Controles de gestión de parches y cambios: cruciales para el éxito de la organización

Controles de gestiónde parches y cambios:cruciales para el éxito

de la organización

GUÍA DE AUDITORÍA DE TECNOLOGÍA GLOBAL

i

Instituto de Auditores InternosGuía de Auditoría de Tecnología Global

Controles de gestión de parches y cambios: cruciales para el éxito dela organización

Autores:

Jay R. Taylor, General Motors Corp.Julia H. Allen, Universidad Carnegie Mellon, Instituto de Ingeniería de Software

Glenn L. Hyatt, General Motors Acceptance Corp.Gene H. Kim, Tripwire Inc.

Copyright © 2005 del Instituto de Auditores Internos, 247 Maitland Avenue, Altamonte Springs, Florida 32701-4201.Todods los derechos reservados. Impreso en Estados Unidos. Ninguna parte de esta publicación puede ser reproducida,guardada en un sistema de recuperación o transmitida en forma alguna ni por ningún medio, sea electrónico, mecánico,

fotocopia, grabación, o cualquier otor, sin obtener previamente el permiso por escrito del editor.

El IIA publica este documento con fines de informativos y educativos. Este documento tiene como propósito bindarinformación, pero no sustituye el asesoramiento legal o contable. El IIA no ofrece ese tipo de asesoramiento y no

garantiza ningún resultado legal ni contable por medio de la publicación de este documento. Cuando surgen cuestioneslegales o contables, se debe recurrir y obtener asistencia profesional.

ii

Parte 1Resumen ejecutivo .............................................................................................................................................................. 1

Parte 2Introducción.......................................................................................................................................................................... 4

Parte 3¿Por qué debo interesarme en cómo la organización gestiona el cambio?.......................................................................... 9

Parte 4Definir la gestión de cambio de TI.................................................................................................................................... 13

Parte 5¿Qué preguntas debo hacer sobre la gestión de parches y cambios? ................................................................................ 21

Parte 6Tres meses más tarde: finaliza la historia de Silvia............................................................................................................ 25

Parte 9¿Por dónde deben comenzar los auditores internos? ........................................................................................................ 28

Parte 8¿Dónde puedo obtener más información?.......................................................................................................................... 31

Parte 9Apéndice A: Programa de auditoría de gestión del cambio de TI.................................................................................... 32

Parte 10Apéndice B: Metodología de Operaciones Visibles .......................................................................................................... 39

Parte 11Apéndice C: Ejemplo Práctico de Negocio para la Gestión del Cambio ........................................................................ 39

Parte 12Apéndice D: Herramientas de la Gestión del Cambio y Proveedores.............................................................................. 42

Parte 13Referencias ........................................................................................................................................................................ 43

Parte 14Acerca de los autores ........................................................................................................................................................ 44

GTAG — Índice

iii

GTAG — Lista de figuras y cuadros

Lista de figuras

Figura 1: Modelo COSO ERM para la gestión del cambio .............................................................................................. 12

Figura 2: Trabajo no planificado como indicador de procesos eficaces de gestión del cambio ........................................ 18

Figura 3: Variables clave que influyen sobre los procesos de gestión del cambio ............................................................ 18

Figura 4: Niveles de capacidad de gestión del cambio ...................................................................................................... 23

Lista de cuadros

Cuadro 1: Mediciones de la gestión del cambio .............................................................................................................. 16

Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo ...................................................... 21

Cuadro 3: Programa de auditoría de gestión del cambio de TI ........................................................................................ 33

Cuadro 4: Roles típicos...................................................................................................................................................... 38

Cuadro 5: Separación de funciones .................................................................................................................................. 38

Cuadro 6: Problemas e indicadores de gestión ineficaz del cambio.................................................................................. 40

Cuadro 7: Beneficios de una transformación eficaz .......................................................................................................... 40

1

1.1 ¿Por qué el Director Ejecutivo deAuditoría debe involucrarse en el controlde la gestión de parches y cambios?

Probablemente, usted se esté preguntando porqué debe leeruna guía sobre la gestión de parches y cambios de la tecnolo-gía informática (TI). Al fin y al cabo, ¿no es este un asuntoque puede delegar por completo en su personal técnico deauditoría de TI? Además, ¿no hay guías lo suficientementeminuciosas sobre este asunto que retoma la gestión del entor-no de computadora central? La respuesta breve a estas dos pre-guntas es “no”.

Si bien el rol principal de los directores ejecutivos deauditoría no incluye el requisito de ser experto en tecnología,existen riesgos significativos asociados a los usos de la tecno-logía en prácticamente todas las actividades empresariales. Esimportante comprender que no es necesario que usted sea unexperto para ayudar a las personas a gestionar la tecnología ysus riesgos asociados. El objetivo de esta guía es ayudar a losdirectores ejecutivos de auditoría, a los ejecutivos del mismonivel, y al personal en general, a que mejoren sus conocimien-tos sobre gestión de tecnología, a la vez que sirve para ayudar-les a aconsejar a la dirección cómo dirigir estos procesos demanera eficaz.

Respecto al público para quien se diseñó esta guía, lostemas relativos a control de cambio de TI raramente han cobra-do tanta importancia como en la actualidad. Los directores eje-cutivos de auditoría son responsables ante los comités deauditoría y se espera que cumplan con las diversas regulaciones,como la Ley Sarbanes-Oxley de EE. UU. de 2002, Artículo 404.Por lo tanto, tener los conocimientos necesarios para cuestionarla gestión de TI no sólo es útil sino también esencial.

Después de leer esta guía, usted podrá:• Disponer de un conocimiento activo de los procesos de

gestión del cambio.• Diferenciar rápidamente los procesos de gestión del

cambio excelentes de los ineficaces.• Reconocer rápidamente los indicadores y las señales de

alarma indicativas de la existencia de problemas de con-trol en los entornos de TI relacionados con la gestióndel cambio.

• Comprender que la gestión del cambio eficaz depende dela implementación de controles preventivos, de detec-ción y corrección para fortalecer la separación de funcio-nes y asegurar una supervisión de gestión adecuada.

• Estar en condiciones de recomendar las mejores prácti-cas conocidas para tratar estos problemas, tanto paraproporcionar un grado de seguridad respecto a riesgos(incluidas las certificaciones de controles), como tam-bién para aumentar el nivel de eficacia y eficiencia.

• Vender sus recomendaciones más eficazmente a losDirectores de TI , a los Máximos Ejecutivos y a losDirectores Financieros.

Dado que cualquier “riesgo de TI” genera cierto grado de ries-go de negocio, es importante que el Director Ejecutivo deAuditoría comprenda en profundidad los problemas de gestióndel cambio.

La gestión de parches y cambios se define en este documentocomo el conjunto de procesos ejecutados dentro del departamen-to de TI de la organización diseñado para gestionar mejoras, actua-lizaciones, correcciones progresivas y parches en los sistemas de

producción, entre ellos:• Revisiones al código de aplicación.• Actualizaciones de sistemas (aplicaciones, sistemas ope-

rativos, bases de datos).• Cambios de infraestructura (servidores, cables, rutea-

dores, filtros de seguridad, etc.).En conjunto, nos referimos a ellos como "cambios de

TI". Todas las organizaciones tienen que afrontar los cambiosde TI con eficacia porque prácticamente cualquier decisiónde negocio exige uno o más cambios en los activos. Cuandolos cambios fallan o se controlan de manera deficiente, elimpacto en el negocio puede ir desde inconvenientes meno-res hasta eventos que impidan el logro de los objetivos delnegocio, incluida la capacidad de cumplir con un conjuntode regulaciones cada vez más grande.

1.2 Una gestión del cambio deficiente sepuede identificar rápidamente

Esta guía fue desarrollada para ayudar a los directores ejecu-tivos de auditoría a plantear las preguntas acertadas a la orga-nización de TI a fin de evaluar la capacidad de gestión delcambio. Con el propósito de ayudarlo a evaluar rápidamenteel nivel general de riesgo del proceso y a determinar si esnecesaria una revisión más detallada de ese proceso, esta guíatambién proporciona las respuestas que se esperan de talespreguntas.

Los primeros cinco indicadores de riesgo de una gestiónde cambio deficiente:• Cambios no autorizados (un valor por encima de cero no

es aceptable).• Interrupciones no planificadas.• Baja tasa de éxito del cambio.• Gran cantidad de cambios de emergencia.• Demoras en las implementaciones de proyecto.

Esta guía incluye mediciones probadas en campo para ayu-darle a evaluar la salud del proceso de gestión del cambiocuantitativamente, como así también sugerirle medicionesde gestión para guiar a su organización a lograr y mantenerniveles de control y rendimiento cada vez más altos. De estamanera, los auditores internos pueden ayudar a la Direcciónidentificando las fuentes de riesgo para la organización y eva-luar la eficacia de los procesos de gestión de riesgo, control ygobierno.

Entre los síntomas e indicadores fácilmente reconoci-bles de fallos de control a causa de cambios de TI controla-dos deficientemente se incluyen:

• Falta de disponibilidad de servicios y funciones críti-cas, incluso durante breves períodos de tiempo.

• Inactividad imprevista del sistema o de la red que a suvez detiene los procesos críticos del negocio, como lacoordinación de calendarios con proveedores y la res-puesta a los pedidos del cliente.

• Inactividad de una aplicación crítica, base de datos oservidores Web, que impide a los usuarios realizar sustareas críticas.

• Publicidad negativa y atraer la atención indeseada delConsejo de Administración.

GTAG — Resumen ejecutivo — 1

2

GTAG — Resumen ejecutivo — 1

A un determinado nivel organizacional, los indicadores deque las organizaciones de TI tal vez presenten problemas sis-témicos de control de gestión del cambio son, entre otros:

• La mayor parte del tiempo de TI de la organización seemplea en operaciones y mantenimiento (>70%), enlugar de ayudar al negocio a implementar nuevascapacidades.

• Imposibilidad de completar proyectos y trabajos plani-ficados (a causa de la necesidad de combatir numero-sas situaciones de emergencia y trabajos no planeados).

• Se despierta a la Dirección de TI en el medio de lanoche por diversos problemas.

• Alta rotación del personal de TI.• Relaciones de confrontación entre el personal de asis-

tencia técnica de TI, los desarrolladores y los clientesdel negocio (internos o externos), generalmente a raízde la mala calidad del servicio o por demoras en laentrega de funcionalidad.

• La gestión de TI invierte una excesiva cantidad detiempo en prepararse para las auditorías de TI y solu-cionar los problemas detectados.

Lo que separa a muchas organizaciones de tener un desem-peño deficiente es sólo un cambio nada más.

1.3 Reflexiones para comprender cómo segestiona el cambio de TI con eficacia

La gestión del cambio frecuentemente es un tema de difícildominio para las organizaciones dado que hay muchas partesinteresadas involucradas (por ejemplo, gerentes de negocio,desarrolladores de sistemas de aplicación, personal de opera-ciones de TI, auditores, etc.). No obstante, esta no es unarazón para que las organizaciones sean complacientes con loscontroles inadecuados o con desempeños deficientes.

Los entornos de producción estables y bien administra-dos exigen que la implementación de cambios sea predecibley repetible, que obedezca a un proceso controlado que sepueda definir, supervisar e implementar. Los controles de TInecesarios para alcanzar esto son análogos a los controles uti-lizados en los procesos financieros para reducir el riesgo defraude y errores: separación de controles de funciones (queson de naturaleza preventiva) y de controles de supervisión(que son de naturaleza preventiva y de detección).[Chambers 03]

Los directores ejecutivos de auditoría deben estar bastan-te familiarizados con estos controles: Únicamente el personalmínimo necesario para implementar los cambios de TI en pro-ducción debe tener acceso a dicho entorno (preventivo). Losprocesos de autorización deben involucrar a las partes intere-sadas para evaluar y mitigar los riesgos asociados a los cambiospropuestos (preventivo). Los procesos de supervisión debenimpulsar a la gerencia de TI y al personal relacionado a asumirsus funciones responsablemente (preventivo) y a ser capacesde detectar un desempeño errático (de detección).

Donna Scott, Vicepresidenta y Directora deInvestigación de Gartner, destaca que “el 80% del tiempo deinactividad de [TI] no planificado se debe a problemas delproceso o provocados por las personas, incluidas las prácticasde gestión del cambio". Estos problemas surgen a partir de la

ausencia de controles automáticos preventivos, de deteccióny corrección que posibilitan buenas decisiones basadas en elriesgo con respecto al cambio, monitorización eficaz y apli-cación del proceso de gestión del cambio.

Las organizaciones de alto rendimiento de TI tambiénhan llegado a esta conclusión, que a su vez está respaldadapor un trabajo bastante amplio realizado por el Instituto deIngeniería de Software (en inglés, SEI) y el Instituto deProcesos de TI (en inglés, ITPI).

¿Qué tienen en común las organizaciones de alto rendi-miento de TI? Poseen una cultura de gestión del cambio queimpide y evita cambios sin la correspondiente autorización.Además, "confían, pero siempre verifican" mediante el usode controles de detección independientes para conciliar loscambios en la producción contra los cambios autorizados y,en el caso de interrupciones de servicio, excluyen la opciónde "cambiar primero" en el ciclo de reparaciones. Por último,también cuentan con el tiempo promedio de reparación másbajo (en inglés, MTTR).

Los auditores observarán que en estas organizaciones dealto rendimiento de TI, la gestión del cambio no se ve comoalgo burocrático, sino por el contrario, como la única red deseguridad que evita que se conviertan en una organización debajo rendimiento. En otras palabras, la gestión de TI poseelos controles para alcanzar sus propios objetivos de negociode manera eficiente y eficaz.

El logro de una tasa de éxito del cambio de más de 70% sóloes posible con controles preventivos y de detección.

Loa auditores internos, junto con la dirección, desean asegu-rar que los riesgos relacionados con la gestión del cambio sehayan identificado, medido y gestionado correctamente. Elpunto clave a recordar es que la gestión de cambio exige con-centrarse en el proceso con un enfoque administrador y huma-no que está respaldado por controles técnicos y automáticos.

1.3.1 Consideraciones regulatoriasLos procesos de gestión de cambio eficaz sirven para que laorganización pueda cumplir permanentemente con las nue-vas y aún más amplias regulaciones. Se debe prestar especialatención cuando se implementan cambios de tecnología querespaldan el proceso de preparación de informes financieros.Esos cambios pueden afectar al cumplimiento organizacionalcon la Ley Sarbanes-Oxley, las directivas de privacidad de laUnión Europea y los requisitos del Proyecto de ley delSenado (SB) 1386 del Estado de California. Los cambios sincontrol en producción pueden conducir a errores, que si sonuniversales o críticos, se considerarán como deficienciasimportantes. Cuando determinados controles financierosclave se ven afectados o bien cuando la organización nopudo corregir deficiencias importantes de control general deTI, que fueron identificadas el año anterior (como, por ejem-plo, en gestión del cambio), la gestión probablementeenfrente la posibilidad de tener que resolver debilidadesmateriales.

Cuando el fallo no es una opciónAl gestionar los cambios, usted controla gran parte del riesgopotencial que los cambios pueden introducir.

1.4 Los primeros cinco pasos para minimizarlos riesgos del cambio de TI

En esta guía, hemos encuadrado las mejores prácticas que seobservaron en cuanto a procesos de gestión del cambio quereducen el riesgo del negocio y aumentan el grado de eficien-cia y eficacia de TI. En resumen, los cinco pasos prescripti-vos que la mayoría de las organizaciones pueden adoptar deinmediato para mejorar sus procesos de gestión del cambioson los siguientes:

• Crear un ambiente en la alta dirección que motive lanecesidad de una cultura de gestión del cambio entoda la empresa, que a su vez esté respaldada por unadeclaración de la gerencia de TI de que la única canti-dad de cambios no autorizados aceptable es cero.Entonces, se pueden poner en práctica controles pre-ventivos y de detección para ayudar y sostener esteobjetivo a fin de asegurarse de que todos los cambiosde producción sean conciliados con órdenes de traba-jo autorizadas.

• Monitorizar continuamente la cantidad de interrup-ciones no planeadas, lo cual es un excelente indicadorde cambios no autorizados y fallos en el control decambios.

• Reducir la cantidad de cambios que implican riesgos alestablecer de manera específica períodos para congela-ción de cambios y mantenimiento bien definidos y deestricto cumplimiento. De esta manera se maximiza elgrado de estabilidad y productividad durante las horasde producción. Las interrupciones no planificadas sir-ven como indicadores eficaces de que este proceso decambio está siendo soslayado.

• Utilice la tasa de éxito del cambio como un indicadorclave del desempeño de la gestión de TI. En los entor-nos donde los cambios no son gestionados, monitoriza-dos y controlados, las tasas de éxito de cambio por logeneral están por debajo del 70%. Cada cambio fallidogenera tiempo improductivo potencial, trabajos deemergencia y no planeados, discrepancias con los pla-nes y riesgo de negocio. Para aumentar la tasa de éxitodel cambio se necesitan controles eficaces preventivos,de detección y corrección.

• Utilice el trabajo no planificado como indicador deeficacia de los procesos y controles de gestión de TI.Las organizaciones de TI con alto rendimiento dedicanmenos del 5% de su tiempo a trabajos no planificados,en tanto que las organizaciones promedio más frecuen-temente emplean del 45% al 55% de su tiempo enactividades no planeadas (y urgentes).

1.5 El rol del auditor internoEl Comité de Auditoría desea asegurarse de que la gerenciahaya identificado y evaluado los riesgos que podrían impediralcanzar los objetivos del negocio. Se deben adoptar proce-sos robustos para mitigar, gestionar, aceptar o transferir losriesgos eficazmente. Los auditores internos son los ojos yoídos de la gerencia y del comité de auditoría, a través de

ellos se busca detectar las áreas que necesitan fortalecimien-to. A esos fines, la importancia de un proceso de gestión delcambio eficaz no se debe subestimar y los auditores internosdeben considerar la posibilidad de efectuar revisiones regu-larmente.

3

Introduction – 3GTAG — Resumen ejecutivo — 1

GTAG — Introducción — 2

4

Esta guía aborda la gestión de parches y cambios de TI comoherramienta de gestión y trata los siguientes temas:ón y tratalos siguientes temas:

• ¿Por qué la gestión de parches y cambios de TI esimportante?

• ¿De qué manera la gestión de parches y cambios de TIayuda a controlar los riesgos y los costos de TI?

• ¿Qué estrategias funcionan y cuáles no?• ¿Cómo saber si la gestión de parches y cambios de TI

funciona eficazmente?• ¿Qué debe hacer la auditoría interna?

Los apéndices de la guía proporcionan herramientas a lagerencia y a los auditores para entender y abordar los riesgosinherentes a la gestión de parches y cambios de TI.

2.1 ¿Por qué la gestión de parches y cambios deTI es importante?

Las recientes investigaciones han demostrado que una ges-tión deficiente de parches y cambios de TI aumenta el tiem-po improductivo y los costos. Hay ejemplos destacados queilustran este problema. CNET News informó que en 2001,un “error de configuración del ruteador” de Microsoft inte-rrumpió el servicio a Microsoft.com, MSN.com,Expedia.com y a otros más. No se pudo reanudar el serviciopor completo sino hasta después de transcurridas 22 horas.1

En el año 2004, el diario Globe and Mail informó sobre uncambio de software relativamente menor en el banco RoyalBank de Canadá que ocasionó que “de repente, 10 millonesde clientes del banco no pudieran saber con seguridad los sal-dos de sus cuentas durante varios días y una cantidad noespecificada de personas se quedó esperando para realizardepósitos y otras transferencias”2 ¿De qué forma se puedesiquiera comenzar a calcular los costos de tales problemas?

Considere que las organizaciones que tienen mejor gestiónde parches y cambios ostentan las siguientes características:

• Gastan menos dinero y energía de TI en trabajo noplanificado.

• Destinan más cantidad de dinero y energía de TI anuevos trabajos y a alcanzar las metas del negocio.

• Tienen menos tiempo improductivo.• Instalan parches con interrupciones mínimas.• Se concentran más en las mejoras y menos en “apagar

incendios”.Si las organizaciones necesitan más incentivos que estos, laLey Sarbanes-Oxley (para aquellos a quienes compete) losproporciona al exigirle a la dirección ejecutiva que compren-da y apruebe formalmente los controles sobre la preparaciónde informes financieros, incluidos los controles de TI. Sin unagestión del cambio de TI eficaz, es difícil ver cómo la direc-ción puede cumplir con los requisitos de la Ley y garantizar laintegridad de los estados financieros.

2.2 ¿De qué manera la gestión de parches ycambios de TI ayuda a controlar los riesgosy los costos de TI?

Los riesgos de TI de cualquier tipo se pueden ver exacerba-dos por una gestión del cambio de TI ineficaz. En oposición,

los riesgos se pueden controlar mediante procesos de gestiónde parches y cambios prudentes y bien diseñados. Tal vez seamenos evidente que una buena gestión de parches y cambiosde TI puede reducir costos.

Sin control y visibilidad adecuados, una organizaciónpuede gastar dinero y esfuerzo en cambios innecesarios ymenos prioritarios, a la vez que se descuidan iniciativasmás importantes. Los cambios de diseño deficiente o sinla ponderación adecuada pueden ocasionar interrupcio-nes que luego, después del hecho, deberán ser resueltas, obien puede ocurrir que se deban “retirar” los cambios rea-lizados. Los cambios de TI en un componente puedeninterrumpir la operación de otros componentes. Estasinterrupciones cuestan tiempo y dinero, sin embargo, sepueden mitigar mediante un buen proceso de gestión deparches y cambios de TI.

Por último, la gestión del cambio de TI ineficientee ineficaz puede costarle a la organización las siguientes con-secuencias:

• Desgaste del personal de TI altamente calificado debi-do a la frustración producida por los resultados de bajacalidad.

• Sistemas de baja calidad que impiden a los empleadosser eficaces y eficientes, o que hacen perder clientes.

• Pérdida de oportunidades para proporcionar a losclientes servicios y productos innovadores o más efi-cientes.

Los procesos de gestión del cambio de TI bien diseñados yrigurosamente implementados pueden producir los resulta-dos opuestos. Los esfuerzos de TI se pueden centrar en lasprioridades del negocio. Se pueden minimizar las situacionesde emergencias al respecto. Se puede retener al personal deTI y motivarlo para alcanzar la excelencia. Se puede propor-cionar a los empleados herramientas que ampliarán su pro-ductividad. Los clientes se sentirán satisfechos con sistemasque responden a sus necesidades.

2.3 ¿Qué estrategias funcionan y cuáles no?Para ser eficaz, la gestión del cambio de TI debe proporcio-nar a la dirección de la organización un grado de visibilidaden los siguientes puntos:

• Qué es lo que se cambia, por qué y cuándo.• Cómo se implementan los cambios eficiente y

eficazmente.• Cuáles son los problemas ocasionados por los cambios

y qué grado de severidad tienen.• Cuánto cuestan los cambios.• Cuáles son los beneficios que brindarán los cambios.

Esa visibilidad se proporciona a través de mediciones e indi-cadores que se informan de manera regular y objetiva. Esos sonlos instrumentos del tablero de mando que otorgan a la direc-ción la visibilidad necesaria.

La gestión del cambio de TI proporciona el acelerador, elpedal de freno y el volante (y una marcha atrás para volver alas configuraciones anteriores) para controlar el vehículo deTI a través de:

1 “Microsoft responsabiliza a los técnicos por la interrupción masiva del servicio”, CNET News, 24 de enero de 20012 “RBC adjudica la culpa a errores humanos”, GLOBEANDMAIL.com, 10 de junio de 2004.

• La participación temprana y frecuente por parte de ladirección y de los usuarios finales para alinear los cam-bios de TI con las necesidades del negocio.

• Un proceso definido, predecible y repetible con resul-tados definidos, predecibles y repetibles.

• Coordinación y comunicación con los participantesafectados por los cambios.

2.4 ¿Cómo saber si la gestión de parches ycambios de TI funciona eficazmente?

Como guía general, la dirección (incluida la gestión de TI)puede verificar si la gestión de parches y cambios está dandoresultados mediante la formulación de una serie de preguntassimples y el análisis de las respuestas:

• ¿Tenemos un proceso de gestión del cambio eficaz?¿La respuesta es una negación de la importancia de la ges-tión del cambio de TI o una afirmación de su importanciay reconocimiento de las mejoras en curso?

• ¿Qué controles se han adoptado en nuestro procesode gestión del cambio?¿Los controles se han puesto en práctica y se mejoran díaa día o simplemente están en evaluación y se aplaza suincorporación hasta que la situación de emergencia pase?

• ¿Hemos visto los beneficios del proceso de gestión delcambio?¿Hay beneficios medibles o el énfasis está centrado en loscostos del proceso de gestión del cambio de TI?

• ¿Recuerda la interrupción que afectó a todo el sitiodurante la semana pasada como consecuencia de uncambio? ¿Qué pasó?¿Cuánto sabe la dirección acerca de las causas de las inte-rrupciones? ¿Cuál es el grado de control que tiene ladirección respecto a la recurrencia del problema?

• ¿Qué proceso se utilizó para determinar la causa de lainterrupción?¿Fue de tipo ad hoc o metódico? ¿El diagnóstico del pro-blema determinó rápidamente si la interrupción fue causa-da por un cambio, y de ser así, qué cambio provocó elproblema?

• ¿De qué manera TI controla el estado de salud delproceso?¿Los indicadores y medidas son elementos indicativos obje-tivos y verdaderos o son subjetivos y sospechosos?

• ¿Cuál es la meta de nuestro proceso de gestión delcambio?¿Se centra en factores de fiabilidad, disponibilidad y efi-ciencia, o en otras metas menos cruciales? ¿En ese aspec-to, está realmente centrado en algo?

• ¿Nuestro proceso de parches qué grado de interrupcio-nes ocasiona?¿La gestión de parches es parte de un proceso de lanza-mientos y cambios definido y repetible, o es del tipo adhoc, informal y basado en emergencias?

Las investigaciones recientes sugieren que las organizacionesque tienen mejores procesos de gestión de parches y cambiosde TI necesitan menos administradores de sistemas. Cuandola gestión de parches y cambios de TI funciona bien, el per-sonal de TI es más eficaz y productivo.

Se deben informar las medidas más rigurosas y formalespara proporcionar la máxima visibilidad sobre la eficacia dela gestión de parches y cambios de TI, entre ellos:

• Cambios autorizados por semana.• Cambios implementados por semana.• Cantidad de cambios no autorizados que soslayan el

proceso del cambio.• Tasa de éxito del cambio (porcentaje de los cambios

reales efectuados que no ocasionaron interrupciones,deterioro de servicios o un episodio de trabajo no pla-nificado).

• Cantidad de cambios de emergencia (incluidos los par-ches).

• Porcentaje de parches implementados en las versionesde software planificadas.

• Porcentaje de tiempo empleado en trabajo no planifi-cado.

• Porcentaje de proyectos entregados más tarde de loplanificado.

2.5 ¿Qué debería hacer auditoría interna?Esta Guía de Auditoría de Tecnología Global (GTAG) tratasobre la gestión de los riesgos que son una preocupación cre-ciente de aquellas personas implicadas en el control y goberna-bilidad del proceso. Al igual que la seguridad de la información,la gestión de los cambios de TI es un proceso fundamental que,de no efectuarse correctamente, puede ocasionar daños a todala empresa. Este impacto a nivel de toda la empresa hace queel tema sea de interés para la mayoría de los comités de audito-ría y, en consecuencia, para la alta dirección.

Esta guía proporciona herramientas para ayudar a losauditores internos a obtener y evaluar las evidencias de que lasaseveraciones de la gestión de TI (desempeño, eficacia, efi-ciencia) son correctas. Al igual que en el proceso de una audi-toría3 financiera, los auditores de TI deben obtener los datossubyacentes de autorización (por ejemplo, informes del cam-bio autorizado) y la infor--mación que sirve de respaldo y evi-dencia los hechos (por ejemplo, informe de los cambios deproducción a partir de los controles de detección, cotejo de loscambios de producción con los cambios autorizados, las inte-rrupciones de sistema, etc.). Al hacer esto, los auditores pue-den expresar de manera competente una opinión sobre lasaseveraciones de la gestión de TI respecto a sus procesos degestión del cambio y su capacidad de mitigar el riesgo en losestados financieros.

La auditoría interna puede ayudar a la dirección y al con-sejo de administración implementando las siguientes accio-nes:

• Comprender los objetivos de la organización relaciona-dos con la confidencialidad, integridad y disponibilidaddel procesamiento de TI.

• Ayudar a identificar los riesgos que pueden surgir a par-tir de los cambios y determinar si tales riesgos son cohe-rentes con el grado de apetito de riesgo y tolerancia dela organización.

• Ayudar en la toma de decisión en cuanto a elegir unacartera apropiada que responda a la gestión de riesgos.

• Buscar e impulsar una cultura de gestión de cambio dis-

5


3 Adaptado del libro de Auditoría de Montgomery: 12ª edición, Capítulo 1: “Resumen de Auditoría” [O'Reilly 98]

ciplinada, incluida la promoción de los beneficios deuna buena gestión de cambio.

• Comprender los controles que son cruciales para unenfoque sólido de la gestión del cambio de TI.– Preventivos.

• Autorizaciones apropiadas.• Separación de funciones.• Supervisión.

– De detección.• Detección de cambios no autorizados.• Monitorización de las mediciones de la gestión

del cambio objetivo y válido..– De corrección.

• Revisiones posteriores a la implementación.• Alimentación de información del cambio durante

los primeros pasos de diagnóstico del problema.• Mantener actualizados los procesos de gestión de par-

ches y cambios de TI y recomendar su adopción a laorganización.

• Demostrar de qué manera la dirección puede cosecharlos beneficios provenientes de una mejor gestión delriesgo, del mayor grado de eficacia y de los menores cos-tos.

• Ayudar a la dirección a identificar enfoques prácticos yeficaces en relación con la gestión del cambio de TI.

2.6 Un diálogo esclarecedor entre un Directorde TI (DTI) y un Director Ejecutivo deAuditoría (DEA)

Uno de los desafíos para un gobierno y auditoría de TI efica-ces es realizar buenas preguntas que revelen de qué maneralos gerentes de TI piensan y verifican que las estrategias y lastácticas de TI respondan a los objetivos del negocio. Confrecuencia, las conversaciones se centran en las tecnologíasmás que en los procesos de control y gestión para implemen-tar y sostener esa tecnología, y operarla de manera eficiente.

Muchos ven la gestión del cambio como una burocraciainnecesaria, y no como una herramienta que posibilita el logrode las metas del negocio. Además, muchas organizaciones deTI confunden a las tecnologías del tipo de los sistemas de soft-ware de gestión de parches como si fueran el sustituto de unproceso de gestión saludable. Si bien el software de gestión decambio puede automatizar los controles para ayudar a asegurarla aplicación del proceso de gestión del cambio, el sólo hechode tener el software no proporciona los resultados necesarios.

Los ejecutivos de auditoría de rango superior puedenproporcionar orientación y asesoramiento a los gerentes deTI sin profundizar en detalles técnicos que desvían la aten-ción de la pregunta real: ¿Nuestros procesos de gestión del cam-bio son eficaces y estamos llevando a cabo las actividadescorrectas de TI basadas en el cambio?

Para mostrar con qué rapidez el director ejecutivo deauditoría puede determinar la salud de los procesos de ges-tión del cambio de TI, incluimos un diálogo ficticio entreSilvia, quien recientemente tomó su nuevo puesto de traba-jo como DTI de una de las empresas Fortune 500 (DTI), yFernando, el DEA. El diálogo ilustra cómo las suposicioneserróneas se evidencian incluso en los gerentes de TI de rangosuperior y cómo estas suposiciones se pueden cuestionar coneficacia para provocar cambios drásticos en sus sistemas de

creencias y enfoques.¿Por qué un diálogo? El Dr. Eliyahu Goldratt adquirió pro-

tagonismo en 1980 por su trabajo sobre la teoría de las restric-ciones, que es uno de los tres movimientos de gestión clave deesta década. (Los otros dos sistemas de gestión y de resoluciónde problemas son la Gestión de Calidad Total del Dr. W.Edward Deming y las metodologías de fabricación, como Justoa Tiempo). Probablemente el Dr. Goldratt sea más famoso porsu libro The Goal: A Process of Ongoing Improvement [Goldratt92], donde el protagonista es un gerente de planta que inten-ta aumentar la calidad y disminuir el costo antes del cierre dela planta en 60 días. Su libro ha vendido millones de copias yse utiliza en cientos de cursos universitarios de todo el mundo.Este diálogo está inspirado en The Goal.

2.6.1 La convicción de Silvia en su plan de gestiónde parches se hace añicos

Hace una semana, a Silvia la ascendieron de Directora deOperaciones a Directora de TI (DTI). Debe afrontar losdesafíos de abordar no sólo todos los problemas de disponibi-lidad y competitividad de costos de TI, sino también losmolestos problemas de seguridad. Hay abundantes rumoresde que toda su división será externalizada.

Silvia está esperando para entrar a la reunión de comitéde auditoría. Fernando, DEA, también está esperando juntoa ella. Fernando se unió a la empresa hace seis meses y pro-viene de una conocida firma de telecomunicaciones global.Silvia se pregunta si debería aprovechar esta oportunidadpara conocer más a Fernando. Desarrollar una relación detrabajo de respeto mutuo podría mejorar su función DTI.

Silvia abrió el diálogo diciendo “Fernando, estoy poconerviosa por la reunión. Esta es mi primera actualizaciónsobre el estado del programa de seguridad de la informaciónde la empresa”. Fernando es un veterano en el tema dadas susnumerosas interacciones con el comité de auditoria y deinmediato siente simpatía por Silvia y su preocupación.

“No te preocupes. Si puedes definir tus metas con clari-dad y describir lo que necesitas para alcanzarlas, estoy segurode que no habrá ningún problema. No te dejes intimidar porla reputación del comité de auditoría. He estado en amboslados de la mesa y me parece que estas personas son muy pro-fesionales, competentes y agradables”.

“¿De veras? Entiendo que te incorporaste a la empresa aprincipios de año y que provienes de ABC Telecom. ¿Estabasa cargo de la auditoría interna allá?”, pregunta Silvia.

“No, mi experiencia en realidad incluye algunos perío-dos en TI y en auditoría financiera e investigación de frau-des”, responde Fernando. “Considérame como una personade negocios que trabaja en auditoría interna”.

Al escuchar esto, Silvia se siente de inmediato más tran-quila. ¡Tenemos antecedentes similares! “Entonces, conoceslos temas que debo afrontar. ¡Eso es un verdadero alivio!Sabes por lo que estoy pasando. Ya hemos logrado salir delapuro de cerrar los baches existentes en la seguridad de lainformación Mi idea es contarles lo que hemos estadohaciendo para aplicar los parches con más rapidez y reducirlas vulnerabilidades ante gusanos y virus. Antes de ser desig-nada DTI tuve a mi cargo la tarea de desarrollar nuestronuevo sistema de gestión de parches”.

Fernando duda. “¿Te pareció que era necesario un siste-


6

ma totalmente nuevo para ayudarte a administrar los par-ches?”

“Sí”, contesta Silvia. “Hemos estado trabajando en estodurante seis meses para solucionar un problema detectado enuna auditoría y reducir nuestra carga de trabajo”.Verdaderamente se logró mejorar la eficiencia y la seguridad.Nunca más se nos pasará un parche importante”.

Fernando frunce el ceño. “Ah, la verdad es que nomuchas veces escucho algo así. Permíteme preguntarte esto:¿cuándo es aceptable no implementar un parche?”

Ahora es Silvia la que comienza a fruncir el ceño.Fernando parecía una persona muy inteligente, pero sus pre-guntas son bastantes extrañas. Silvia responde, “Bueno, enrealidad, ¡nunca! Justamente, la omisión de parches es exac-tamente lo que nos valió la observación de auditoría en pri-mera instancia. Mi meta es asegurarnos de que siempreimplementemos los parches tan pronto como sea posible. ¡Alfin y al cabo, nuestra tarea es asegurarnos de que estos servi-dores son seguros! No solamente vamos a tener más seguri-dad, sino que además seremos más eficientes”.

Fernando parece algo exasperado. “¿De veras? ¿Estásimplementando tecnología de gestión de parches y obtienesrealmente un grado mayor de eficiencia?”

“Rotundamente. Ya hemos obtenido excelentes resulta-dos. En realidad, recientemente hemos alcanzado el hito decobertura de servidores del 60%”.

“¿Y pudieron aumentar la eficiencia… en qué grado?”,pregunta Fernando.

“Bueno, no tengo todos los detalles, pero sé que el retor-no de la inversión es importante”. Silvia busca en su maletíny con orgullo le muestra a Fernando el informe de una pul-gada de espesor. “Aquí está. Al automatizar el proceso deparches, estaremos ahorrando entre 300 y 600 horas del per-sonal por mes”.

Fernando mira el informe, pero no lo toma. “¡Increíble,600 horas de personal por mes! Ese ahorro equivale a más detres empleados a tiempo completo. ¿Entonces, estás redu-ciendo el número de trabajadores en tres personas gracias atodo ese ahorro de mano de obra?”

“¡Ojalá fuera así! Siempre tenemos un cúmulo de traba-jo atrasado porque no tenemos personal suficiente.Permanentemente hay nuevos proyectos, y ni siquiera men-cionemos las constantes emergencias por roturas y correccio-nes que nos exigen dejar lo que estemos haciendo para correra reparar la catástrofe del día. Esa es justamente la razón porla que necesitamos automatizar todo”.

Fernando se reclina y se sonríe como si hubiera confir-mado una sospecha. Silvia se siente algo insegura. Fernandopregunta, “¿Qué están haciendo exactamente en este instan-te esas dos personas que completaron la implementación?”

“Bueno, como dije, se están ocupando de diversos proble-mas que varían de emergencias operacionales a desafíos impre-vistos relacionados con el sistema nuevo. Con frecuencia, nostopamos con parches que no se aplican correctamente la pri-mera vez y siempre hay algunas cuestiones residuales que debe-mos corregir manualmente. Estos problemas se resolverán unavez que logremos establecer el proceso”.

“¿Entonces, estás diciendo que la tasa de éxito inicial delsistema es relativamente baja?”, pregunta Fernando.

“Bueno, tal vez, pero estoy segura de que con el tiempo,podremos resolverlo”, responde Silvia, un poco a la defensiva.

“¿Todo este trabajo no planeado tiene un impacto sobretu disponibilidad, verdad?”, continúa Fernando.

Ajá. Fernando mencionó el asunto de la disponibilidad.Ese es un punto definitivamente sensible. Silvia recuerda lasreuniones de confrontación con distintos gerentes de unida-des de negocio a quienes les impactó el tema del fallo dealgunos parches. “Bueno, cierto que sí, en algún grado. Pero,¿hacia adónde apuntas con todo esto?”

Fernando hace caso omiso de su pregunta. En cambio,pregunta, “¿Y este sistema de gestión de parches resolvió lasobservaciones realizadas por auditoría? Mi informe para elcomité de auditoría de hoy señala que la fecha de finaliza-ción del objetivo en tu plan de acción se sigue postergandocada día”.

Transcurren unos instantes durante los cuales Silviatrata de pensar una respuesta. En una voz tan confidentecomo le es posible, responde “Bueno, no, esas observacionesde auditoría no se han resuelto todavía, pero nos hemoscomprometido a hacer que el sistema funcione”.

2.6.2 Fernando saca conclusiones según los hechos“Silvia, imagino que si no has aumentado la disponibilidad ni laseguridad, no has disminuido el gasto operacional, y en realidadestás generando más trabajo no planeado, entonces no me pue-des decir que estás incrementando el grado de eficiencia”

“Es más, es muy probable que estés acelerando la tasa decambio al implementar parches sin aumentar la tasa deéxito, por lo tanto, tu cantidad de trabajo no planeado sedebe estar incrementando sideralmente. Adivino que losgerentes de unidades de negocio estarán tan molestos quepiden a gritos la desconexión del sistema completo”.

Anonadada, Silvia se pregunta para qué inició esta con-versación con Fernando. Iba a presentar con orgullo su plande gestión de parches y ahora ni siquiera está segura de queeso sea una buena idea.

“Fernando, ¿cómo sabes esas cosas? Ojalá pudiéramostener más tiempo porque pareciera que has puesto tu dedo enuno de mis mayores problemas”.

“Opino lo mismo. Si tuviéramos un poco más de tiem-po, me parece que podría ayudarte a mantener el trabajo deTI dentro de la empresa y salvar tu nuevo puesto”.

“¡Un momento! Mi organización no está en apuros. Conun software tan deficiente como el que tenemos hoy, es nece-sario automatizar el proceso de parches para mantener lainfraestructura segura. El negocio sigue imponiéndonosdemandas totalmente insanas sin comprender los temas deTI o seguridad".

“Silvia, para mí, es evidente que no estás ejecutandouna operación de TI segura y eficiente. En realidad, proba-blemente estés gestionando una operación ineficiente e inse-gura. Si el comité de auditoría comienza a realizar preguntas,esto se hará evidente y tal vez perciba que no estás adminis-trando los riesgos correctamente. Según esta breve conversa-ción, creo que hay determinados problemas sistémicos decontrol del cambio de TI. Mi parecer es que no tienes loscontroles preventivos, de detección y corrección que necesi-tas para aplicar la separación de roles adecuada y los contro-les de supervisión eficaz.”


7

8

“¿Me estás diciendo que mi gente me miente?”“En general, la gente rara vez miente acerca de estas

cosas. Sin embargo, tus mediciones ciertamente sí. Cuandohablas de eficiencia, me parece que no has comprendidobien el punto central del tema. Es necesario que piensesacerca de este asunto un poco más. Las próximas dos sema-nas, estaré afuera de viaje, pero, si lo deseas, puedes llamar ami asistente y concertar una cita para que hablemos de esto”.Luego, Fernando se levanta e ingresa a la sala de conferen-cias.

Más tarde, llaman a Silvia para que ingrese a la reunióny con éxito presenta el plan de seguridad de la informacióny los logros ante el comité de auditoría. En 15 minutos, fina-liza y regresa a su oficina.

“¿Qué fue lo que pasó?, se pregunta Silvia. Antes de suconversación con Fernando, la gestión de parches era el cen-tro de su plan y anhelaba utilizar el éxito de esta para demos-trarles a todos cuán competente era. Pero después de suconversación con Fernando, su confianza se había desmoro-nado de tal manera que en su presentación ante el comité deauditoría sólo mencionó la gestión de parches muy breve-mente. Y lo peor de todo era que no podía ver qué era lo queestaba mal.

Silvia admite para sí misma que su implementación delsistema de gestión de parches no está funcionando según loplaneado. La fecha de finalización del proyecto se demoracada día más. Se pregunta cómo Fernando pudo saber que elproyecto estaba comenzando a desviarse de la meta ¿Quéquiso significar Fernando cuando dijo que ella no habíaentendido bien y que no estaba gestionando el asuntocorrectamente?

El resultado de este diálogo se encuentra en la Parte 5,página 25.


Los auditores internos y los profesionales de TI tienenamplia información sobre las disciplinas informáticas opera-tivas de gestión del cambio y control del cambio. Estos pro-cesos ha sido bien definidos en publicaciones que seremontan a Computer Control and Audit de Mair, Wood &Davis [Mair 73] y otras. El Instituto de Auditores Internos ysu publicación, Systems Auditability and Control, de 1977marcaron un hito. Esta fue actualizada en 1994 y refleja ade-cuadamente la importancia de este tema para la direción delas organizaciones y los auditores internos.

La gestión del cambio y del problema es crítica paraalcanzar una operación estable, confiable y bien con-trolada. Implica rastreo del problema, procedimientosde escalamiento, revisión de los problemas y cambiosde la gestión, establecimiento de un orden de priori-dad de recursos, movimiento controlado de programasen producción, y control del cambio de software desistemas.

Sin embargo, sólo recientemente se han realizado esfuerzospara entender cuáles son las prácticas y condiciones deentornos de TI que impulsan resultados comerciales. Lanueva investigación publicada por el Instituto de Ingenieríade Software y el Instituto de Procesos de TI en 2004 muestraque una de las diferencias clave que definen el alto o el bajorendimiento de las organizaciones de seguridad y TI es la pre-sencia de una cultura eficaz de la gestión del cambio. Enotras palabras, la gestión del cambio no sólo es un controlbásico clave, sino que también ofrece potenciales beneficiospara el negocio.

El informe titulado Best in Class Security and OperationsRound Table Report (BIC SORT) [Allen 04], reproduce algu-nas de las diferencias que hay entre los departamentos deseguridad y de TI de alto y bajo rendimiento. El informe des-cribe los problemas y las inquietudes principales, los procesosy procedimientos resultantes utilizados para responder aellos, así como los sistemas de creencias y la cultura que sos-tiene a tales procesos y procedimientos. Con esta visión, losautores descubrieron cómo se comportaban las organizacio-nes de alto y bajo rendimiento, tanto cuantitativa como cua-litativamente.

En las organizaciones de bajo rendimiento, la gerenciano puede confiar en la gestión del cambio de TI para respal-dar su negocio adecuadamente. Exacerbando este punto, lasorganizaciones que carecen de una disciplina de gestión delcambio, tampoco tienen mediciones rigurosas y visibilidad.La gerencia y la auditoría interna, respecto a eso, no tieneninguna manera confiable de evaluar con exactitud la efica-cia y eficiencia del proceso de gestión del cambio. Cuando elaseguramiento de los controles del cambio que respaldan unproceso de negocios se ve suficientemente socavado, elmismo proceso del negocio también se ve socavado. En con-traste, las organizaciones de gestión del cambio de IT de altorendimiento pueden proporcionar información centrada yexacta para ajustar su propio desempeño, y para permitir a lagerencia y a los auditores evaluar el proceso de gestión delcambio junto con la capacidad de respaldar los procesos delnegocio afectados.

Como auditores internos, debemos familiarizarnos coneste tipo de información y aplicarla en las revisiones de audi-

toría para ayudar a nuestras organizaciones a administrar lasinversiones de TI con mayor grado de eficiencia y eficacia.

3.1 El cambio genera riesgos: por qué losparches deben ser tratados simplementecomo otro cambio

Los auditores saben que existe una relación estrecha entre elcambio y el riesgo. Los activos de TI parecen estar en unestado de cambio constante. La gestión de TI debe tratar conlo siguiente:

• Cambios regulares (por lo general, aplicaciones, soft-ware intermedio, sistema operativo, software de la redy actualizaciones de hardware programadas para laimplementación).

• Parches (cambios para reparar códigos defectuosos uotras vulnerabilidades detectadas en producción).

• Cambios de emergencia necesarios para corregir pro-blemas inmediatos que provocan la interrupción delservicio.

La gestión del cambio de TI eficaz permite que la organiza-ción se pueda mover con seguridad de un estado conocido ydefinido a otro, independientemente de la razón que motiveun cambio.

Los activos de TI son más fáciles de administrar y con-trolar cuando no existe la presión de implementar o entregarel cambio. Por ejemplo, considere las características positi-vas asociadas con los períodos de congelación del cambio: losniveles de servicio y disponibilidad son los más altos, y eldepartamento de TI emplea la mayor parte de su tiempo entrabajos planeados.

Sin embargo, ¿qué ocurre cuando se detectan vulnerabi-lidades críticas y se incrementa el nivel de urgencia del cam-bio? ¿Qué sucede cuando los numerosos proveedores conquienes usted trabaja lanzan parches regularmente para repa-rar fallos críticos? Según PricewaterhouseCoopers [PWC 04],el volumen puro de cambios está en aumento, lo cual puedetener un impacto significativo en la estrategia de la gestiónde TI para administrarlos:

La aplicación y el software de sistema operativo contienenun gran número de errores y vulnerabilidades que quedanpor descubrirse más allá de las fechas de lanzamiento ori-ginales. En 1999 se informó sobre 417 vulnerabilidadesde software, según el Centro de Coordinación 4 CERT®

de la Universidad Carnegie Mellon. Para 2003, la canti-dad de vulnerabilidades reportadas había ascendido a3.784 o a aproximadamente 73 [nuevas] vulnerabilida-des por semana.

En el taller de BIC SORT, muchos participantes identifica-ron como problema crítico el volumen de parches urgentes aser aplicados en la infraestructura operativa y la ausencia deun proceso de gestión eficaz para administrarlos. Sin embar-go, el contraste entre cómo las organizaciones de alto y bajorendimiento percibieron y respondieron a este problema fuenotable. Las organizaciones de alto rendimiento implemen-taron parches en su infraestructura con una frecuenciamucho menor que las de bajo rendimiento. Más esclarecedo-ra aún resultó la comparación de los sistemas de creenciasque guiaron a la gestión de TI cuando se tomaron las decisio-nes respecto a parches.

9

GTAG — ¿Por qué debo interesarme en cómola organización gestiona el cambio? — 3

4 CERT® es marca registrada en la Oficina de Patentes y Marcas Registradas de EE. UU. por la Universidad Carnegie Mellon.

5 En el Apéndice A, Cuadro 4 (página 38) se describen algunos roles a modo de ejemplo. Además, una organización debe asegurarse de que las funcionesde los participantes del proceso estén separadas correctamente (Cuadro 5, página 38).

En las organizaciones de bajo rendimiento la implemen-tación de parches se caracteriza como de tipo ad hoc, caóticay urgente. La disponibilidad de un parche para solucionar unavulnerabilidad de seguridad crítica puede ocasionar interrup-ciones y a menudo da como resultado cantidades significativasde recursos que se redireccionan desde trabajos planeados parasolucionar el parche no planeado. Y lo que es peor aún, inclu-so la implementación exitosa del parche puede provocar pro-blemas no deseados, como el caso de servidores que se tornanno funcionales y, por lo tanto, no disponibles para entregarservicios críticos. Una investigación de directores de seguridadde la información (en inglés, CISO) pertenecientes al gobier-no federal de EE.UU., realizada por Intelligent Decisions einformada por InformationWeek [Hulme 04] calificó la inquie-tud de sostener la gestión de parches en el máximo nivel comoel problema más grande a afrontar.

La gestión de parches se ubicó en tan alta jerarquía porqueafecta a todas las partes de la infraestructura y hay tantosparches que se lanzan habitualmente que a todos les preo-cupa poder seguirles el ritmo.

En contraste, las organizaciones de alto rendimiento conside-ran al nuevo parche como un cambio planeado y predecibleen el proceso normal de gestión del cambio. El parche se agre-ga a la cola de “candidatos a la ingeniería de liberación”,donde se evalúa, se prueba y se integra a una implementaciónde liberación ya programada. Al seguir un proceso bien defini-do para integrar los cambios, se alcanza una tasa de éxito delcambio mucho más alta. Resulta interesante observar que granparte de las organizaciones de alto rendimiento aplican par-ches mucho menos frecuentemente que las de bajo rendimien-to, a veces en una proporción de una o dos órdenes demagnitud. Las de alto rendimiento ven al riesgo de la exposi-ción de vulnerabilidad menor que el riesgo de disponibilidaddebido a impactos no anticipados de un cambio erróneo ofuera de ciclo. En oposición, las organizaciones de alto rendi-miento que optan por implementar un parche como un cam-bio de alta prioridad tienen la capacidad de hacerlo de unamanera predecible y repetible a través del uso de un procesode gestión del cambio eficaz.

Las organizaciones de alto rendimiento aplican parchesmucho menos frecuentemente que las de bajo rendimiento, aveces en una proporción de una o dos órdenes de magnitud.

Dada esta visión y durante la duración de esta guía, tratamoslos parches como una categoría o clase de cambio que estásujeta al proceso normal de gestión del cambio. Así emergendos inferencias clave: la gestión de parches es una funciónsubordinada a la gestión del cambio y a menudo, un procesode gestión del cambio eficaz puede ayudar a asegurar que lastecnologías utilizadas para solucionar el problema de tipo“implemente el parche y cruce sus dedos” no creen proble-mas adicionales.

3.2 Ya tenemos un proceso de gestión delcambio ¿Cuál es la diferencia aquí?

Un aspecto clave de la gestión eficaz es que la organizacióntiene controles amplios, bien definidos, preventivos, de

detección y corrección, así como una clara definición y sepa-ración de los roles. Los controles de gestión del cambio permi-ten a la gerencia afrontar nuevos requerimientos (comonuevos proyectos de desarrollo y nuevas regulaciones guberna-mentales) sin tener que aumentar los recursos. Por lo general,la gestión del cambio eficaz mitiga el riesgo, disminuye el costoy proporciona recursos para servicios adicionales.

En oposición, la gestión del cambio ineficaz genera un ries-go alto. En la mayoría de las organizaciones no se trata de si exis-te o no un proceso de gestión del cambio, se trata de si el procesoes tan eficaz y eficiente como es posible y si se utiliza para todoslos cambios de TI. Al implementar los cambios de emergencia esextremadamente difícil evitar errores, irregularidades e interrup-ciones no buscadas. Las interrupciones en cuanto a disponibili-dad de TI (que a su vez da como resultado un servicio de bajacalidad y la insatisfacción del cliente) a menudo impulsa a lasorganizaciones a considerar e implementar procesos de gestiónde cambio y controles. Las investigaciones señalan que los depar-tamentos de TI de alto rendimiento están continuamente bus-cando formas de mejorar sus procesos operativos, incluida lagestión del cambio. Al mejorar el control y la predecibilidad delos cambios en los sistemas y las redes, su departamento de TIestará encaminado a convertirse en una organización de primernivel. Los auditores internos están en la posición ideal para ayu-dar a la gerencia a mejorar estos procesos y controles.

Si el departamento de TI no puede describir todos los cambiosy sus estados actuales, tampoco podrá describir lo que estáadministrando o si los cambios están funcionando según loplaneado.

Aunque resulta fácil hablar de la gestión del cambio, esta esuna de las disciplinas más difíciles de implementar. Requierede la colaboración entre un equipo interfuncional de progra-madores de aplicaciones, el personal de operaciones, losauditores y las personas del negocio cuyo enfoque sea los ser-vicios punto a punto. Es importante destacar que cada grupotiene un rol específico a desempeñar y que estos roles debenestar definidos en los procedimientos de gestión del cambio.5

Los auditores internos son expertos en dibujar diagramasde flujo de los procesos del negocio y en evaluar los contro-les. Están en la mejor posición para ayudar a sus organizacio-nes a ver los beneficios de mirar los procesos clave desde unaperspectiva global.

El departamento de TI debe tener la capacidad de eva-luar e informar el estado de todos los cambios en todomomento. Los procesos de gestión del cambio eficaz propor-cionan la información y el aseguramiento necesarios pararealizar el seguimiento de todos los cambios en sus diversosestados de consumación.

Por último, las metas para administrar mejor los cambiosde TI de una organización son reducir el riesgo (aquel prima-riamente asociado a la incapacidad de ejecutar las funcionesdel negocio a causa de la inactividad por una falla), reducir eltrabajo no planeado (en consecuencia, se liberan recursos res-tringidos), eliminar resultados no deseados (ocasionados porerrores u omisiones) y mejorar la calidad del servicio paratodos los clientes internos y externos.

10


3.3 ¿Cómo puede ayudar un proceso robustode gestión del cambio?

Las solicitudes del cambio surgen como respuesta a un deseode obtener beneficios para el negocio, como reducir costos omejorar los servicios, o a partir de la necesidad de corregirproblemas. La meta del proceso de gestión del cambio es sos-tener y mejorar las operaciones organizacionales. Esto se lograasegurando que se utilicen métodos y procedimientos estan-darizados para el manejo eficaz y eficiente de todos los cam-bios y minimizando el impacto de los incidentes relacionadoscon el cambio sobre la calidad y la disponibilidad.

Para proteger el entorno de producción, los cambios sedeben administrar de manera repetible, definida y predecible.Se debe prestar especial atención para asegurarse de que loscambios realizados para corregir una aplicación, servidor o dis-positivo de red no introduzcan problemas no deseados. Esto esparticularmente importante en el caso de los activos de TI(software, hardware, información) que respaldan los procesos ylos repositorios de datos críticos del negocio de la empresa.

Los procesos de gestión del cambio sólidos ayudan tam-bién a que la organización pueda sostener el cumplimientopermanente con las nuevas y amplias regulaciones. Las acti-vidades que abordan el impacto potencial de los cambios enel cumplimiento regulatorio deben incluirse dentro de lospasos de aprobación del proceso de cambio para la unidad denegocios y la gestión del riesgo. Por ejemplo, se debe prestaratención cuando se implementan cambios en la tecnologíaque respalda el proceso de preparación de reportes financie-ros para asegurar el cumplimiento constante con la LeySarbanes-Oxley. De la misma manera, puede ocurrir que loscambios en el manejo de la información de identificaciónpersonal en Europa hagan que se incumplan las directivas deprivacidad de la Unión Europea.

Los procesos de gestión del cambio eficaz se deben docu-mentar para reducir el esfuerzo constante necesario para tra-zar el mapa, validar y certificar los cambios en el proceso depreparación de reportes para respaldar el cumplimiento con laLey Sarbanes-Oxley. En el Artículo 404 de la Ley, se exigeque la gerencia valide y evalúe los controles sobre los proce-sos de preparación de reportes, incluidos los controles de TI.Los cambios sin control en el entorno de producción puedenconducir a errores que, si son generalizados o críticos, sepodrán considerar como deficiencias importantes que sedeben reportar al comité de auditoría. Se requiere que lasdeficiencias más serias denominadas “debilidades materiales”en el mundo del contador público, sean divulgadas pública-mente por las empresas a través de presentaciones ante laComisión de Valores de EE. UU. (SEC). Las revelacionespúblicas de las deficiencias pueden afectar la reputación, elprecio de las acciones y la capacidad de la organización parapermanecer en el negocio.

El Artículo 404 de la Ley Sarbanes-Oxley requiere que lagerencia valide los controles de TI. Los cambios sin controlen el entorno de producción pueden conducir a deficiencias ydebilidades materiales serias.

En el documento guía, Enfoque para evaluar excepciones ydeficiencias de control [BDO 04], las deficiencias observadasen los controles informáticos en general, como la gestión delcambio, se deben evaluar en relación con su efecto sobre loscontroles de aplicación. En particular, la debilidad del controlgeneral de TI (en inglés, ITGC) se clasifica como una “debi-lidad material” si ocurre uno o más de los siguientes:

• Una debilidad de control de aplicación causada por unadebilidad de ITGC, o relacionada con esta, se clasificacomo una debilidad material.

• La generalización y la importancia de una debilidad deITGC conduce a la conclusión de que hay una debili-dad material en el entorno de control de la organiza-ción.

• Una debilidad ITGC clasificada como deficiencia sig-nificativa permanece sin corregirse después de un perí-odo razonable de tiempo.

El año pasado, muchas organizaciones observaron serias defi-ciencias asociadas con la gestión del cambio de los controlesgenerales de TI que rodean un sector del entorno de prepara-ción de reportes financieros. Si esto sigue sin corregirse en elpresente año, estas organizaciones estarán en riesgo. Los audi-tores internos pueden ayudar a la gerencia identificando estosproblemas y colaborando para que ella se asegure de que estossean corregidos de manera oportuna.

Un modelo de aceptación general para evaluar los con-troles internos es el titulado Control interno - Marco integrado,publicado por el Comité de Organizaciones Patrocinadoras dela Comisión Treadway - (COSO) en el año 1992. En 2004,este modelo fue mejorado para proporcionar un marco de ges-tión de riesgo empresarial aceptado, que incluya principiosclave, conceptos, un lenguaje común respecto a riesgos y unaguía clara para la implementación. Esta nueva orientacióntitulada Gestión de Riesgo Empresarial - Marco Integrado[COSO 04], proporciona cuatro categorías de objetivos orga-nizacionales y ocho componentes interrelacionados de ges-tión de riesgo eficaz. En la Figura 16 (página 12) se incluyeuna ilustración de cómo se puede aplicar el modelo COSO ala gestión del cambio.

La organizaciones de alto rendimiento generalmente tie-nen una visión positiva de los controles. El caso concreto esque los procesos eficaces de gestión del cambio reducen elriesgo de convertirse en una organización de bajo rendimien-to y provocan menos problemas que, a su turno, deban serresaltados por el contador público externo (auditor de cuen-tas), el organismo de control equivalente o la autoridad revi-sora. Como resultado, la empresa tiene un Comité deAuditoría más satisfecho y se reduce la presión sobre la geren-cia del departamento de TI. Por lo general, un Comité deAuditoría satisfecho trae aparejado que todos estén más feli-ces, el máximo ejecutivo (CEO), el director financiero(CFO), el DTI y el DEA. Por último, las organizaciones quetratan los controles de gestión del cambio como posibilitado-res de conducta comercial eficaz son más exitosas. El puntoclave a recordar es que la gestión del cambio se centra en elproceso con un enfoque administrador y humano que está res-paldado por controles técnicos y automáticos.


11

6 Extraído de “Enterprise Risk Management-Integrated Framework” de COSO, septiembre 2004. El resumen ejecutivo está disponible enhttp://www.coso.org/publications/erm/coso_erm_executivesummary.pdf.

12

Figura 1: Modelo COSO ERM para la gestión del cambio

MONITORIZACIÓN

Monitorización• Mediciones de desempeño y análisis de cambio

mensuales proporcionados al Director de TI(CIO).

• Auditorías del proceso de gestión del cambio rea-lizadas por la auditoría interna.

• Autoevaluación de control anual (en inglés,CSA) realizada por las unidades de negocio y elDepartamento de TI.

• Informes periódicos de la dirección de gestión delcambio proporcionados a la alta dirección.

Información y comunicación• Mensajes periódicos de la alta dirección con res-

pecto a que el control del cambio es importante.• Se comunican los problemas con la mesa de ser-

vicio para su resolución y análisis de tendencias.• Se comunican los cambios en la política a todo el

personal que se ve afectado por ellos.• Comunicación regular de los cambios próximos a

realizarse.

Actividades de control• Proceso ordinario implementado y documentado.• Estructura del comité de control del cambio eficaz• Se utilizan registros de control del cambio.• Se mantiene una separación de las funciones de

los programadores y del personal técnico.• Controles automáticos para hacer cumplir el pro-

ceso de promover los cambios en la producción.• Proceso automático para volver el entorno de

producción a su estado anterior al cambio.• Se documentan las configuraciones aprobadas.• Se documenta la clara delegación de autoridad.• Se documentan las aprobaciones de los cambios.• Sistema automático y copias de seguridad de

datos junto a la capacidad de restaurar desde elentorno aprobado.

Evaluación de riego• Las evaluaciones del riesgo a nivel de proceso y

estrategia de la empresa tienen en consideraciónlos riesgos asociados con los cambios fuera de

proceso (no deseados o no autorizados).• El personal de TI comprende cabalmente los ries-

gos provocados por el cambio.• Se realiza una evaluación completa del riesgo de

todos los cambios propuestos.• Planificación de la continuidad de negocio

implementada.• Se realiza la evaluación de auditoría interna.• El seguro del negocio necesita que se realice una

evaluación.• Se evalúan los factores de riesgo para determinar

la clasificación del cambio y el nivel de pruebas yaprobación.

Determinación de objetivos e identificación delevento

• La gerencia establece los objetivos y estrategiasdel negocio.

• La gerencia establece los objetivos para la gestióndel cambio, identifica qué eventos pueden impe-dir el logro de los objetivos del negocio y la debi-da observación del proceso de cambio.

Entorno interno• La alta dirección demuestra que la gestión del

cambio es importante.• Presencia de una cultura de gestión del cambio

eficaz.• No hay ninguna tolerancia para los cambios fuera

de proceso, está implementado el proceso derenuncia.

• Existe la documentación pertinente (políticas, pro-cedimientos, proceso de gestión de cambios paraaplicaciones, bases de datos, sistemas operativos ycualquier otro activo de TI).

• Se proporciona capacitación sobre el proceso atodo el personal afectado por el cambio.

• Se aplican las responsabilidades y los roles definidos.• Están implementados los acuerdos de niveles de

servicio (en inglés, SLA) y contratos con provee-dores donde se definen los estándares de procesoy rendimiento.

• Están implementados los estándares y pautas anivel de la empresa para el proceso del cambio.

INFORMACIÓN Y COMUNICACIÓN

ACTIVIDADES DE CONTROL

RESPUESTA AL RIESGO

EVALUACIÓN DE RIESGO

IDENTIFICACIÓN DEL EVENTO

DETERMINACIÓN DE OBJETIVOS

ENTORNO INTERNO


En la mayoría de las empresas, el departamento de TI tienedos roles principales: 1) operar y mantener los servicios ycompromisos existentes y 2) entregar los nuevos productosy/o servicios para ayudar a alcanzar los objetivos del negocio.Esta parte describe el alcance de la gestión del cambio en res-paldo a estos dos roles, las características de gestión del cam-bio eficaz e ineficaz, el rol de la auditoría en la gestión delcambio y las mediciones que pueden contribuir para admi-nistrar el cambio con eficacia..

4.1 ¿Cuál es el alcance de la gestión del cambio?Esta guía se centra en la gestión del cambio operacional deTI que se inicia cuando se identifican actualizaciones omejoras en los activos de TI (infraestructura, aplicaciones)para su pase a producción (por ejemplo, desde un equipo dedesarrollo de aplicaciones o desde un equipo de investiga-ción y desarrollo) y finaliza cuando tales activos se retirandel entorno de producción. Esto incluye los controles demantenimiento de la aplicación y del cambio de emergencia.Se excluyen específicamente los cambios que se presentandurante el diseño y desarrollo del software.

El término gestión del cambio, tal como se utiliza en laguía, excluye el proceso de gestión de configuración. La ges-tión de configuración tiene que ver con identificar, contro-lar, mantener y verificar las versiones de todos loscomponentes de TI (hardware, software, documentaciónrelacionada) [ITIL 00]. Sin embargo, el proceso de gestióndel cambio debe interactuar con el proceso de gestión deconfiguración (y controles relacionados) cuando se efectúancambios en las configuraciones.

4.1.1 Fuentes de cambioPrácticamente, todas las decisiones comerciales requierencambios de TI. Los siguientes factores sirven como fuentesde cambio que se deben abordar y administrar con eficaciaen el entorno de TI:

• Entorno externo (mercado competitivo, partes intere-sadas/accionistas, riesgos cambiantes).

• Entorno regulatorio.• Objetivos del negocio, metas, estrategias, requerimien-

tos, procesos y cambios de prioridades.• Proveedores (nuevos productos, actualizaciones, par-

ches y vulnerabilidades).• Socios y proveedores.• Resultados de una auditoría, evaluación de riesgo y

otros tipos de evaluación y valoración.• Problemas operacionales.• Cambios en requerimientos de rendimiento o

capacidad.

4.1.2 Alcance de los cambiosUn proceso de gestión de cambio eficaz abarca dentro de sualcance todas y cada una de las modificaciones que se reali-cen a los activos basados en TI de los que dependen los ser-vicios del negocio. Entre los activos sujetos a la gestión delcambio se incluyen:

• Hardware: computadoras centrales, servidores, estacio-nes de trabajo, ruteadores, conmutadores y dispositivosmóviles.

• Software: sistemas operativos y aplicaciones.• Información, datos y estructuras de datos: archivos y

bases de datos.• Controles de seguridad: software antivirus, filtros de

seguridad y sistemas de detección/protección contraintrusiones.

• Procesos, políticas y procedimientos.• Roles/responsabilidades: autorización, autoridad para

actuar y controles de acceso.

4.1.3 Proceso de gestión del cambioHabitualmente, un proceso de gestión del cambio incluye lassiguientes actividades:

• Identificar la necesidad del cambio.• Prepararse para el cambio.

– Documentar en detalle la solicitud del cambio.– Documentar el plan de prueba del cambio.– Documentar el plan para deshacer el cambio en

caso de fallo del cambio.– Escribir un procedimiento paso a paso que incorpore

el cambio, el plan de prueba y el plan para deshacerel cambio.

– Presentar el procedimiento del cambio en forma desolicitud de cambio.

• Desarrollar la justificación comercial y obtener lasaprobaciones.– Evaluar el impacto, el costo y los beneficios

relacionados con la solicitud del cambio.– Revisar y evaluar los riesgos e impactos de la

solicitud del cambio, incluidos impactos regulatorios.• Autorizar la solicitud del cambio.

– Autorizar, rechazar o solicitar información adicionalacerca de la solicitud del cambio.

– Priorizar la solicitud del cambio con respecto a otrasque estén pendientes.

• Programar, coordinar e implementar el cambio.– Programar y asignar un implementador del cambio.– Programar y asignar un evaluador del cambio.– Probar el cambio en un entorno de preproducción.– Comunicar el cambio a las partes interesadas que

probablemente se vean afectadas.– Aprobar el cambio para la implementación.– Implementar el cambio según se solicitó.

• Verificar y revisar el cambio implementado (un pasocrítico que con frecuencia se omite).– ¿Fue el cambio exitoso?– ¿Se realizo un seguimiento sobre el proceso del

cambio?– ¿Cuál fue la variación entre el cambio que se planeó

y el que se implementó?– ¿Se mantuvieron los requerimientos de control

interno, operaciones y cumplimiento regulatorio?– ¿Cuáles fueron las lecciones aprendidas que se

pueden utilizar para mejorar el proceso?• Retirar el cambio si no tuvo éxito.• Cerrar la solicitud del cambio y comunicarlo a las par-

tes afectadas.• Efectúe los cambios acordados en el proceso de gestión

del cambio.

13

GTAG — Definir la gestión de cambio de TI — 4


Los auditores de inmediato reconocerán que la gestión delcambio eficaz exige controles preventivos, de detección ycorrección, y que la necesidad de controles independientesaumenta a medida que el entorno de producción de TI setorna más dinámico y complejo. Entre los controles preven-tivos necesarios se incluyen la separación de roles, la autori-zación del cambio, su supervisión y aplicación. Si embargo,para monitorear y aplicar el proceso con eficacia, se debenadoptar controles de detección para supervisar el entorno deproducción en relación a los cambios, conciliar estos cam-bios como cambios aprobados e informar las variaciones noautorizadas. La gestión del cambio eficaz también cumple unrol correctivo para la gestión de TI durante las interrupcio-nes y restricciones de servicio, lo cual permite que se descar-te el cambio en primer lugar en el ciclo de reparaciones, ypor consiguiente se reduzca el tiempo de reparación.

4.2 ¿Cuál es el aspecto de la gestión del cambioineficaz?

¿Cómo sabe usted si una organización tiene un proceso de ges-tión del cambio eficaz o ineficaz? ¿Qué conductas y qué otrasseñales sirven como indicadores útiles de la capacidad de laorganización o bien de su falta de capacidad al respecto?

Los indicadores de una gestión del cambio ausente o ine-ficaz aparecen como disfunciones en una variedad de dimen-siones organizacionales.

A nivel de mercado:• Oportunidades perdidas. La empresa no puede imple-

mentar los nuevos servicios y productos planeados demanera consistente. Esto ocurre cuando se tienen quecomprometer recursos para afrontar trabajos no planea-dos, como consecuencia de cambios no administrados.El trabajo no planeado se puede manifestar como tiem-po perdido/no presupuestado, recursos perdidos/no pre-supuestados (personal, capital) y como trabajo nopresupuestado.

• Los proyectos de desarrollo se retrasan y a menudo seexceden del presupuesto establecido, esto da comoresultado productos y servicios con demoras y más cos-tosos en comparación con la competencia.

A nivel de clientes/partes interesadas:• Los productos y servicios no funcionan como se anun-

cia o se espera, o bien, operan con fallos. Esto condu-ce a un producto o servicio no confiable de bajacalidad. Si los clientes pueden cambiar de proveedorfácilmente, lo harán.

A nivel de la organización:• Los cambios no autorizados, no rastreados, crean una

potencial exposición al fraude.• Los requerimientos del negocio se pueden malinterpre-

tar en relación con los cambios de TI que se requierene implementarse de manera deficiente e inadecuada.

• La organización tiene muy poca capacidad, o directa-mente ninguna, para pronosticar el impacto de un cam-bio sobre los procesos comerciales existentes.

• Dado que es poco probable que los cambios sean eva-luados en relación unos con otros, no se fijan priorida-des de cambio, lo que da como resultado que se trabajesobre los elementos equivocados o se trabaje sobre algoque es menos importante. Es probable que se realice el

trabajo fuera de la secuencia pensada con el riesgo dereprocesos y duplicación de esfuerzos.

• Es evidente un alto grado de problemas, reflejado enuna actitud de tipo “siempre nos pasa todo a nosotros”o “se pierde mucha energía en el sistema”, además nohay capacidad para controlar el entorno operacional.

• Los sistema de parches ocasionan importantes inte-rrupciones ocasionadas por fallos de los cambios que asu vez dan como resultado cortes, deterioro del servi-cio, reprocesos o trabajos no planeados. Esto a menu-do exacerba una relación de trabajo negativa o adversaentre el sector de seguridad de la información y el deoperaciones de TI.

• Grandes cantidades de los ciclos de tiempo, recursos ycapital, se emplean para corregir actividades o infraes-tructuras no autorizadas del proyecto y se quita a losciclos de las actividades planeadas y autorizadas.

• Los recursos regularmente se desvían a reprocesos,como resultado de la necesidad de afrontar las conse-cuencias no deseadas de cambios no administrados.

• Se observa una alta rotación del personal técnico yevidencias claras de “desgaste” en el personal clave.

A nivel de infraestructura de TI:• El comportamiento ad hoc, caótico y urgente requiere

de la intervención de los expertos/héroes técnicos; unalto porcentaje del tiempo se emplea en modo de“situación de emergencia” en tareas reactivas.

• Incapacidad para rastrear cambios, informar sobre elestado y los costos del cambio y presencia de cambiosno autorizados.

• Aumento de los recursos que se emplean para afrontartrabajos no planeados, a expensas del trabajo planea-do. Esto se puede describir como un bajo porcentaje deéxito del cambio. La tasa de éxito del cambio es unamedida de la cantidad de trabajo nuevo que se intro-duce cuando se implementa un cambio. Una tasa deéxito del cambio alta significa que el cambio se haimplementado según lo planeado y que no se ha intro-ducido trabajo adicional como resultado del cambio.En oposición, una tasa de éxito del cambio baja impli-ca que un cambio inesperadamente introduce trabajono planeado adicional, a veces, por encima del trabajorequerido para implementar el cambio original. Unatasa de éxito del cambio baja puede producir una espi-ral descendente que consume recursos excesiva y con-tinuamente.

• Una TI ineficaz interactúa con sus iguales(Investigación y Desarrollo, programadores de aplica-ciones, auditorías, seguridad, operaciones) que gene-ran barreras e introducen demoras innecesarias.

• Una cantidad numerosa de cambios no documentadosque se suceden a través del tiempo aumenta la varia-ción de producción de configuración dando comoresultado tasas de éxito del cambio bajas y aumentan-do la dificultad de implementar parches sin que ocu-rran fallos de cambios ni trabajo no planeado.

14


15

4.3 ¿Cuál es el aspecto de la gestión del cambioeficaz?

¿De qué manera puede reconocer una gestión de cambio efi-caz al verla? ¿Puede entrar a una organización y determinaren 15 minutos si el proceso de gestión de cambio es eficaz?

Los indicadores de una gestión de cambio eficaz apare-cen como una capacidad madura (predecible, repetible,administrada, mensurable, medida) en una variedad dedimensiones organizacionales.

A nivel de mercado:• La empresa está en posición de actuar en nuevas opor-

tunidades de negocios que requieren una capacidad deTI adicional o actualizada. Cada oportunidad se planeay administra de una manera predecible. Los recursosadecuados se pueden comprometer con la seguridad deque son suficientes, y de que están basados en un ren-dimiento histórico rastreado.

• Los productos y servicios respaldados por la TI se lan-zan al mercado según lo planeado y esperado.

A nivel de clientes/partes interesadas:• Los productos y servicios funcionan tal como se anun-

ció y muestran un nivel de calidad de servicio y pro-ducto confiable y uniforme. Los problemas y reclamosde los clientes se tratan de manera oportuna. Los clien-tes por lo general se sienten satisfechos y son leales a laorganización.

• Hay una disminución de la demanda de recursos queofrecen los centros de asistencia/mesa ayuda al cliente.

• Las partes interesadas apropiadas están involucradasen la evaluación de los riesgos asociados a los cambiospropuestos y priorizan su implementación.

• Los participantes del proceso de cambio comprendenlas categorías y prioridades relevantes de los cambios ylos niveles de rigor y formalidad requeridos para imple-mentar cada uno de ellos.

• Hay una postura de cumplimiento debido a la naturale-za básica de la administración del cambio.Prácticamente, toda regulación tiene requerimientos deTI y como resultado, puede crear un nuevo proyectopara los equipos de cumplimiento y seguridad. Cuandolos controles están bien documentados, el cumplimien-to con una nueva regulación no es un proyecto nuevo,sino simplemente una actividad de mapeo.

A nivel de empresa:• La cultura de la gestión del cambio se hace evidente en

el entendimiento, la conciencia, el patrocinio visible yla acción.

• Regularmente, se realizan compensaciones eficacesque equilibran el riesgo y el costo del cambio en rela-ción a la oportunidad. Los cambios se programan ypriorizan en consecuencia. Existe una capacidad parapredecir el impacto del cambio en el negocio. SegúnBITS [BITS 04]:

Con frecuencia, determinar el grado de aceptación deriesgo de una empresa es el paso más difícil en la imple-mentación de una estrategia de gestión del cambio. Laspersonas que tienen a su cargo la responsabilidad delproceso de gestión del cambio deben entender el grado detolerancia al riesgo de su organización con respecto a lainstalación de parches, a la vez que deben ayudar a

identificar dichos parches y distribuirlos en la organiza-ción utilizando la calificación de severidad de la organi-zación como guía.

• Los recursos (tiempo, esfuerzos, dólares, capital) seaplican para implementar los cambios seleccionadoscon poco esfuerzo desperdiciado o casi ninguno (altatasa de éxito del cambio); los recursos raramente sedesvían al trabajo no planeado.

• La organización puede responder con seguridad a laspreguntas: “¿Estoy haciendo las cosas correctas?”(capacidad para seleccionar y dar prioridades) y“¿Estoy haciendo las cosas correctamente?” (con unacalidad y un desempeño aceptables).

• Un proceso de gestión del cambio eficaz se evidenciapor la aplicación/adherencia y disciplina de un proce-so riguroso, en la capacidad de tomar decisiones demanera centralizada y en la colaboración y comunica-ción entre los departamentos.

• Se trazan mapas de los proyectos autorizados según lasórdenes de trabajo y viceversa.

• Las inversiones para cumplimiento y seguridad se sos-tienen porque las configuraciones de producción no sedesvían a estados no seguros y de incumplimiento. Enconsecuencia, el costo de seguridad y cumplimiento esmucho más bajo.

• Progresivamente, se destinan más tiempo y más recur-sos a problemas de TI estratégicos dado que la organi-zación ya tiene bajo control sus inquietudes tácticas(operacionales del día a día).

• La gestión del cambio eficaz sirve como control esen-cial del gobierno de TI.

A nivel de infraestructura de TI:• Los controles de gestión del cambio (incorporados en los

procesos operacionales de TI bien definidos) se utilizanpara ayudar a garantizar la uniformidad y predecibilidadnecesarias para lograr las metas del negocio que a su turnoconfían en estos procesos. En otras palabras, el personalde TI entiende cómo la gestión del cambio eficaz respal-da la tarea de cumplir con los objetivos comerciales.

• Una cultura de gestión del cambio se perpetúa a travésde una combinación de matices en los niveles más altosy de controles preventivos, de detección y corrección,que sirven para impedir futuros cambios no autorizados.La gerencia explícitamente establece que el úniconúmero aceptable de cambios no autorizados es “cero”.

• Presenta una tasa de éxito del cambio alta, lo que dacomo resultado la ausencia de trabajo no planeado o siexiste, en una cantidad al menos mínima. La ausenciade urgencias y la existencia de un proceso bien defini-do para integrar los cambios conduce a una tasa deéxito del cambio mucho más alta.

• Los controles del cambio eficaz se han implementado,se informan con regularidad y se auditan con facilidad.Los controles preventivos están bien documentados yse ejecutan de manera consistente, los controles dedetección se utilizan para supervisar, vigilar y conciliarlos cambios según las órdenes de cambio autorizado.Los controles son favorables para el muestreo sustanti-vo de los auditores y se requiere poca o casi ningunainformación adicional de la gerencia de TI.

• La variaciones en las configuraciones de producción sedetectan con anticipación de manera de incurrir en elmínimo costo posible y provocar el mínimo impacto.

• La empresa regularmente demuestra la excelencia ope-racional con respecto a la gestión del cambio.

• Los niveles altos de servicio (alto grado de disponibili-dad,tiempo productivo y tiempo medio entre fallos;bajo grado de tiempo medio para detectar problemas eincidentes y para las reparaciones) tienen lugar en pre-sencia de procesos bien definidos que introducen cam-bios planeados y predecibles.

• Cuando surgen problemas con un nuevo cambio oconfiguración, TI tiene la capacidad de restablecerrápidamente los sistemas al estado operacional confia-ble y conocido.

• TI ostenta estructuras de costo inusualmente eficientes(una proporción de servidores con respecto a adminis-tradores de sistema de 100:1, o incluso un valor másalto, en comparación con el correspondiente a lasorganizaciones de bajo rendimiento, con una cifra,como mínimo, inferior en una orden de magnitud).

• Resolución e identificación oportuna de los problemasoperacionales, incluidos los incidentes de seguridad.

• La organizaciones que poseen procesos de gestión delcambio eficaz y controles al respecto afrontan los par-ches de una manera predecible y planeada, que estásujeta a los mismos procesos y análisis que cualquierotro cambio. Los parches se agregan a la cola “candi-dato de ingeniería de liberación”, donde se evalúan,se prueban y se integran a una implementación deliberación ya programada.

• Los controles preventivos y de detección son automá-ticos y permiten la preparación de informes másexactos y sencillos para los auditores, requieren menor

cantidad de inspecciones manuales y muestreos sustan-tivos que se asemejan a los de “arqueología”.

• Las organizaciones más eficaces aplican parches conmenor frecuencia que la norma, tal vez en una propor-ción de un orden de magnitud, aceptan que el riesgo dela exposición a la vulnerabilidad puede ser menor queel riesgo a la disponibilidad debido a los impactos noanticipados ocasionados por un cambio erróneo fuerade ciclo. Sin embargo, en el caso de una actualizacióncrítica, las organizaciones capaces pueden implemen-tar un parche fuera de ciclo con un riesgo mínimo.

Para tener un proceso eficaz, las partes interesadas no parti-cipan únicamente en la evaluación de los riesgos relaciona-dos con los cambios propuestos y en el establecimiento deprioridades para la implementación del cambio. Una de lasbarreras que con frecuencia deben afrontar los departamen-tos de TI cuando tratan de desarrollar un proceso de gestióndel cambio robusto es la falta de interés, compromiso ypatrocinio de sus contrapartes del negocio. Los gerentes deunidades de negocio deben involucrarse activamente entodo el proceso, desde la identificación inicial de sus necesi-dades hasta la realización de la mayoría de las pruebas deaceptación por parte del usuario, e incluso la aprobación delos cambios que se incorporarán en producción. Estos puntosde contacto críticos tienen más probabilidades de ocurrircuando el rol del gerente de negocio está incluido en las polí-ticas y procedimientos relevantes, y los gerentes de rangosuperior ponen el énfasis apropiado en el hecho de ser copro-pietarios del proceso antes que meros observadores. Lacomunicación y colaboración entre TI y las unidades denegocio son críticas para lograr un proceso eficaz.


16

Cuadro 1: Mediciones de la gestión del cambio7

Mediciones e indicadores PautasCantidad de cambios autorizados por semana segúnmedición del registro de la gestión de cambio de los cambiosautorizados.

En general, una mayor cantidad de cambios indica más cam-bios de productividad, siempre que la tasa de éxito del cam-bio sea alta. La tendencia (ascendente, descendente oestable) debe tener sentido en el contexto del negocio.

Las organizaciones de alto rendimiento pueden sostener hastamás de 1.000 cambios exitosos por semana.8

Cantidad de cambios reales efectuados por semana segúnmedición por parte de los controles de detección, comomonitorización de software.

La cantidad de cambios realmente implementados en lasemana no debe exceder la cantidad de cambios autorizados.

Cantidad de cambios no autorizados.

Estos son cambios que soslayan el proceso del cambio. Semiden tomando la cantidad de cambios reales efectuadosmenos la cantidad de cambios autorizados.

Si no se tienen controles de detección, no se puede realizarninguna medición confiable de los cambios reales. En tal caso,la cantidad de interrupciones no planeadas se puede utilizarcomo medición sustituta.

Cuanto más bajo su valor, mejor, pero por lo general, el úniconúmero aceptable de cambios no autorizados es “cero”, uncambio aislado puede destruir una operación completa ocrear un riesgo material.

Una gran cantidad de cambios no autorizados indica que “laverdadera forma de hacer cambios” es mediante la omisióndel proceso de gestión de cambios.

Las organizaciones de alto rendimiento tienen una cultura degestión del cambio y, por consiguiente, declaran que no tole-ran ningún cambio no autorizado [Kim 03].

7 En el Apéndice A, página 32, se incluyen más definiciones sobre estas mediciones e indicadores.8 Comparación (benchmarking) realizada por el Instituto de Procesos de TI (IPTI).

17


La tasa de éxito del cambio, definida como los cambiosimplementados con éxito (esos que no ocasionaron interrup-ciones, deterioros de servicios o un episodio de trabajo noplaneado), como porcentaje de los cambios reales realizados.

Cuanto más alta, mejor. Cuando los cambios no se adminis-tran ni se realizan las pruebas adecuadas sobre ellos, las tasasde éxito del cambio, por lo general, están en un valor del70%.

Las organizaciones de TI de alto rendimiento no sólo alcanzantasas de éxito del orden del 99% con regularidad, sino que loscambios fallidos rara vez provocan interrupciones del servicioo trabajos no planeados.

Cantidad de cambios de emergencia (incluidos parches) deter-minada por la cantidad de cambios que requirieron de la apro-bación urgente en la semana mediante el uso de la comisiónde revisión del cambio o el proceso de cambio de emergencia.

Cuanto más bajo, por lo general, es mejor. La presencia demuchos cambios de emergencia indica que la “verdaderaforma de hacer cambios” es mediante el uso del proceso decambios de emergencia, sea por comodidad o rapidez.

Los cambios de emergencia, generalmente, tienen un porcen-taje de fallos más alto y generan trabajos no planeados oreprocesos. Un aumento en los cambios de emergencia pro-bablemente indique que hay otros problemas de gestión decambios que está ocasionando tal incremento.

Las comparaciones del IPTI detectaron que cuando loscambios de emergencia representan más del 10% del totalde cambios, la organización, casi con certeza, es de bajo ren-dimiento. Concretamente, dos organizaciones que tuvieronfallos de TI que ocuparon la primera plana de las noticiasestaban efectuando de urgencia más del 25% de sus solicitu-des de cambios.

Porcentaje de parches implementados en las versiones desoftware planeadas. Cuando los parches se implementan enversiones de software planeadas, no provocan interrupcio-nes en producción y tienen tasas de éxito del cambio muchomás altas.

Cuanto más alta, por lo general, mejor.

Paradójicamente, la organizaciones de TI de alto rendimientocon frecuencia tienen una tasa de implementación de parchesmuy baja. Durante las sesiones de BIC SORT, dos de las organi-zaciones de alto rendimiento afirmaron que ellos optaban porimplementar parches con una frecuencia anual, a pesar de efec-tuar miles de cambios por semana. Con frecuencia, mitigan losriesgos de vulnerabilidad sin requerir cambios en los sistemasde producción (por ejemplo, eliminando la vulnerabilidad en unfiltro de seguridad).

Porcentaje de tiempo empleado en trabajo no planeado. Eltrabajo planeado es tiempo que se emplea en proyectos ytareas autorizadas. El trabajo no planeado incluye ciclos decortes/correcciones, reprocesos y cambios de emergencia..

Cuanto menos mejor.

De acuerdo a las 11 organizaciones de IT de alto rendimientoque estudió el IPTI todas empleaban menos del 5% de sutiempo en trabajos no planeados. Por el contrario, centenaresde organizaciones empleaban del 30% al 40% de su tiempoen trabajos no planeados.

Porcentaje de proyectos entregados más tarde de loplaneado.

Cuanto más bajo, por lo general, es mejor. Cuando las organi-zaciones emplean todo su tiempo en trabajos no planeados,a menudo no disponen del tiempo suficiente para trabajar enlos trabajos planeados, como por ejemplo, en los nuevosproyectos y servicios. Por consiguiente, eso hace que los pro-yectos se entreguen con retrasos.

Cuadro 1: Mediciones de la Gestión del Cambio (continuación)

4.4 Mediciones e indicadores de la gestión delcambio

Los auditores internos deben determinar si estas medicionesclave de gestión del cambio se están utilizando para vigilar laeficacia del proceso e impulsar el valor de negocio. Las medi-ciones enumeradas en el Cuadro 1 de las páginas 16 y 17 sonindicadores útiles de un proceso de gestión del cambio eficaz.

La Figuras 2 y 3 muestran los indicadores clave de la ges-tión del cambio eficaz y los controles dominantes que losincrementan o los disminuyen. Los indicadores clave9 son:

• Cantidad de cambios de producción.• Porcentaje de esos cambios que fallan o no están auto-

rizados.• Intervalo de tiempo requerido para recuperar el cam-

bio fallido.Cuando estas tres variables se multiplican en conjunto, elresultado es trabajo no planeado.

Este es un modelo extremadamente simple y no preten-de ser matemáticamente correcto. Su objetivo es mostrar lasvariables dominantes y los indicadores líderes para la gestióndel cambio de TI eficaz y, en consecuencia, una TI eficaz:

• Cuando una organización de TI no realiza cambios o se

encuentra en un período de congelación de cambios, ladisponibilidad está en su punto más alto y el trabajo noplaneado en su punto más bajo.

• Cuando una organización de TI no aplica las políticas degestión del cambio (por ejemplo, cuando los controlespreventivos y de detección son inadecuados), los cambiosfallidos y no autorizados ocasionan interrupciones pro-longadas que, a su vez, generan trabajos no planeados.

• Cuando las organizaciones de TI tienen una propor-ción alta de trabajo no planeado con respecto a traba-jo planeado, disponen de menos tiempo para realizar eltrabajo específico de su tarea, como por ejemplo,entregar nuevos productos y servicios.

Las organizaciones de TI de alto rendimiento se desempe-ñarán incluso mejor que lo que sugiere este modelo. Cuandolos cambios se administran correctamente, incluso los cambiosplaneados fallidos raramente ocasionan una interrupción delservicio y, en consecuencia, el tiempo medio para reparacioneses “cero”. Por el contrario, las organizaciones de bajo rendi-miento a menudo no pueden medir más que las interrupcionesobvias y los trabajos no planeados.


18

Figura 2: Trabajo no planeado como indicador de proceso de gestión del cambio eficaz

Cantidad decambios en producción

Porcentaje de cambiosfallidos o cambios no

autorizados

Tiempo mediopara

reparaciones

Porcentaje del tiempoempleado en trabajos no

planeadosX X =

Organizaciones de altorendimiento >1000 cambs/sem < 1% Minutes < 5% del tiempo

Organizaciónpromedio

No se conoce,centenares

~30 - 50%(Promedio)

Horas, Días 35 - 45% deltiempo

Figura 3: Variables clave que influyen sobre los procesos de gestión del cambio

ORGANIZACIÓN PROMEDIO: 35 - 45% del tiempo (y los gastos operacionales) se emplean en trabajos no planeados.

IMPACTO: proyectos demorados, reprocesos, problemas de cumplimiento, variaciones no controladas, etc.

Cantidad decambios enproducción

Porcentaje de cambiosfallidos o cambios no

autorizados

Tiempo mediopara

reparaciones

Porcentaje del tiempoempleado en trabajos

no planeadosX X =

COMPORTAMIENTOS QUE AUMENTAN LA TASA DE ÉXITO DEL CAMBIO:• Pruebas eficaces de los cambios.• Revisión de riesgo eficaz al aprobar los cambios.• Identificación eficaz de los participantes del cambio.• Programación eficaz de cambios.COMPORTAMIENTOS QUE REDUCEN LOS CAMBIOS NO AUTORIZADOS:• Cultura de gestión del cambio.• Sentido de propiedad del proceso del cambio por parte de la gerencia.• Monitorización eficaz de la infraestructura con controles de detección para poner en

práctica el proceso del cambio.• Uso de acciones correctivas por parte de la gerencia cuando no se siguen los procesos de cambio.• Separación eficaz de las funciones mediante la adopción de restricciones respecto a quién puede

implementar cambios.

COMPORTAMIENTOS QUE DISMINUYEN ELTIEMPO PROMEDIO DE REPARACIÓN:• Cultura de contingencias: se desea descartar el cambio

en primer lugar en el ciclo de reparaciones.• Proceso de gestión del cambio eficaz que puede

informar sobre cambios autorizados y programados.• Capacidad de distinguir entre eventos de interrupción

planeados y no planeados.• Comunicaciones eficaces acerca de los cambios

programados.• Monitorización eficaz de la infraestructura para

los cambios de producción.

9 Sobre la base de las comparaciones del IPTI que analizó 11 organizaciones de TI de alto rendimiento y encuestó a centenares de distintas organizaciones.

4.5 Integración de la Gestión de parches a laGestión de de cambios

A pesar de la urgencia que conlleva la aplicación de parchesde software, la implementación de parches idealmente debepertenecer a los procesos de preproducción, donde los par-ches se pueden probar adecuadamente en un entorno depuesta en escena. Estos parches se implementan como partede una versión de software programada.

La implementación de parches es una operación riesgo-sa por diversas razones. Los parches tienden a afectar amuchas bibliotecas de sistemas críticos y a otros software uti-lizados por diversos programas de aplicación. Tienden aintroducir grandes cambios, con frecuencia, con poca docu-mentación que describa específicamente qué es lo que dichosparches modificarán. Además, suelen ser operaciones com-plejas y de gran tamaño. Incluso, hasta las variaciones peque-ñas de configuración pueden provocar resultadosdrásticamente diferentes. Estos factores hacen que la tasa deéxito del cambio para los parches sea mucho más baja quepara los cambios típicos, y por lo tanto requieren la realiza-ción de pruebas más amplias. Cuando no se realizan las sufi-cientes pruebas y planificación, invariablemente aparece eldilema de “implemente el parche y cruce los dedos”.

Este fenómeno está bien documentado, se refiere alhecho de que ni la implementación del parche ni su noimplementación parecen lograr el objetivo de crear una pla-taforma informática segura y disponible. Tal como se descri-bió anteriormente, las organizaciones de TI de altorendimiento implementan parches con mucha menor fre-cuencia que las organizaciones de TI típicas, y aun así logranla postura de seguridad deseada. Es incorrecto suponer queadoptan esa decisión a costa de la seguridad. Más bien, admi-nistran con eficacia el riesgo residual y utilizan controlescompensadores en lugar de implementar parches.

Los ejemplos de cómo se deben evaluar las solicitudes deimplementar parches en los sistemas de producción incluyenlas siguiente preguntas [ITPI 04]:

• ¿Constituye una amenaza material para nuestra capaci-dad de entregar un servicio seguro y confiable para elnegocio?

• ¿Podemos mitigar esta amenaza sin aplicar el parche ola actualización?

• ¿Podemos realizar una prueba del impacto de la actua-lización y sentirnos seguros de que nuestras pruebasservirán para predecir el resultado en nuestros sistemasde producción?

• ¿Cuándo es el próximo ciclo de versiones? ¿Podemosponer en el mismo paquete esta actualización con otrasactualizaciones probadas?

• Si necesariamente tenemos que hacer esto ahora,¿cómo podemos minimizar el riesgo de consecuenciasinesperadas?

• Si no podemos reducir el riesgo de exposición median-te pruebas y no podemos empaquetar esto con otrasversiones, ¿podemos lograr que las partes interesadas yla gerencia de TI aprueben formalmente el riesgo?

Genere un programa de versiones que logre los objetivos

anteriores, intente empaquetar los parches y actualizacionesdentro de una misma versión, en lugar de aplicar parchesindividuales en los sistemas individuales.

Muchas de estas mediciones también están identificadasen el trabajo finalizado en Noviembre de 2004 y realizado porCorporate Information Security Working Group's, BestPractices and Metrics Team (Equipo de mediciones y mejoresprácticas del Grupo de trabajo de seguridad de la informacióncorporativa). Este trabajo fue contratado por el Comité deReformas Gubernamentales de la Cámara de Representantesde EE. UU., Subcomité de Tecnología, Política de la informa-ción y Relaciones Intergubernamentales y Censo.10

Por último, los riesgos relacionados con el cambio no serestringen a la mera aplicación de los parches, sino que se pue-den generalizar a cualquier tecnología de implementación decambios automática. John Gall concisamente escribió acercadel desafío de la automatización: “El advenimiento de la revo-lución informática simplemente proporciona nuevas oportu-nidades de errores a niveles de complejidad y grandiosidad queanteriormente no eran posibles”. [Gall 86]

El uso de la gestión de parches y de las tecnologías deimplementación de cambios a la vez hace que el entorno deproducción sea más complejo y dinámico: el número de vec-tores de cambios aumenta así como el número de cambiosque se pueden realizar. Estos entornos requieren: 1) contro-les preventivos adicionales para reducir la posibilidad decambios no autorizados y 2) controles de detección indepen-dientes para simplificar las funciones de monitorización,conciliación y preparación de informes.

4.6 Principios de guía: cómo decidir si se debenimplementar los cambios, cuándo y cómo

Los principios de guía sobre cómo tomar buenas decisionesde gestión del cambio implican plantearse las siguientes pre-guntas:

• ¿El cambio es realmente necesario? Las organizacionesde TI tienen la menor cantidad de trabajos no planea-dos y de situaciones de emergencias en los períodos decongelación de cambios. Por consiguiente, cualquiercambio debe garantizar no sólo los esfuerzos de prepa-ración e implementación del cambio, sino también lasconsecuencias (a menudo, imprevistas) de realizarlo.

• Cuando no hay cambios permitidos, ¿los períodos decongelación de cambios y mantenimiento programadoestán igualmente definidos? Los períodos de estadoestático no sólo son los más estables, sino también losmás productivos y, por consiguiente, se deben definir yaplicar.

• Si necesariamente se deben efectuar cambios, ¿cómo seasegura de que sean exitosos? Los cambios no probadosrara vez tienen una tasa de éxito superior al 70%. Lasorganizaciones comprometidas con la implementaciónexitosa de cambios deben invertir tiempo y recursospara realizar las pruebas adecuadas.

• Cuando se deben implementar cambios, ¿se programanen grandes lotes? La variación crea riesgo y este sepuede reducir mediante el empaque de varios cambios

19


10 La información sobre este esfuerzo está disponible en http://reform.house.gov/TIPRC/News/DocumentSingle.aspx?DocumentID=3030. El informe delGrupo del mes de noviembre de 2004 se puede consultar en http://www.educause.edu/LibraryDetailPage/666&ID=CSD3661.


20

juntos que se pueden probar e implementar simultáne-amente. Esto da como resultado períodos más prolon-gados de estado operacional estático de preservación ya la vez tiempos de implementación de cambios másbreves y más productivos.

• ¿Las variaciones se informan con regularidad a la geren-cia de TI? ¿Se están conciliando los cambios de produc-ción con trabajo autorizado? ¿Se documentan lasinterrupciones no planeadas y las variaciones del cambioy se actúa en consecuencia? ¿Los informes que muestranel efecto de los controles preventivos y de detección sonde fácil acceso para la gerencia y los auditores? Cuandolos controles funcionan correctamente, no solamente elproceso de auditoría de cambio funciona más eficiente-mente, sino que también es más probable que la gerenciade TI alcance sus objetivos comerciales.

21

Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo

Preguntas al Gerente de TI Gerente de TI con gestión decambio eficaz

Gerente de TI con un estilode modo de resolución de

problemas

Gerente de TI en posibleestado de negación

“La gestión del cambio esmuy importante. ¿Ustedpiensa que tenemos unproceso de gestión de cam-bio eficaz?”

“Los nuestros son de prime-ra clase. Incluso, estamospreparados para cumplircon los requerimientos de laSección 404 de la LeySarbanes-Oxley puesto quetodos los controles estánimplementados. Hemostenido que generar algunosinformes más para mostrarlos mapas de los controles,pero estamos en buenascondiciones”.

“Es curiosa la pregunta,estamos trabajando en eso,al igual que todos los queestán sujetos a la Sección404 de la Ley Sarbanes-Oxley. Lo sabremos mejor amedida que avancemos enesa dirección”.

“Tenemos un proceso queparece que funciona. No heoído comentarios negativosacerca de nuestro procesode gestión del cambio, con-cretamente, auditoría no hadicho nada al respecto. Nopodemos afrontar los gastosindirectos de un procesoengorroso para corregir algoque ya funciona”.

“¿Cuál es la cantidadaceptable de cambios noautorizados?”

“La única cantidad aceptablede cambios no autorizadoses “cero”. Un cambio aisladopuede destruir una opera-ción completa: por esarazón conciliamos los cam-bios diariamente.Confiamos, pero siempreverificamos”.

“Bueno, si usted lo preguntade esa manera, es evidenteque la cantidad aceptablede cambios no autorizadoses cero. ¿Pero, apostaría-mos nuestras bonificacionesdel trimestre asegurandoque eso se cumple? Enabsoluto. En particular, des-pués del último trimestre”.

“Mire, no nos pagan paraque no hagamos cambios. Aveces, tenemos que que-brantar las reglas. Esa es laforma en que realmentehacemos los trabajos aquí.La gestión del cambio esburocrática y sólo deseandesaceleran las cosas”.

“Describa qué controlesnecesita en su proceso degestión del cambio”.

“Solicitamos los controlespreventivos, de detección yde corrección que son nece-sarios para proporcionar a lagerencia una visión exactadel trabajo que se está reali-zando. Hemos definido algu-nas nuevas mediciones delcambio y hemos identificadoa determinadas partes intere-sadas que debemos involu-crar en nuestro comité degestión del cambio. No sabí-amos en absoluto que a loscontadores realmente lesconcernía la gestión del cam-bio, ahora, ellos participaránen nuestras reuniones”.

“Tenemos un equipo com-pleto de auditores internos yconsultores que están tra-bajando en el proyecto rela-cionado con la LeySarbanes-Oxley. Ellos estándefiniendo y creando unplan para probar los contro-les específicos. Todo el pro-yecto Sarbanes-Oxley revelóla necesidad de una pers-pectiva integrada y unavisión empresarial del cam-bio. Además, detectamosalgunos procesos de nego-cios que necesitan mejorcontrol de cambios y esta-mos trabajando también enesa dirección”.

“Aún estamos en la fase deanálisis. Estamos simple-mente demasiado ocupadoscon las urgencias del nego-cio y para lo único quehemos tenido tiempo espara el tema de controlesrespecto a la Ley Sarbanes-Oxley. Pero sabemos que esimportante y vamos a traba-jar en eso apenas podamos.Además, actualmente notenemos presupuesto paraese trabajo. Mi experienciame indica que lo que tene-mos, probablemente, seasuficientemente bueno por-que nadie me ha dichoespecíficamente que el pro-ceso actual es inadecuado”.

GTAG — ¿Qué preguntas debo hacer sobrela gestión de parches y cambios? — 5

En esta sección ofrecemos un conjunto de preguntas que losauditores pueden utilizar para comprender de qué manera seadministran los cambios con eficacia. El objetivo de esta sec-ción es proporcionar buenas preguntas y una orientaciónacerca de cómo interpretar las respuestas típicas de los distin-tos arquetipos de gerentes de TI que tienen diferentes visio-nes acerca de la importancia de la gestión del cambio eficaz.

Los arquetipos más habituales son:• Gerente de TI que tiene un proceso de gestión de cam-

bio eficaz.• Gerente de TI que tiene un proceso de cambio inefi-

caz, pero que trabaja en mejorarlo (en el modo de solu-ción de problemas).

• Gerente de TI que tiene un proceso de cambio ineficazy no tiene planes de cambiarlo (en estado de negación).

Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo (continuación)

Preguntas al Gerente de TI Gerente de TI con gestiónde cambio eficaz


problemas

Gerente de TI en posiblenegación

“¿Hemos visto beneficios apartir del proceso de gestióndel cambio?”

“Rotundamente. En realidad,los beneficios han sido tanevidentes que hemos creadouna cultura interna de gestiónde cambios. Ya no nos senti-mos como bomberos profe-sionales. Hemos mejoradosustancialmente nuestrodesempeño, grado de tiempoproductivo y de satisfacciónpor parte de nuestros clientes,y en relación con nuestro per-sonal interno y en toda lalínea ascendente de ejecutivosde la empresa”.

“Sí, pero aún no estamosdonde deseamos estar.Hemos reducido la cantidadde interrupciones y hemosincrementado nuestra tasa deéxito del cambio de manerasignificativa. Ahora, los cam-bios ocurren dentro de la ven-tana de mantenimiento,aunque aún tenemos el oca-sional 'cowboy' que se olvidade seguir el proceso”

“El ritmo del negocio es tanalto en estos momentos quesimplemente no tenemostiempo de seguir un procesode gestión de cambio fastidio-so que reduce la velocidad delas tareas, disminuye la pro-ductividad y crea una atmós-fera burocrática. No siempreresponsabilizo al personal porno seguir el proceso del cam-bio porque ellos ya están allímite de sus posibilidades tra-tando de mantener este lugaren funcionamiento. No obs-tante, las interrupciones ocu-rren ocasionalmente ysabemos que no podemosseguir colapsando el sistemade gestión de órdenes”.

“¿Recuerda la interrupción queafectó a todo el sitio durantela semana pasada como con-secuencia de un cambio?¿Qué fue lo que ocurrió?”

“Pudimos determinar que elcambio en particular que pro-vocó la interrupción de 10minutos estaba autorizado.Sin embargo, no pudimosanticipar el efecto corrienteabajo en un sistema no rela-cionado. Esto no volverá asuceder”.

“Detectamos que un programa-dor migró un cambio sin seguirnuestros procesos aprobados.Nunca se le debió haber otor-gado la autoridad de aproba-ción para los cambios en esesistema específico. Corregimosesto apresuradamente y esteprogramador ya no podrá nisiquiera conectarse a los servi-dores de producción”.

“Detectamos que uno de nues-tros proveedores estaba reali-zando algunas tareas demantenimiento y actualizandodeterminado software. El pro-blema fue que sobrescribieronuna biblioteca que nosotroshabíamos personalizado. Sesuponía que ellos debían llevarun registro de nuestras perso-nalizaciones, como no fue así,esta fue una violación a nuestrocontrato de mantenimiento”.

“Cuando usted estaba traba-jando para solucionar la inte-rrupción, ¿cuál fue el procesoque utilizó para identificar elerror?”

“Lo primero que hacemossiempre es descartar los cam-bios autorizados, tan anticipa-damente como sea posible enel ciclo de reparaciones.Supimos de inmediato que lainterrupción no se debió a uncambio programado. Luego,verificamos los cambios deproducción de emergencia.Identificamos cuatro cambiosque se realizaron dos minutosantes de la interrupción ydetectamos quiénes los hicie-ron. Estos realizaron una res-tauración y estuvimosnuevamente en funcionamien-to en sólo minutos”.

“Teníamos un presentimientofuerte de que el problema noprovenía de un cambio autori-zado. Probamos e implemen-tamos nuestros cambiosúnicamente dentro de venta-nas de lanzamientos específi-cas. Entonces, comenzamos ainvestigar revisando los regis-tros, trabajamos hacia atrástomando como punto de par-tida la interrupción y busca-mos todo lo que estuvierafuera de la ventana.Finalmente, encontramosquién había realizado el cam-bio pero no supimos porquése había realizado tal cambio.Creo que el administradoraprendió una lección muyvaliosa ese día”.

“Dado que no tenemos unproceso centralizado, variosequipos por separado semovilizaron para tratar dedescubrir cuál era el error.Finalmente, armamos un equi-po SWAT. Rápidamente,pudieron descubrir que lainterrupción fue ocasionadapor la actualización del prove-edor, pero tuvimos que esta-blecer una conferenciatelefónica con ellos parapoder identificar que la causahabía sido nuestra biblioteca.No hubo manera de volver labiblioteca a su versión ante-rior, entonces, tuvimos querestaurar todo el directorio delsoftware desde una cinta”.

22


Preguntas al Gerente de TI Gerente de TI con gestión decambio eficaz


problemas

Gerente de TI en posibleestado de negación

“¿De qué manera lleva unavigilancia general del buenfuncionamiento delproceso?”

“Mediante la tasa del cam-bio, la tasa de éxito del cam-bio; el tiempo medio dereparación (en inglés,MTTR), el tiempo medioentre fallos (en inglés,MTBF) y un conteo de loscambios no autorizados queomiten el proceso. Además,tenemos una medición decobertura para mostrar quépartes de la empresa noparticipan en el proceso. Eltrabajo no planeado es unexcelente indicador. Siemprebuscamos las variaciones ytratamos de ver cómopodemos reducirlas en suorigen”.

“Medimos con qué rapidezimplementamos un cambio.Medimos el tiempo medioentre la solicitud del cambioy su cierre. Nos estamospreparando para medir latasa de éxito del cambio asícomo los cambios de emer-gencia y los cambios no pla-neados”.

“No utilizamos medicionescaprichosas, aunque insisti-mos definitivamente en laexcelencia del proceso. Séque tenemos muchos incen-dios que combatir, pero austed también le ocurriría situviera que trabajar conalgunas de estas personas”.

“¿Cuál es la meta de suproceso de gestión delcambio?”

“Confiabilidad, disponibilidady reducción de costos. Dosde esos valores deben incre-mentarse mientras el tercerodebe reducirse. Tratar deoptimizar sólo uno de lostres nos dejaría fuera delnegocio”.

“Deseamos efectuar tantoscambios como el negocio lorequiera. Deseamos imple-mentarlos con rapidez yexactitud”.

Nuestra meta es captar laatención de todos los parti-cipantes clave en las reunio-nes de gestión del cambio yasegurarnos de que todosestén informados de lo queestá sucediendo y por qué.Entendemos que en lamedida en que las auditoríassean favorables, estamos enla dirección correcta”.

“¿Su proceso de parches,qué grado de interrupcionesocasiona?”

“Ninguno. Entendemos quela disponibilidad es de capi-tal importancia. Tenemosque ver de qué manera miti-gamos los riesgos de seguri-dad sin incurrir en lospeligros asociados a loscambios. En promedio,colocamos un lote grandede parches por año”.

“La implementación de par-ches solía ocasionar muchasinterrupciones, pero des-pués de la interrupciónimportante que sufrimoshace seis meses atrás, repa-samos todos los supuestosque nos formulábamosacerca de qué parchesimplementar y cuándo.Hemos reducido la cantidadde tiempo empleado en losparches de una frecuenciasemanal a una mensual, yahora estamos trabajandopara lograr una frecuenciatrimestral”.

“Debido a la mala calidad delsoftware que nos entreganlos proveedores, seguimosempleando demasiadotiempo en la implementa-ción de parches. Es unasituación sin salida. Si noimplementamos parches,nuestros sistemas podríanser atacados. Si colocamoslos parches, corremos elriesgo de que los sistemasde producción colapsen.Pero como no deseamossalir en la primera plana delas noticias, no tenemos otraopción que implementarparches”.

23


Cuadro 2: Preguntas a realizar sobre la gestión del cambio agrupadas por arquetipo (continuación)

24

BASADO EN EL USO DE UN SISTEMA DE HONOR

Basado en el enfoque “Operaciones Visibles” de IPTI

REACTIVO GESTIÓN DE CAMBIO DE CICLO CERRADO. MEJORA CONTINUA

EFICACIA

REACTIVO• Más del 50% del

tiempo se emplea entrabajo no planeado.

• Entorno caótico,muchas situacionesde emergencias

• MTTR es demasiadoextenso; bajos nivelesde servicio.

• Sólo puede incremen-tar la capacidad de TIdestinando numero-sas personas alproblema

BASADO EN EL USO DEUN SISTEMA DE HONOR• 35% del 50% del tiempo

empleado en trabajo noplaneado.

• Alguna tecnologíaimplementada.

• Usted tiene una visióncorrecta, pero no hayresponsabilidad asignada.

• La proporción de servido-res con respecto a admi-nistradores es bastantebaja.

• Los costos de TI sondemasiado altos.

• El proceso se pervierteporque se habla con las“personas adecuadas”.

GESTIÓN DE CAMBIO DECICLO CERRADO

• 15% a 35% del tiempoempleado en trabajo noplaneado.

• Hay cierto sistema deflujo de trabajo/ticketimplementado.

• Los cambios se docu-mentan y se aprueban.

• La tasa de éxito del cam-bio es alta.

• Los niveles de servicioson bastante buenos.

• La proporción de servi-dores con respecto aadministradores esbuena, pero no la mejorde todas (en inglés, BoB).

• Los costos de TI mejo-ran, pero aún son dema-siado altos.

• Los incidentes de seguri-dad han disminuido.

MEJORA CONTINUA• Se emplea menos del 5%

del tiempo en trabajosno planeados.

• La tasa de éxito del cam-bio es muy alta.

• Los niveles de servicioson de primera clase.

• Los costos operativos deTI están bajo control.

• Se puede aumentar lacapacidad de TI rápida-mente con aumentosmarginales en costos deTI.

• Hay procesos de revisiónde cambios y de capaci-tación implementados.

• Puede incrementar lacapacidad de una mane-ra rentable.

Figura 4: Niveles de capacidad de gestión del cambio

LOS CAMBIOS DOMINAN A LAORGANIZACIÓN

LOS CAMBIOS DOMINAN A LAORGANIZACIÓN


5.1 Evolución de la capacidad de gestión del cambioLa gestión del cambio es un proceso evolutivo. Los grupos nodeben desalentarse cuando comienzan a desarrollar sus proce-sos de gestión del cambio. Las soluciones probablementerequieran cambiar a las personas, los procesos y la tecnología.A continuación, las etapas típicas de la gestión del cambio:

1. Olvido del cambio: “¿Eh, se reinició el conmutador?”2. Conciencia del cambio: “¿Eh, quién reinició el

conmutador?”3. Anunciar el cambio: “Eh, voy a reiniciar el conmu-

tador. Avísenme si esto ocasiona un problema”.4. Autorizar el cambio: “Eh, necesito reiniciar el con-

mutador. ¿Quién debe autorizar esto?”

5. Programar el cambio: “¿Cuándo es la próxima venta-na de mantenimiento? Me gustaría aprovechar laoportunidad para reiniciar el conmutador”.

6. Verificar cambio: “Al observar los registros del admi-nistrador de fallos, observo que el conmutador se rei-nició según lo programado”.

7. Administrar el cambio: “Vamos a programar la opera-ción de reinicio del conmutador para la semana 45 demanera tal que podamos realizar la actualización demantenimiento y el reinicio al mismo tiempo”.

La Figura 4 muestra una evolución de la capacidad degestión del cambio desde un estado reactivo a un estadode mejora continua.

Cuando Silvia considera las medidas que tomó en función delos comentarios de Fernando y la forma tan diferente con laque está administrando su organización, queda anonadadapor la diferencia que observa en sólo tres meses. Cuando unose concentra en mejorar la manera de administrar los cam-bios, los niveles de servicio y la disponibilidad aumentan, lassituaciones de emergencia disminuyen y todos se sienten másproductivos debido a que emplean el tiempo en proyectosestratégicos importantes.

Los auditores internos están sumamente satisfechos conel progreso que Silvia logró en su plan de gestión de parches.No se esperaba este resultado; ella implementa parches ensus sistemas con menor frecuencia que antes de la auditoría.Una vez que las observaciones de auditoría se resolvieron yvalidaron con éxito, José, uno de los auditores, la llamó y ledijo: “Buen trabajo, Silvia. Parece que has logrado un grancambio en 90 días. Es verdaderamente notable. ¿Cómo lolograste?”

Silvia se pregunta exactamente cómo lo logró. No podíadecir simplemente que aplicó todo lo que Fernando habíasugerido porque, en realidad, él nunca le había dicho quéhacer, lo cual fue inmensamente frustrante pero le permitióanalizar a fondo sus suposiciones. Luego de reflexionar unmomento sobre la pregunta, Silvia responde: “Creo que suce-dió en tres etapas clave. ¿Quiere que le cuente más?” Josésonríe entusiasmado y asiente con la cabeza mientras buscaen su libro de notas.

Recordando su primera reunión con Fernando, Silviaexplica: “Salí de esa reunión sabiendo que había muchascosas en las que tenía que pensar. ¿Cuál era la causa de losincrementos en el trabajo no planeado? ¿Por qué nuestrosproyectos siempre se demoraban y lo hacían cada vez más?¿Fernando se había dado cuenta de algo?”

Le preguntó a su personal en qué estaban empleando sutiempo. Algunas partes de su organización estaban resolvien-do situaciones de emergencia del momento y, por algunarazón, tal como la proverbial bola de nieve, nunca podíanterminar con tales situaciones. Muchas de las entrevistas noplanificadas con el personal fueron interrumpidas por las lla-madas de los localizadores que indicaban algún corte o inte-rrupción de servicio y la conversación se debía suspenderantes de tiempo.

Silvia comenzó a preguntarse qué estaba generando estacultura de urgencia continua y comenzó a seguir a los emple-ados para ver qué hacían cuando respondían a las llamadasde los localizadores. Durante dos semanas, empleó el 50 porciento de su tiempo en observar a sus gerentes, tratando deimaginarse en qué estaban empleando el tiempo.

“Observar de cerca a mis equipos fue sumamente esclare-cedor. Pero hubo otra reunión con Fernando que confirmó mipronóstico”. Fernando había regresado de Europa y le comen-tó a Silvia sobre los procesos maduros y eficientes de TI quehabía observado en los socios joint venture que su personalestaba auditando. Esta empresa europea tenía uno de los mejo-res resultados de mediciones en la industria, como tiempo pro-medio de reparación bajo (MTTR, en inglés), tiempopromedio entre fallos alto (MTBF, en inglés), tasas de éxitodel cambio superiores al 98%, así como también, el logro mássorprendente: una proporción administrador de sistema/servi-dor alta debido a que la mayor parte del trabajo se realiza en el

proceso de administración de versiones. Fernando adjudicóparte del éxito al modo de “administrar en función de loshechos”, una forma de operar que recluta los esfuerzos de todaslas personas de la organización para que sus resultados se tor-nen visibles y difíciles de ignorar. Fernando le dijo: “Cuandolas organizaciones se administran basándose en los hechos,nada se toma como cierto sin supervisión ni medición”.

Al escuchar sobre la medición de la tasa de éxito del cam-bio, a Silvia se le ocurrió una idea. Descubrió la causa que esta-ba generando prácticamente todo el trabajo no planeado: loscambios fallidos. En función de lo que había observado, esti-mó que uno de sus equipos estaba realizando alrededor de 100cambios por semana y no podía recordar si, durante la semanaanterior, alguno de esos cambios había tenido éxito sin causaralgún reproceso o trabajo no planeado.

“Creo que ahora puedo comprender mejor la tensióncuando diferentes equipos tienen distintas definiciones conrespecto a un cambio exitoso”. Pensó en una reunión quehabía tenido con varios administradores del centro de datosal final del día cuando todos los localizadores de la habita-ción comenzaron a sonar. Mientras se dirigía a la puerta, unode sus gerentes comentó con tono cortante: “Esos deben serlos programadores que están implementando los cambios deldía antes de irse”.

Silvia decidió concentrarse primero en el equipo dedesarrollo para descubrir cuántos cambios realizaban, cuán-tos de ellos fallaban y por qué fallaban. Les solicitó a todossus gerentes que enviaran una lista de los problemas operati-vos más importantes que habían surgido en el último trimes-tre y que clasificaran la causa raíz en fallos de hardware,condiciones ambientales o fallos relacionados con los cam-bios. Quería descubrir cómo el equipo que realizaba los cam-bios decidía si eran exitosos y si sabía o no que estos cambiospodrían crear una situación de emergencia para otro equipo.

Cuando le mostró un resumen del plan a Fernando, élsonrió y le dijo: “Felicitaciones. Estás comenzando a plante-ar las preguntas que todas las organizaciones de TI de altorendimiento se plantean”. Le preguntó cómo debía ser unproceso de gestión del cambio eficaz. Silvia pudo identificaralgunos aspectos clave.

“¡Muy bien!”, respondió Fernando. “Entonces, ¿quévas a hacer para corregir los procesos deficientes y asíalcanzar tus metas?”

Silvia describió cómo sus esfuerzos recientes le permitie-ron “estabilizar al paciente”. Redujo o eliminó el acceso paratomar control de las fuentes de cambios no planificados ypropensos a errores. En las dos semanas anteriores, documen-tó un nuevo proceso de gestión del cambio, notificó a todaslas partes interesadas, creó un equipo para llevar a cabo elcambio y ventanas de cambio para controlar mejor lo que sehacía y el momento en que se hacía y “electrificó la barrera”para asegurarse de que todo el personal de TI se sintiera com-pletamente responsable de las “mejoras” que realizaban.Ahora su lema es “Confiar pero siempre verificar”. Todosparecían haber captado el mensaje y las nuevas reunionessemanales de gestión del cambio la ayudaron a asegurarseque se aplicara el sistema de rastreo de solicitudes existentey a mejorar las comunicaciones internas.

De hecho, la mayoría de sus problemas giraban en tornoa los cambios fallidos. Los nuevos controles fueron suma-

25

GTAG — Tres meses más tarde: finaliza la historia de Silvia — 6

26


mente eficaces. Silvia recordó que le había enviado al equi-po un mensaje de felicitaciones anunciando que no habíansurgido “sorpresas” durante los últimos cinco días, una situa-ción poco común. (Cuando generó algunos reportes paraaveriguar cuándo había sucedido eso por última vez, se son-rió y decidió guardar en secreto los resultados. La última vezque los niveles de servicio alcanzaron esta eficiencia fue elverano pasado cuando este mismo equipo tuvo un trabajo deTI fuera de la oficina, lejos de sus teclados).

Silvia ahora tenía una estadística que mostraba la cantidadde cambios no planificados y el tiempo improductivo y unreporte con los nombres de los proyectos y de las personas quecausaron problemas desde que se implementó el nuevo proceso.

El personal de Silvia había identificado la mayoría de lascausas del tiempo improductivo y ahora tenía un plan de“respuesta inmediata” para poner el equipo en funciona-miento en la mitad del tiempo. Su equipo necesitaba sólo el20 por ciento del tiempo improductivo para identificar lacausa de la interrupción y empleaba el 80 por ciento en solu-cionarla. Anteriormente, se empleaba mucho tiempo enidentificar qué había cambiado, quién lo había cambiado ypor qué. Silvia reconoció que ese proceso era ineficiente.

Silvia le comenta a José: “Quiero comenzar a emplear latasa de éxito del cambio para cada proceso de negocios yactivo de TI de manera que pueda aprender del desempeñoanterior y evitar la implementación de cambios histórica-mente riesgosos”.

Mostrando curiosidad acerca de la participación del per-sonal en el nuevo proceso, José le pregunta: “¿Cómo sabes sien verdad todos están siguiendo el proceso?”.

Silvia le explica que el grupo de operaciones de TIpublica una lista de cambios autorizados. Además, ha “elec-trificado la barrera” para asegurarse de que se siga el proceso.Ha implementado controles de detección para informartodos los cambios de producción, que luego se deben conci-liar con la lista de cambios autorizados. Cuando se detectancambios no autorizados, se envía un mensaje a todo el equi-po de ingeniería para comunicarle que tiene cuatro horaspara que alguien explique por qué realizó un cambio no auto-rizado antes de activar una investigación de seguridad.

José le pregunta si todos desarrollan planes de “restaura-ción” antes de autorizar la implementación de los cambios.Silvia confirma esto y comenta que han logrado beneficiosmedibles al definir por anticipado cómo recuperarse ante unproblema, en lugar de intentar hacerlo durante el momentocandente de la recuperación. José la felicita y está ansioso porcomentar sus éxitos con los demás gerentes de TI y departamen-tos.

Silvia se siente gratificada pero sabe que hay mucho máspor hacer. Entonces, recuerda el consejo de Fernando: “Ahoraque has comenzado a controlar cómo se realizan los cambiosen la producción para reducir la probabilidad de trabajo noplaneado, necesitas hacer un inventario de todos los activosde infraestructura e identificar aquellos que generan la mayorparte del trabajo no planeado”. Como un especialista en faunaque controla la manada de venados, Silvia debe supervisarcada activo para descubrir cuáles están funcionando, qué ser-vicios dependen de ese activo, quién es el responsable y cuánfrágil es el artefacto. “Tener un inventario no sólo ayuda en lagestión de problemas sino que también contribuye al desarro-

llo de una biblioteca de compilación repetible de los activos yservicios más críticos, con lo cual se reduce el costo de repara-ción de tales elementos”.

Silvia acepta que la orientación que le dio Fernando laayudó a comprender lo que José le está diciendo. Espera fina-lizar su plan de acción y debatirlo con Fernando antes de lapróxima reunión del comité de auditoría. “Ahora me doycuenta de que la gestión ineficaz del cambio hizo que miequipo viera al proceso como algo burocrático y, por lo tanto,lo ignorara”. Cuando Silvia pudo demostrarles que el 80 porciento de las interrupciones eran causadas por errores de laaplicación o de los operadores, comenzaron a comprenderpor qué el departamento luchaba por asignar personas a losproyectos de desarrollo de preproducción. José le agradece aSilvia por su tiempo, cierra su libro de notas y se va.

Silvia está ansiosa por revisar su plan con el comité deauditoría la semana próxima. En función de los resultadosdel nuevo proceso de gestión del cambio durante los últimos60 días, ella calcula que podrá redireccionar los esfuerzos dedos o tres personas que actualmente manejan la gestión deparches y de otra persona que se dedica a diagnosticar lascausas del tiempo improductivo y las etapas de corrección.

Silvia cree que puede reasignar a tres miembros del per-sonal al nuevo proyecto de servidor Web para órdenes decliente y llegar a implementarlo correctamente antes de lasvacaciones, en lugar de hacerlo a principios de año. Lecomenta a Fernando: “El equipo de marketing proyecta unincremento del 20 por ciento en las órdenes previas a lasvacaciones a través de este proceso si tenemos éxito. Es unamuy buena noticia para el consejo. Y este es sólo el comien-zo”. Silvia le dice a Fernando. Durante una revisión de cen-tro de datos por incumplimientos, su equipo de auditoría noencontró ninguna discrepancia entre nuestros estándares deconfiguración de TI y nuestros servidores de producción. Nosólo los miembros de mi equipo adoptaron el nuevo procesode gestión del cambio, sino que también instalaron softwareautomático para evitar y detectar variaciones entre los están-dares y los parámetros actuales de configuración mejorandosignificativamente la seguridad de nuestra información”.

No obstante, Fernando no está convencido y señala queSilvia no puede administrar lo que no puede medir, y que esoque se puede medir, es lo que en definitiva se debe hacer.Silvia describe las medidas clave de su proceso de versiones,control y resolución y de otros procesos. Entiende que si supersonal no puede describir los procesos ni realizar las medi-ciones con respecto a estos, no sabrá qué está haciendo.

Fernando parece impresionado y dice: “No está mal,Silvia. Suena como un gran plan”.

Por primera vez en sus conversaciones con Fernando,Silvia se siente como si finalmente ha aprobado el examen.Pero no puede resistirse a hacer una pregunta que ha tenidoen mente desde que conoció a Fernando. “A propósito,¿cómo sabe tanto de gestión de cambios?”

Fernando le responde: “Como antes mencioné, soy unapersona de negocios que trabaja en auditoría interna. EnABC Telecom, estaba en TI y era el responsable de infraes-tructura y operaciones. Conseguí ese trabajo gracias a quepude demostrar mi habilidad para instalar procesos repetiblesy verificables, en los que la seguridad, la disponibilidad, lacalidad y el valor se incorporaban a los procesos y se medían

en el curso normal de los negocios. Sin esto, no podíamosprestar nuestros servicios y mantener nuestros clientes. Toméeste trabajo para aplicar el mismo proceso de ideas en toda laempresa, no sólo en TI. Existe una verdadera necesidad degarantizar que todos nuestros procesos de negocios y sistemasde respaldo incluyan los controles necesarios para que no seproduzcan errores como sobrepagos a proveedores, estadosfinancieros erróneos o demoras en la entrega de sistemas yservicios. ¿Dónde mejor que el departamento de auditoríainterna, con el respaldo total de la gerencia y del comité deauditoría del consejo, para lograr esto?”

27


GTAG — ¿Por dónde deben comenzar los auditores internos? — 7

28

Según el Enfoque Integral de Gestión de Riesgo Empresarial(Enterprise Risk Management - Integrated Framework), lagerencia establece los objetivos estratégicos, selecciona lasestrategias y difunde los objetivos alineados en toda laempresa. El enfoque de gestión de riesgo empresarial seorienta hacia el logro de los objetivos de la entidad en cua-tro categorías: estrategias, operaciones, generación de repor-tes y cumplimiento. Se deben diseñar e implementarcontroles preventivos, de detección y de corrección paraayudar a garantizar que las respuestas a los riesgos se lleven acabo con eficacia. La auditoría puede ayudar a garantizar quela gestión de TI cuente con un proceso eficaz para adminis-trar los riesgos asociados con el logro de los objetivos. Entrelos ejemplos de los tipos de objetivos de gestión de cambiosque la gestión de TI debe definir, se encuentran aquellos parala revisión y aprobación de solicitudes de cambio, que garan-tizan que los cambios se implementen de manera adecuada yeficaz, y que ayudan a garantizar que TI pueda efectuar unarecuperación rápida cuando los cambios fallan.

Los controles preventivos, de detección y corrección sedeben deducir de los objetivos de la gerencia para la gestiónde cambios de TI. La gestión de TI debe demostrar que lossiguientes controles existen y son eficaces [Tipton 00]:

• Controles preventivos.– Autorización de cambios.

• Documentación que muestra el proceso de gestiónde cambios, incluidos los roles y las responsabilidadesde los participantes..

• Documentación que muestra los propietariosautorizados para todos los procesos de negocios ylos sistemas de TI de respaldo, con nivelesasignados de autorizaciones.

– Separación de roles.• Documentación que muestra la clara asignación y

separación de los roles y las responsabilidades delas partes interesadas en la gestión de cambios,incluida la autorización, la planificación, laimplementación y la revisión de cambios.

• Políticas claras que describen las categorías y losniveles de cambios y los grados de formalidad,aprobación y severidad asociados con el avance delos cambios dentro de cada categoría desde lainiciación hasta la etapa de implementación.

• El acceso para realizar cambios en la producciónestá estrictamente limitado a las personasresponsables de implementar los cambios. Todoslos demás empleados, como por ejemplo losprogramadores, no poseen tal acceso.

• Programas de capacitación y difusión parapromover una cultura de la gestión del cambio.

– Supervisión y monitorización.• Documentación que muestra que el proceso de

cambios está siendo controlado, supervisado eimplementado de manera eficaz. En todo momento,debe existir una lista publicada de cambiosautorizados, así como también una lista de cambiosno autorizados, generada mediante la conciliaciónde los cambios reales de producción y los cambiosautorizados.

• Las actas de las reuniones de la gestión del cambio

también pueden mostrar las solicitudes de cambiosrecientemente autorizados y programados. Cadasolicitud de cambio debe tener un identificadorúnico y una persona responsable.

• Controles de detección.– Supervisión y monitorización:

• Métodos automáticos para detectar si los cambiosrealizados en la producción están presentes y si serevisaron independientemente. Podrían serregistros de auditoría de cambios o utilidades queanalizan la infraestructura de producción paraencontrar los cambios.

• Cambios en el equipo de producción registradosen registros de trabajo, tickets de trabajo y órdenesde cambio. Estos deben identificar la fecha, lahora, el implementador y el sistema junto con losdetalles de los cambios realizados.

• Los cambios se deben revisar para garantizar queno exista variación entre el cambio planificado yel cambio implementado. Las variaciones se debeninformar y explicar.

• Aceptación de cambios implementados,documentando la correlación entre los cambiosdetectados y los cambios implementados,indicación de una implementación exitosa,aceptación por parte de un gerente de cambios ycierre de la orden del cambio.

– Muestreo sustantivo para auditar la exactitud de lasconciliaciones entre los cambios de producción y loscambios autorizados.• Muestra de solicitudes de cambios autorizados.

Recorrer el proceso de gestión de cambio paragarantizar que los cambios se hayan implementadodentro del alcance del cambio autorizado.

• Muestra de controles de detección correspondientea los cambios. Garantizar que los cambios se puedanasignar al trabajo autorizado.

• Controles de corrección y de recuperación.– Se identifican todos los cambios realizados fuera del

proceso de gestión de cambio. La documentacióndescribe las acciones correctivas y lógicas tomadas.

– Revisiones posteriores a la implementación sobre loscambios realizados, en función del grado del cambio,importancia de las actividades comerciales quesufrieron cambios y la significatividad de los riesgospotenciales para el negocio.

– Cuando los cambios fallan, los gerentes de problemasprimero descartarán el cambio en el ciclo dereparación mediante el acceso a los cambios autorizados y planificados y mediante la revisión de loscambios de producción en la infraestructura afectada.

Para lograr el éxito, la gerencia se debe alinear con lasinquietudes de los accionistas, representados por el consejode administración. Se deben alcanzar los objetivos de laempresa, que, en general, son objetivos relacionados con laparticipación de mercado o ingresos, con el crecimiento delprecio de las acciones o del negocio o con la contención delos costos de personal y operaciones. Se deben formular pla-nes para alcanzar los objetivos y se deben desarrollar demanera eficaz en toda la organización para tener la posibili-


29

dad de lograr el éxito. El Comité de Auditoría desea asegu-rarse de que la gerencia haya identificado y evaluado los ries-gos que podrían impedir el logro de los objetivos. Se debenadoptar procesos sólidos para mitigar, administrar, aceptar otransferir los riesgos eficazmente. La variación del plan tam-bién es un riesgo que se debe manejar de manera activa. Losauditores internos son los ojos y oídos de la gerencia, a tra-vés de ellos se busca detectar las áreas del entorno de gestiónde riesgos que necesitan fortalecimiento.

Para la mayoría de las empresas, la no disponibilidad deservicios y funciones críticas, incluso durante breves perío-dos de tiempo, es una de las maneras más rápidas de inte-rrumpir el progreso hacia el alcance de los objetivos delnegocio. El tiempo de inactividad de la red inesperado puededetener la ejecución de los procesos críticos de negocios,como la coordinación de calendarios de materiales con pro-veedores y la respuesta rápida a órdenes del cliente. Delmismo modo, el tiempo de inactividad en una aplicación crí-tica, base de datos o servidores Web puede ser destructivo.Los auditores internos, junto con la gerencia, desean asegu-rar que estos riesgos y los riesgos relacionados se hayan iden-tificado, medido y administrado correctamente. Pero, ¿cómopuede administrar dichos riesgos si no ha identificado ni ana-lizado sus causas?

Proteger el entorno de producción y respaldar a la orga-nización mientras se persiguen los objetivos de negocio sonresponsabilidades clave del departamento de TI. Los audito-res internos tienen la responsabilidad de garantizar que sedesarrollen procesos adecuados de gestión de riesgos, inclusodentro de TI. A esos fines, la importancia de un proceso degestión del cambio eficaz no puede subestimarse y los audito-res internos deben considerar la posibilidad de efectuar revi-siones regularmente.

7.1 El rol de la auditoría en el proceso degestión de cambios

Dado que los auditores internos, por lo general, no tienentiempo para revisar todas las facetas de las organizaciones enlas que trabajan, deben desarrollar planes de auditoría enfunción de una evaluación de riesgos. Para poder evaluar losriesgos de negocios dentro de TI, los auditores deben recopi-lar información preliminar. A continuación se detallan lastareas que deben llevar a cabo los auditores para determinarel nivel relativo de riesgo de negocio asociado con las prác-ticas de la gestión del cambio de la organización y si se deberealizar una revisión profunda o de nivel avanzado de la ges-tión del cambio:

1. Se deben comprender los componentes básicos de lagestión del cambio. El término gestión del cambio, talcomo se utiliza en este documento, no incluye todo elproceso del ciclo de vida del desarrollo de sistemas,como el desarrollo de aplicaciones o la gestión de con-figuración. No obstante, la gestión del cambio debereflejar e integrarse con el proceso del ciclo de vida deldesarrollo de sistemas (y controles relacionados).Comprender el contenido de esta guía le proporcionael conocimiento suficiente como para realizar las pre-guntas difíciles relacionadas con la organización de TIy así poder entender el nivel de mejora que posible-mente se necesite en el proceso y los controles de ges-

tión del cambio. (Consulte el Cuadro 2, página 21,para obtener preguntas útiles que podrá realizar).

2. Se deben utilizar los indicadores de procesos de gestióndel cambio eficaz e ineficaz (consulte las Secciones3.2, página 10, y 3.3, página 11) y los niveles de capa-cidad proporcionados en esta guía (consulte la Figura4, página 24) para evaluar la eficacia relativa de losprocesos de gestión del cambio correspondientes a laorganización. Realice una revisión del proceso de ges-tión del cambio y busque los elementos clave descrip-tos en esta guía. Se debe comprender cómo laadministración de TI mide el proceso y si este respon-de verdaderamente a las necesidades del negocio.

3. Se debe obtener una ficha de evaluación de la admi-nistración de TI para medir los resultados y la eficaciadel proceso. Se debe determinar si se están utilizandolas mediciones adecuadas para supervisar el proceso eimpulsar mejoras continuas. (Consulte la Tabla 1,página 16).

4. Se debe determinar si la administración de TI ha asig-nado la responsabilidad de la gestión del cambio a unempleado que no sea el programador de software ni elencargado de preparar los cambios. ¿La administraciónha asegurado el entorno de producción de manera quesólo las personas responsables de implementar cambiospuedan efectivamente implementarlos?

5. Se debe realizar una breve revisión para determinar siexisten pistas de auditoría de los cambios en el entor-no de producción y que dichas pistas de auditoría nopuedan ser manipuladas ni destruidas.

6. Al realizar auditorías de control de cambios, se debenbuscar indicadores de gestión del cambio eficaz, talcomo se muestra en el ejemplo de programa de audito-ría del Apéndice A (página 32). Debe concentrarse enlos riesgos del negocio causados por el fallo en alcanzarlos objetivos de control, que están basados en losObjetivos de Control de Información y TecnologíaRelacionada (en inglés, COBIT).

7. Se debe ayudar a la administración a identificar losmodelos con los que se puede mejorar el enfoque haciala gestión del cambio. Un ejemplo es el libro VisibleOps Handbook: Starting ITIL in Four Practical Steps[ITPI 04], descrito en el Apéndice B (página 39). Estaguía concisa contiene información útil sobre cómo esuna organización de TI de alto rendimiento y cómomejorar un bajo rendimiento. Presenta el proceso demejora en cuatro etapas:

• Estabilizar al paciente.• Buscar artefactos frágiles.• Crear una biblioteca de compilación repetible.• Mejora continua.

8. Cuando la organización considera la posibilidad de ter-cerizar funciones de TI a un proveedor de servicios, sedebe verificar que las expectativas de la organizaciónestén claramente identificadas en los acuerdos de nivelesde servicio (SLA, en inglés) y en los contratos. Es impor-tante garantizar que se tengan en cuenta los siguientespuntos respecto del proceso de gestión del cambio:

• ¿Quién es el responsable de administrar interna-mente los cambios diarios que surgen a partir de

las solicitudes de cambios?• ¿Cómo sabe la organización si los cambios fueron

realizados por el proveedor de servicios fuera delproceso de gestión del cambio acordado?

• ¿Qué control tiene la organización sobre el prove-edor de servicios para asegurarse de que este norealice cambios no autorizados o ilógicos? ¿Cómosabe la organización si se efectuaron dichoscambios?

• ¿Cómo se evita que el proveedor apruebe cambiosfuera de los períodos de tiempo de la ventana decambio, con el consiguiente impacto en el servicio(aplicaciones no disponibles cuando se necesitan)y en el costo (o pérdida de ingresos)?

• ¿Quién es el responsable de garantizar que loscambios de negocio importantes que afectan a TIse hayan evaluado, aprobado, planificado, con-trolado, implementado y revisado adecuadamente?

• ¿El proveedor ha considerado los impactos en lainfraestructura (sistema y red) y en la seguridadde la información como parte de la evaluación decada cambio?

• ¿La organización ha identificado quién, entre susintegrantes, es la persona que pertenece a loscomités de control de cambios del proveedor?

• ¿Quién supervisa el cumplimiento de los acuerdosde niveles de servicio?

• Para los sistemas dentro del alcance del artículo404 de la Ley Sarbanes- Oxley u otras regulacio-nes, el acuerdo de niveles de servicio tambiéndebe incorporar prácticas requeridas, procedi-mientos de validación, cálculos de tiempo de laprueba requerida, trabajo de corrección, repeti-ción de pruebas y otras consideraciones.

9. Al debatir y escribir las observaciones de auditoría, sedebe presentar el valor de negocio de los procesos degestión del cambio eficaces, además de los riesgos delos procesos ineficaces. Se deben articular claramentelos riesgos de operaciones, financieros y reglamenta-rios, que no se están administrando adecuadamente yvincular los resultados con las tolerancias de riesgosque ha establecido la administración para respaldar lasmetas y los objetivos del negocio. Se debe evitar con-centrarse en la tecnología, excepto cuando se hayanautomatizado ciertos controles del proceso de gestióndel cambio. En cambio, se le debe recordar a la admi-nistración que la gestión del cambio está basada enprocesos, tiene un enfoque de gestión y humano, y estárespaldada por controles técnicos y automáticos.

30

11 ITIL es marca registrada en la Oficina de Comercio de Gobierno (en inglés, OGC).


31

GTAG — ¿Dónde puedo obtener más información? — 8

Best in Class Security and Operations Round Table Report, JuliaAllen, Kevin Behr, Gene Kim, et al., (CMU/SEI-2004-SR-002). Pittsburgh, PA: Software Engineering Institute, CarnegieMellon University, marzo de 2004. Disponible a través de losautores mediante solicitud.

Capability Maturity Model® Integration (CMMI®).Carnegie Mellon University, Software Engineering Institute.Disponible en http://www.sei.cmu.edu/cmmi/cmmi.html.Chrissis, Mary Beth, et al. CMMI®: Guidelines for ProcessIntegration and Product Improvement. Addison Wesley,2003. Consulte específicamente el área de proceso de gestiónde configuración.

COBIT [Control Objectives for Information and relatedTechnology] 3rd Edition Executive Summary, Framework,Control Objectives, Audit Guidelines, and ManagementGuidelines, julio de 2000. Disponible en http://www.itgi.org yhttp://www.isaca.org. Consulte específicamente AI-6:Acquisition and Implementation: Manage changes y DS-9:Delivery and Support: Manage the configurations.

Information Technology Infrastructure Library (ITIL)® 11.Office of Government Commerce. Vaya ahttp://www.ogc.gov.uk/index.asp?id=2261 yhttp://www.itsmf.com. Consulte específicamente el volumenBest Practice for Service Support, Capítulo 8, ChangeManagement (2000).

ISO/IEC 17799 Information Technology Code of Practicesfor Information Security Management, First Edition. ISO/IEC17799:2000(E). Diciembre de 2001. Consulte específicamentelas secciones 8.1.2 Operational change control, 10.5.1 Changecontrol procedures, 10.5.2 Technical review of operating systemchanges y 10.5.3 Restrictions on changes to software packages.

Microsoft Service Management Functions OperationsGuide: Change Management. Microsoft Corp., 2004.Disponible en http://www.microsoft.com/technet/itsolutions/tech-guide/msm/smf/smfchgmg.mspx.

Systems Assurance and Control (SAC). The Institute ofInternal Auditors Research Foundation, Agosto de 2003.Información e índice disponibles enhttp://www.theiia.org/esac/index.cfm.

Visible Ops Handbook: Starting ITIL in Four PracticalSteps. Kevin Behr, Gene Kim, George Spafford. IT ProcessInstitute, 2004. Información disponible enhttp://www.itpi.org/visibleops.

GTAG — Apéndice A — Programa de auditoríade gestión del cambio de TI — 9

32

12 Si la gerencia no desarrolló sus propias definiciones, el auditor y el auditado deben acordar en qué consisten las definiciones a los fines de la auditoría.13 Lo ideal es que el trabajo planeado y no planeado se mida en lugar de calcularlo. No obstante, incluso cuando se usan las definiciones más informales, lacantidad de trabajo planeado y no planeado puede resultar un indicador excelente de la eficacia de la organización de TI. Toda interrupción del serviciorepresenta un trabajo no planeado, al igual que el trabajo originado por un cambio fallido, cambio de emergencia, parche o incidente de seguridad. El tra-bajo no planeado es aquel que hace que los gerentes de TI reorganicen sus horarios y no permite que los administradores de sistemas puedan llevar a cabosus planificaciones diarias.

Proceso, propósito y riesgosLa gestión del cambio de TI es un proceso para administrarcambios en el hardware de producción, en los dispositivos dered, en los sistemas operativos y en el software de aplicación.La administración de una organización utiliza el proceso degestión del cambio de TI para:

• Garantizar que los cambios de TI respondan a las nece-sidades de la organización y crean valor de negocio.

• Anticipar y administrar los problemas que se puedengenerar en el entorno de producción como resultadode los cambios.

• Promover la eficacia y la eficiencia de los esfuerzos dela gestión del cambio de TI.

El logro de estos objetivos estratégicos y operacionales dealto nivel no está garantizado automáticamente. Los even-tos, los riesgos clave y otras circunstancias podrían impedirque la administración alcance los beneficios de negocio dese-ados. Dichos eventos son los siguientes:

• Los cambios interrumpen las operaciones y crean otrosproblemas.

• Los cambios que causan interrupciones u otros proble-mas no son detectados ni se rastrea su origen para laoportuna identificación de las causas y la restauraciónde los servicios afectados.

• Los cambios no se realizan de manera completa u opor-tuna.

• Los cambios no se realizan de la manera más eficiente,lo que genera costos excesivos.

• A pesar de implementar los cambios correctamente,estos no pueden responder a los requerimientos delnegocio y, por lo tanto, no crean el valor de negociodeseado.

A continuación, se incluye un ejemplo de un programa deauditoría que puede ser útil para la administración de TI ypara los auditores internos que deseen evaluar los controlesque podrían mitigar el riesgo inherente a estos eventos.

9.1 Definiciones de la gestión del cambio12:• Solicitud del cambio: Procedimiento propuesto para

una adición, modificación o eliminación de elementosaprobados, respaldados o básicos de hardware, red,software, aplicación, entorno, sistema, compilación deescritorio o documentación asociada. [ITIL 00]

• Cambio autorizado: Solicitud de cambio para un pro-cedimiento de cambio que ha sido aprobado por elConsejo de asesoramiento para el cambio (CAB, eninglés).

• Cambio no autorizado: Cambio detectado mediantelos controles de detección de producción que no sepuede asociar a un cambio autorizado. Los ejemplos delas variaciones que podrían generar un cambio noautorizado son los siguientes:

– Quién: el cambio fue implementado por unapersona no autorizada

– Qué: el cambio excede el alcance del cambio auto-rizado o el cambio pretendido se implementó, demanera incompleta.

– Dónde: el cambio se implementó en un activoinadecuado.

– Cuándo: el cambio se implementó fuera de la ven-tana de cambio o ventana de mantenimientoprogramada.

• Trabajo planeado: Cualquier actividad del trabajadorque puede ser asignada a un proyecto o procedi-miento autorizado.

• Trabajo no planeado: Cualquier actividad del trabaja-dor que no puede ser asignada a un proyecto o proce-dimiento autorizado.13

• Incidente que afecta al servicio: Cualquier evento queno forma parte de la operación estándar de un servicioy que causa, o podría causar, una interrupción o reduc-ción de la calidad del servicio. Por ejemplo, falta dedisponibilidad de aplicaciones o servicios, inactividaddel hardware o sistema, deterioro del servicio, etc.[ITIL 00].


33

Riesgo Objetivo del control Prueba Referenciaen COBIT

Se debe obtener:• Políticas, normas y procedimientos de gestión del cambio de TI.

• Enumeración de los organigramas departamentales y de personaldonde consten los participantes de la gestión del cambio, espe-cialmente los responsables del desarrollo y la implementación delos cambios.

• Información relativa a los proveedores de servicios de tercerosque participan en el proceso, incluidos los acuerdos de nivelesde servicio (en inglés, SLA) y contratos relacionados.

• Diagramas de flujo en los que figure el proceso de gestión delcambio de TI.

• Inventario y descripciones de los elementos del entorno deproducción alcanzado por la auditoría (por ejemplo, dispositivosde red, servidores, bibliotecas, bases de datos).

• Mediciones, normas y compromisos de niveles de servicio de lasoperaciones de TI, especialmente los que se vinculan directa-mente con la gestión del cambio y del problema.

• Informes de muestra que indiquen cómo las mediciones, lasnormas y los compromisos de nivel de servicio se debeninformar a la gerencia.

• Informes y análisis de los problemas recibidos por la mesa deservicio.

• Lista de los cambios autorizados.

• Registros de control del cambio.

Es posibleque el proce-so de gestióndel cambio deTI no contri-buya adecua-damente allogro de lasmetas delnegocio.

La gestión de TI asegu-ra que todas las solici-tudes de cambio, elmantenimiento del sis-tema y el mantenimien-to de los proveedoressean estandarizados yestén sujetos a procedi-mientos formales degestión del cambio. Lagerencia dispone deuna visibilidad adecua-da de los cambios de TIrealizados al entorno dela producción y ejerceun control apropiadode estos.

Se debe establecer que las políticas, normas y procedimientos degestión del cambio de TI se apliquen de manera lo suficientementeamplia como para asegurar el control de gestión del entorno deproducción. Se debe comprobar que prevean:

• Diferentes opciones según los costos y riesgos del cambio.

• Información del caso de negocio que sirva de guía para el esta-blecimiento de un orden de prioridad para los esfuerzos realiza-dos en pos del cambio.

• Una evaluación estructurada de los riesgos y el impacto quetenga en cuenta todos los impactos posibles en el sistema ope-rativo y su funcionalidad.

• El establecimiento de categorías y prioridades para los cambios.

• El manejo específico de los cambios de emergencia.

• La comunicación con los solicitantes del cambio en relación conel estado de su solicitud.

• La definición de los requerimientos.

• Las pruebas (incluyendo las de unidad, regresión, sistema, inte-gración capacidad/desempeño y la prueba de aceptación deusuario según corresponda).

AI6.Gestionarlos cam-bios

Cuadro 3: Programa de auditoría de gestión del cambio de TI


34

• La generación y/o modificación adecuadas de la documen-tación relacionada.

• La comunicación adecuada de los cambios pendientes a laspartes afectadas, entre ellas a la gerencia, los usuarios, losprogramadores , los administradores de seguridad, opera-ciones de TI y al personal de la mesa de ayuda.

• La separación adecuada de los entornos de desarrollo,prueba y producción.

• La consideración adecuada de las consecuencias de los contro-les (por ejemplo, que incluya desde un principio la gestión deseguridad de la información).

• La consideración adecuada de los efectos para la continui-dad del negocio.

• Las responsabilidades para la investigación de los fallos ,junto con el proceso de resolución de incidentes.

• Los controles definidos a lo largo del proceso de cambio.

Se deben revisar las mediciones, normas, niveles de servicio, com-promisos e informes relacionados con las operaciones de TI. Sedebe verificar que proporcionen a la gerencia información inde-pendiente, oportuna, exacta, completa, concisa y relevante paradeterminar los efectos de los cambios y problemas en las opera-ciones de TI y en última instancia en las metas del negocio. Lasmedidas deben incluir:

• La cantidad de cambios autorizados por semana: ¿Cuántoscambios, según la medición realizada durante el proceso degestión del cambio? (En general, cuanto mayor sea la cantidad,mejor, siempre que la tasa de éxito del cambio también semantenga elevada).

• La cantidad de cambios reales realizados por semana: ¿Cuántoscambios, según las mediciones realizadas por controles dedetección? (En general, cuanto más cambios se realicen mejor,pero no deben superar la cantidad de cambios autorizados porel consejo de asesoramiento para el cambio).

• La cantidad de cambios no autorizados: ¿Cuántos cambios sos-layaron el proceso de cambio? Esto generalmente se mideusando los controles de detección o, lo que es peor, a travésde interrupciones no planeadas. (Cuanto menos, mejor).

• La tasa de éxito del cambio: ¿Cuántos cambios se implementande manera exitosa sin ocasionar interrupciones o episodios detrabajo no planeado? (Cuanto más, mejor). La tasa óptimasupera el 99 por ciento).

• La cantidad de interrupciones que afectan el servicio: ¿Cuántoscambios generan deterioros del servicio o interrupciones?(Cuanto menos, mejor).

• Cantidad de cambios de emergencia: ¿Cuántos cambios necesi-taron del uso del proceso de cambio de emergencia? (En gene-ral, cuanto menos, mejor ya que indica un porcentaje más ele-vado de trabajo planeado).

Cuadro 3: Programa de auditoría de gestión del cambio de TI (continuación)


35

A través de entrevistas, análisis o revisión de los registros de lasreuniones, se debe verificar que existe un grupo de gestión, comoun consejo de asesoramiento para el cambio, que se reúne regu-larmente, revisa las solicitudes de cambio de TI y las aprueba orechaza según corresponda. Se debe establecer que los sociosbrinden a la gestión una explicación adecuada de los cambios ycontrol sobre los mismos. Verifique que los usuarios estén inclui-dos, si corresponde.

AI6.2Evaluación delimpacto

Se deben obtener listados de personal y copias de los organigra-mas donde figure el grupo responsable de la gestión e implemen-tación de los cambios de TI. Se debe verificar que el grupo seaindependiente de los responsables de la solicitud ydesarrollo/preparación de los cambios.

AI6.6Mantenimientoautorizado

Se debe seleccionar una muestra de los cambios introducidos alos elementos de producción dentro del alcance y el término de laauditoría. Se debe establecer que existe documentación clara queindique que para la implementación de los cambios se respetarontodas las políticas, normas y procedimientos aplicables.

AI6.1 Inicio ycontrol de laSolicitud deCambio

Es posible quese implemen-ten cambios deTI que no satis-facen las nece-sidadescomerciales dela gerencia.

Que se apruebenúnicamente loscambios adecua-dos.

Se debe revisar las políticas, normas y procedimientos para queestablezcan que los cambios requieren la aprobación de la geren-cia, incluida la aprobación de las operaciones de TI y de los usua-rios comerciales . La aprobación debe requerirse en los puntosadecuados del proceso de cambio. Por ejemplo, se puede reque-rir la aprobación por parte de la gerencia correspondiente al finalde la preparación del caso de negocio, de la definición inicial delos requerimientos y/o de determinadas fases de prueba.

AI6.2Evaluación delimpacto

Revisar las normas, procedimientos, prácticas y tecnologías degestión del cambio de TI para comprobar que antes de la aproba-ción final:

• Se haya verificado que los requerimientos responden al casode negocio para el cambio.

• Se haya cumplido con los requerimientos tal como se evidenciómediante la prueba.

Revisar las normas, procedimientos, prácticas y tecnologías degestión del cambio de TI para comprobar que antes de la aproba-ción final, las pruebas hayan demostrado adecuadamente que elcambio no dañará el entorno de producción.

AI6.7 Políticade Versión deSoftware

Sólo se imple-mentan los cam-bios aprobados.

Obtener información de control de acceso a los códigos fuente yejecutables de producción (una muestra de estos). Comprobarque sólo los responsables de la implementación de los cambiospuedan modificarlos, añadirlos o eliminarlos.

AI6.6Mantenimientoautorizado

Revisar las políticas y normas para determinar que se requieranpistas de auditoría confiables y de fácil revisión de los cambiosoperados a los elementos de producción.

Revisar la tecnología de pistas de auditoría y los procesos asocia-dos. Nadie debe disponer de derechos de acceso permanentepara eliminar o modificar las pistas de auditoría. Estas se debenadministrar para que estén disponibles con el fin de facilitar lasrevisiones a corto plazo y para las investigaciones a largo plazo.

Revisar los procedimientos para analizar las pistas de auditoría delos cambios introducidos a los elementos de producción dentrodel alcance de la auditoría. Comprobar que se requiera revisiónindependiente, oportuna, seguimiento de las excepciones y evi-dencias de la revisión.


Revisar las normas, procedimientos, prácticas, y tecnologías degestión del cambio para determinar que los controles aseguranque los componentes implementados en la producción coincidencon los componentes desarrollados, probados y aprobados.

AI6.3 Controlde los cambios

Revisar las normas, procedimientos, prácticas y tecnologías degestión del cambio para determinar que los controles asegurenque los códigos fuente y ejecutables implementados en la produc-ción coincidan entre sí.


Los cambios imple-mentados cumplencon los requerimien-tos del negocio.

Revisar las políticas, normas y procedimientos de gestión del cam-bio de TI para determinar si los cambios con costo o riesgo signifi-cativos requieren la aprobación de los usuarios del negocio en lospuntos adecuados para ello.

AI6.1 Inicio ycontrol de lasolicitud decambio

Establecer a través de entrevistas y revisiones de la documenta-ción, que para cada cambio significativo haya una revisión poste-rior a la implementación que evalúa su eficacia y lo compare conel caso de negocio aplicado en la iniciación del cambio.

Es posibleque loscambios deTI ocasio-nen proble-mas deproducción.

Los cambios de TIse implementansiguiendo unasecuencia adecuaday sin interferir conotros cambios.

Revisar las normas, procedimientos, prácticas y tecnologías de ges-tión del cambio de TI para verificar que los controles aseguren:

• Que los cambios se implementen de forma periódica comoversiones y no como modificaciones aisladas al entorno deproducción.

• Que los cambios que puedan afectarse entre sí estén sincro-nizados adecuadamente (por ejemplo, que sólo un programa-dor por vez modifique un módulo dado).

AI6.7 Políticade Versión deSoftware

CLos cambios seimplementan deforma exacta ysegún lo planeado.

Se debe comprobar que la gestión del cambio, el control y la dis-tribución del software se integren de forma adecuada con un sis-tema integral de gestión de configuración.


Revisar las políticas, normas y procedimientos de gestión del cam-bio de TI para asegurar que los cambios documenten de forma ade-cuada los pasos necesarios para la implementación del cambio.

Verificar que el sistema utilizado para supervisar los cambios intro-ducidos a los sistemas de aplicación sea automático para respal-dar el registro y seguimiento de los cambios efectuados asistemas de información amplios y complejos.


Las operaciones deTI se pueden recu-perar de forma efi-ciente y eficaz de losproblemas relaciona-dos con el cambio.

Revisar las políticas, normas y procedimientos de gestión del cam-bio de TI para verificar que los cambios tengan la documentaciónadecuada para dejarlos sin efecto , antes de su puesta en escenaen producción.

Revisar las políticas, normas y procedimientos de gestión del cam-bio de TI para verificar que los cambios documenten exhaustiva-mente qué se cambió, cuándo y quién lo hizo. Todos los cambiosdeben contar con una organización exacta en todo momento (porejemplo, en su desarrollo, implementación retiro, cancelación, etc.).Dicha documentación debe ser de una exactitud confiable y defácil acceso.



GTAG — Apéndice A — Programa de auditoríade gestión del cambio — 9

36

Es posible quelas operacionesde producciónno se recupereneficientementede los problemasocasionados porlos cambios.

Los procesos de cam-bio y de gestión deproblemas están inte-grados.

Revisar las normas y procedimientos de la gestión delcambio para comprobar que cada cambio registre deforma explícita todos los problemas para cuya solución fuediseñado.

Revisar las normas y procedimientos de la gestión del pro-blema para comprobar que cada problema registre deforma explícita todos los cambios que hayan originado ocontribuido a dicho problema.

Los cambios quese deben imple-mentar más rápi-damente de loprevisto por elciclo normal decambio puedenevitar o compro-meter los contro-les de cambio.

Los cambios de emer-gencia se implementande tal manera que sepreservan los controlesde cambio.

Verificar que las políticas, normas y procedimientos degestión del cambio de TI establezcan parámetros paradefinir cambios de emergencia y procedimientos paracontrolar dichos cambios cuando soslayan el procesonormal de evaluación técnica, operativa y de gestión, antesde la implementación.

AI6.4 Cambiosde emergencia

Revisar los procedimientos de los cambios de emergenciapara comprobar que se puedan implementar de formarápida, eficaz y de manera que se preserve la responsabili-dad, identificación y revisión independiente.

Seleccione una muestra de cambios de emergencia reali-zados durante el plazo de la auditoría y verifique que:

• El cambio resultaba necesario por una emergenciaverdadera:

• Se siguieron procedimientos de emergencia.

• La gerencia de TI los registró y autorizó antes de suimplementación.

• Se notificó rápidamente a la gerencia adecuada de lasáreas afectadas.

• Se detectaron los cambios no aprobados y las excep-ciones se elevaron al nivel correspondiente y se resol-vieron con premura.

• Todo la limpieza necesaria se realizó con prontitud.

• Los manuales del usuario se actualizaron con los cam-bios que afectan la interfaz de usuario, el funcionamientodel programa, la seguridad y otros cambios.

AI6.4 Cambiosde emergencia



37


38

Roles en el ciclo de vida del cambio Títulos y roles típicos

Solicitante del cambio Unidad de negocio, operaciones de TI, seguridad, gerente deservicio.

Preparador del cambio Investigación y desarrollo, administrador de bases de datos,equipo de desarrollo de aplicaciones, programador de apli-caciones.

Aseguramiento de calidad, equipo de armado y preparación,equipo de preproducción, equipo de plataforma.

Aprobación del Cambio Gerente del cambio, consejo de asesoramiento para el cam-bio, comité de control del cambio, dirección de gestión delcambio.

Implementador del cambio Operaciones de TI, operaciones de redes, ingeniería deredes, administradores de sistemas, seguridad.

Revisor del cambio Gestión de las operaciones de TI, consejo de asesoramientopara el cambio, seguridad, auditoría.

Auditoría del cambio Gestión de las operaciones de TI, consejo de asesoramientopara el cambio, seguridad, auditoría.

Cuadro 4: Roles típicos

Para cada cambio… Debe ser independiente de…

Los implementadores Los solicitantes

Los operadores del entorno de producción Los preparadores

Los evaluadores Los preparadores

Los implementadores Los preparadores

Por lo menos uno de los responsables de la aprobación Los preparadores

Por lo menos uno de los responsables de la aprobación Los solicitantes

Por lo menos uno de los responsables de la aprobación Los implementadores

Los revisores Los implementadores

El auditor Todos los mencionados precedentemente

Cuadro 5: Separación de funciones

Fuentes: COBIT Control Objectives, 3º Edición, julio 2000: Planning & Organization 4 (P04), página 42, ISO/IEC17799:2001, Auditors Guide, Sección 8.1.4. Segregation of Duties

Las Tablas 4 y 5 muestran los roles típicos y los cargosasociados a estos, además de las obligaciones que no se debencombinar. Los auditores reconocerán rápidamente los para-lelos de estas pautas y las pautas típicas del procesamiento detransacciones. Por ejemplo, aquellos que administran lainfraestructura no deben auditarla. Aquellos que implemen-tan el cambio no deben aprobarlo. Aquellos que crean laaplicación no deben probarla, ejecutarla ni operarla.

Como se observó en la Sección 4.5 “Integración de laGestión de Parches a la Gestión de Cambio” (página 18),cuanto más complejo y dinámico es el entorno de produc-ción de TI, mayor es la necesidad de aplicar controles efica-ces. Dado que la cantidad de personas que implementancambios y las tasas de cambio se incrementan, también lohace la necesidad de aplicar monitorización y supervisiónautomáticas e independientes.

La Metodología de Operaciones Visibles, publicada por elInstituto de Procesos de TI (ITPI, en inglés), brinda unaorientación para los gerentes de TI sobre cómo desarrollarprocesos auditables y aceleradores en cuatro etapas. En laprimera etapa, se desarrolla un proceso de gestión del cambioviable atacando a los principales contribuyentes del trabajono planeado (por ejemplo, interrupciones autoimpuestas,períodos de reparación prolongados debido a la ausencia deinformación de cambios, etc.). Para “estabilizar al paciente”,debe hacer lo siguiente:

1. Reducir o eliminar el acceso: Retirar a todos de losactivos a menos que estén autorizados formalmente arealizar cambios. Dado que estos activos tienen bajastasas de éxito del cambio, debemos reducir la cantidadde reintentos.

a. Documentar la nueva política del cambio:Nuestra política de cambio recomendada es muysimple: “No realizar absolutamente ningúncambio en este activo a menos que yo lo autorice”.Esta política es nuestro control preventivo y creauna expectativa de comportamiento.

b. Notificar a las partes interesadas: Una vezestablecida la política de cambio inicial, se debenotificar a todas las partes interesadas acerca delnuevo proceso. Asegúrese de que todo el personallo vea. Envíelo por correo electrónico al equipo.Imprímalo. Agréguelo a los carteles de inicio desesión. Publíquelo en el sitio Web o en la páginade inicio del portal de Intranet.

2. Electrificar la barrera: Para hacer cumplir el nuevo pro-ceso de gestión del cambio, debe electrificar la barrera yasegurarse de que todos los cambios de producción sedetecten y se correlacionen con los cambios autorizados.Cuando se detectan cambios no autorizados, utilícelospara reforzar el proceso de cambio y refuércelo constan-temente. Por ejemplo, “Equipo, quiero ser claro en esto:estos procesos se desarrollaron para lograr el éxito detodo el equipo y no sólo el éxito individual. Por lo tanto,cualquiera que realice un cambio sin autorización soca-va el éxito del equipo y tendremos que hacer frente aeso. Como mínimo, tendrá que explicarle a todo el equi-po por qué realizó un cambio no autorizado. Si esto serepite, probablemente esa persona quede suspendida porun día y, con el tiempo, es posible que no sea más partede este equipo”.

3. Modificar la primera respuesta: clave para la acelera-ción: Para garantizar que el proceso de gestión delcambio le devuelva el valor a la organización, integreel proceso de gestión del cambio con la función de ges-tión de problemas. Asegúrese de que los administrado-res de problemas tengan toda la informaciónrelacionada con el cambio cuando trabajan con losproblemas. Dado que el 80 por ciento de las interrup-ciones se debe a los cambios y el 80 por ciento deltiempo promedio de reparación se emplea para inten-tar descubrir qué cambió, tener a mano esta informa-ción garantiza que toda la evidencia relevante y causalesté disponible. Por lo general, cuando se preparan deesta manera, los administradores de problemas puedendiagnosticar los problemas con éxito sin tener que

iniciar sesión en las infraestructuras más del 50 porciento del tiempo.

4. Crear el equipo para llevar a cabo el cambio: En lospasos anteriores, hemos comenzado a especificar elcamino correcto para el cambio y hemos desarrolladolos mecanismos para garantizar que se siga el proceso.En este paso, creamos el camino correcto para ir delcambio deseado al cambio autorizado. Creamos unConsejo de asesoramiento para el cambio (en inglés,CAB), compuesto por las partes interesadas relevantesde cada servicio de TI crítico. Estas partes interesadasson las personas que están mejor preparadas para tomardecisiones con respecto a los cambios debido a suconocimiento sobre los objetivos de negocio y los ries-gos técnicos y operacionales.

5. Crear un sistema de seguimiento de la solicitud decambio: Un requisito previo para cualquier proceso degestión del cambio eficaz es la habilidad de rastrear lassolicitudes de cambio (RFC, en inglés) a través delproceso de autorización, implementación y verifica-ción. Los sistemas de manuales impresos en papel rápi-damente se tornan poco prácticos cuando laorganización es grande o compleja o cuando existe unagran cantidad de cambios. Por eso, la mayoría de losgrupos utilizan medios computarizados para rastrear lassolicitudes de cambio y asignar los números de órdenesde trabajo. Algunos se refieren a estas aplicacionescomo “sistemas de emisión de boletos” o “sistemas deflujo del cambio”. Cualquiera sea la manera de rastre-ar los cambios que adopte, no permita que el uso de latecnología suplante la necesidad de un proceso sólido.

6. Inicio de las reuniones semanales sobre gestión decambio (para autorizar el cambio) e informes de cam-bio diario (para anunciar los cambios): Ahora quehemos identificado las partes interesadas en los cam-bios mediante la creación de un consejo de asesora-miento para el cambio, el próximo paso es crear unforo para que se puedan tomar decisiones sobre loscambios solicitados. El Consejo de asesoramiento parael cambio (CAB) autorizará, denegará o negociará uncambio con el solicitante. Los cambios autorizados seprogramarán, se implementarán y, finalmente, se veri-ficarán. El objetivo es crear un proceso que permita unrendimiento superior y exitoso del cambio para laorganización con la menor cantidad posible de proce-sos burocráticos. Si bien puede parecer anormal alprincipio, con la práctica, se pueden lograr reunionesde gestión del cambio de 15 minutos una vez por sema-na. En especial, trate de evitar la actitud de inmedia-tez y poca importancia, que hace que las personasrealicen cambios que soslayan el proceso de aproba-ción del cambio. Si facilitamos el flujo de todos loscambios a través de nuestro proceso, será más fácil uti-lizar el proceso que soslayarlo, incluso durante situa-ciones de emergencia.

La Metodología de Operaciones Visibles lo ayudará a desa-rrollar un proceso de gestión del cambio sostenible que iden-tifique y corrija rápidamente las causas de las bajas tasas deéxito del cambio.

39

GTAG — Apéndice B — Metodología de Operaciones Visibles — 10

40

GTAG — Apéndice C — Ejemplo Práctico deNegocio para la Gestión del Cambio — 11

Nuestros síntomas Causas subyacentes

“Al igual que muchas organizaciones de TI importantes, está-bamos experimentando los efectos de los cambios no docu-mentados. Sabíamos que se estaban produciendo, pero erandifíciles de rastrear, y en la atmósfera actual, tan consciente dela seguridad, esto era inaceptable”.

Niveles de servicio y disponibilidad deficientes.

Cantidad no conocida de cambios operativos.

Tasa de cambio no controlada.

Tasas de éxito del cambio bajas (inferiores a 70%).

Grandes cantidades de trabajo no planeado (inferior a 40%).

“Cuando se produjeron interrupciones en los sistemas fijos detransacciones entrantes, la mesa de ayuda fue la primera ensaberlo. Esto llegaba hasta el grupo de gestión de TI, quienorganizaba un equipo de respuesta y reunía los antecedentespara descubrir lo que había sucedido”.

Cuando los cambios fallaban, la investigación de las causas yla gestión de los problemas insumían más del 25% de la cargade trabajo.

Un diagnóstico inexacto conduce a una tasa de resoluciónde problemas en primera instancia baja (en inglés, FFR,inferior a 50%).

“Era como en el Lejano Oeste. La gente no documentaba suscambios y ni hablar de recibir una aprobación al respecto. Estose hacía evidente en nuestras estadísticas de disponibilidad”.

La ausencia de controles de detección en los procesos degestión del cambio genera un rendimiento deficiente.

La ausencia de los controles de cambio impide la prueba delos controles preventivos y de detección para que los audito-res puedan certificar que los controles son eficaces.

Cuadro 6: Problemas e indicadores de gestión ineficaz del cambio

Nuestra solución Ventajas

“Nos dimos cuenta de que las consecuencias inesperadas delos cambios representaban el factor que más contribuía a lageneración de trabajo no planeado. Formalizamos la aproba-ción requerida para realizar los cambios de producción y parainiciar el proceso. Además “electrificamos la barrera” paragarantizar que se respete el proceso de gestión del cambio”.

Mejor visibilidad de la gestión de los cambios propuestos.

Los cambios operativos son sólo los autorizados por el proce-so de gestión del cambio.

Un mayor control de la tasa de cambio puede generar incre-mentos en la tasa de éxito del cambio de hasta un 95% debi-do a la visibilidad y las pruebas.

“Comenzamos por crear una responsabilidad real en cuanto arendición de cuentas para que todos siguieran el proceso degestión del cambio. Elegimos nuestras reuniones de gestiónde disponibilidad diaria (en inglés, “reuniones DAMM), presidi-das por Kenny, nuestro vicepresidente de operaciones. Kennyrevisa todos los cambios fallidos con los implementadores delcambio y organiza una sesión especial para quienes hayanomitido el proceso de gestión del cambio. Digamos simple-mente que los cambios no autorizados y los de tipo subrepti-cio se producen con mucha menos frecuencia”.

(Este negocio en particular calcula el tiempo de inactividad a$7.000 por minuto).

La cantidad de cambios no autorizados se redujo de “varios aldía” a “varios al año”. Dado que cada interrupción requería doshoras para restablecer el servicio (un cálculo bastante conser-vador), se destinaban 5.000 horas de trabajo, teniendo encuenta una base anual.

Todos los cambios se documentan por completo, lo cual per-mite que se descarte el cambio en primer lugar en el ciclo dereparaciones, permitiendo que el tiempo de restauración pasede “horas” a “minutos”. Para las 11 interrupciones producidasen Q3, se ahorraron aproximadamente 13 horas de tiempo deinterrupción del sistema.

Cuadro 7: Beneficios de una transformación eficaz (basada en los resultados reales informados)

Las organizaciones de alto rendimiento utilizan los procesosde gestión del cambio de TI para reducir los riesgos e incre-mentar la eficacia y la eficiencia operativas. De esta manera,los beneficios de los controles eficaces de los cambios son sig-nificativos y medibles. Ser capaz de demostrar esto facilita latarea de desarrollo de un caso de negocio para mejorar loscontroles de cambios, a diferencia de hacerlo sólo para “com-

placer a la auditoría”. Como se describió en las seccionesanteriores, las mediciones operacionales clave están com-puestas por la tasa de fallos del cambio, el tiempo de recupe-ración en caso de cambios fallidos y el trabajo no planeadoresultante. El Cuadro 6 resume los indicadores de la gestiónineficaz del cambio. El Cuadro 7 describe las maneras desolucionar esto en función de la experiencia real en campo.

41

Nuestra solución Ventajas

“Nos dimos cuenta de que las consecuencias inesperadas delos cambios representaban el factor que más contribuía a lageneración de trabajo no planeado. Deseábamos aplicarmejor nuestras normas y poder eliminar el tiempo destinadoal trabajo de detección.

“Es más, la preparación para las auditorías pasó de represen-tar cuatro semanas de trabajo al año por cada proyecto aestar listo para cada auditoría en menos de medio día.

“Por último, solíamos tener tres equipos de cumplimiento dife-rentes: uno para el Artículo 404 de la Ley Sarbanes-Oxley,otro para la Ley Gramm-Leach Bliley y otro más para la Leyde Responsabilidad y Portabilidad del Seguro de Salud.Cuando nos dimos cuenta de que todas ellas requerían la pre-paración eficaz de reportes de controles de cambio, reempla-zamos todos esos equipos por uno solo encargado delcumplimiento de las tres leyes”.

El cumplimiento de las normas se maneja ahora como untema cotidiano, en lugar de una preparación de último minutoen el borde del colapso.

Dado que la prueba de controles de cambio eficaces se gene-ra con regularidad, los auditores externos no generaron cartascon comentarios para la gerencia (en comparación con el añopasado, se evitaron 130 horas de trabajo no planeado y dehonorarios de auditoría al respecto).

El mapa de los controles de cambio en función de los requeri-mientos regulatorios ordinarios reduce la cantidad de trabajoduplicado que hacen los equipos por separado. Se ha reasig-nado a doce miembros del personal de TI al equipo de opera-ciones de TI.

“Además de que todos nosotros ya no tenemos que usar loslocalizadores en nuestros hogares, hemos descubierto quedisponemos de más tiempo para trabajar en los proyectosplaneados, en lugar de estar apagando incendios todo eltiempo”.

El trabajo no planeado se redujo de más de un 40% a un 15%.

Las entregas puntuales de los proyectos pasaron de cero aun 60%.

El Director de TI (CIO) le ha asignado al grupo de gestión de TIlos proyectos estratégicos clave para el año siguiente.

Cuadro 7: Beneficios de una transformación eficaz (basada en los resultados reales informados) (continuación)

GTAG — Apéndice C — Ejemplo Práctico deNegocio para la Gestión del Cambio — 11

42

GTAG — Apéndice D — Herramientas de la Gestióndel Cambio y Proveedores — 12

A continuación se presentan algunas de las herramientasmás utilizadas para automatizar los procesos descritos en estaguía:

• Visible Ops Handbook: Starting ITIL in Four PracticalSteps.

• Flujo de gestión del cambio (control preventivo).– BMC/Remedy Action Request System.

(http://www.remedy.com/solutions/coretech/index.html)

– HP Service Desk.– (http://managementsoftware.hp.com/products/

desk/index.html).• Auditoría y supervisión de cambios (control de detección).

– Tripwire for Servers and Networking Devices(http://www.tripwire.com)

El material para el ejemplo de la guía de auditoría presenta-do en el Apéndice A se extrajo, en parte, de http://audit-net.org/asapind.htm.

[Allen 04] Allen, Julia; Behr, Kevin; Kim, Gene et al.Best in Class Security and Operations Round Table Report(CMU/SEI-2004-SR-002). Pittsburgh, PA: SoftwareEngineering Institute, Carnegie Mellon University, Marzode 2004. Disponible mediante solicitud.

[BDO 04] BDO Seidman LLP, et al. A Framework forEvaluating Control Exceptions and Defiencies. BDO SeidmanLLP, Crowe Chizek and Co. LLC, Deloitte & Touche LLP,Ernst & Young LLP, Grant Thornton LLP, Harbinger PLC,KPMG LLP, McGladrey & Pullen LLP,PricewaterhouseCoopers LLP, 20 de diciembre de 2004.Disponible en varios sitios incluidohttp://www.kpmg.com/Rut2000_prod/Documents/9/US_DPP_ICOFR_04_024_A01.pdf.

[BITS 04] BITS Financial Services Roundtable. PatchManagement Best Practices for IT Service Providers. BITS,julio de 2004. Disponible en http://www.bitsinfo.org/bits-patchmgmt2004.pdf

[Chambers 03] Chambers, Andrew. Tolley's CorporateGovernance Handbook: 2nd Edition, Appendix B: Fraud.Lexis Nexis, 2003.

[CISWG 04] Corporate Information Security WorkingGroup. Subcommittee on Technology, Information Policy,Intergovernmental Relations & the Census GovernmentReform Committee, U.S. House of Representatives. Reportof the Best Practices and Metrics Teams. 17 de noviembre de2004. Disponible mediante solicitud.

[COSO 04] The Committee of SponsoringOrganizations of the Treadway Commission. Enterprise RiskManagement - Integrated Framework. Septiembre de 2004. Elresumen ejecutivo y la información de solicitud están dispo-nibles en http://www.coso.org.

[Gartner 03] Series on Change Management:• Brittain, Kris. Change Management Makes an

Impact on IT Service Quality. Note AV-19-3311,Gartner, 13 de marzo de 2003.

• Scott, Donna; Brittain, Kris. Defining IT ChangeManagement. Research Note COM-19-1428,Gartner, 6 de marzo de 2003.

• Brittain, Kris; Scott, Donna. Critical FactorsPowering Operational Change Management.Research Note DF-18-4179, Gartner, 4 de marzode 2003.

• Scott, Donna; Brittain, Kris. Best Practices forOperational Change Management. CommentaryCOM-19-1253, Gartner, 6 de marzo de 2003.

• Brittain, Kris; Scott, Donna. Governance/PolicyBack Operational Change Management.Commentary COM-18-4180, Gartner, 6 de marzode 2003.

[Gall 86] Gall, John. Systemantics: The UndergroundText of Systems Lore, General Systemantics Press, 1986.

[Goldratt 92] Goldratt, Eliyahu; Cox, Jeff. The Goal: AProcess of Ongoing Improvement, 2nd Rev edition, North RiverPress, mayo de 1992.

[Hulme 04] Hulme, George. “Federal CISOs RankPatch Management As Biggest Obstacle.” InformationWeek,22 de noviembre de 2004. Disponible en http://information-week.com/story/showArticle.jhtml?articleID=53701321.

[ITIL 00] Information Technology InfrastructureLibrary (ITIL)®14. Office of Government Commerce. Vayaa http://www.ogc.gov.uk/index.asp?id=2261 yhttp://www.itsmf.com. Consulte específicamente BestPractice for Service Support, Capítulo 8 Change Management(2000).

[ITPI 04] Behr, Kevin; Kim, Gene; Spafford, George.Visible Ops Handbook: Starting ITIL in Four Practical Steps. ITProcess Institute, 2004. La información de presentación ysolicitud está disponible en http://www.itpi.org.

[Kim 03] Kim, Gene. “High-Performing IT Operationsand Security Workshop Findings: Part 1.” ComputerWorld,diciembre de 2003. Disponible en http://www.computer-world.com/securitytopics/security/story/0,10801,91205,00.html?nas=SEC2-91205.

[Mair 73] Mair, William; Wood, Donald; Davis, Keagle.Computer Control and Audit. Touche Ross & Co., 1972,1973, 1976 y 1978. Distribuido anteriormente por TheInstitute of Internal Auditors, Inc. Ya no se encuentra dispo-nible en formato impreso.

[O’Reilly 98] O’Reilly, Vincent; McDonnell, Patrick;Winograd, Barry; Gerson, James; Jaenicke, Henry.Montgomery's Auditing, 12th Edition. Wiley, 1998.

[PWC 04] PriceWaterhouseCoopers. The Discipline ofEnterprise Patch Management: A Critical Component of aBroader Approach to Protection, 2004. Disponible enhttp://www.pwcglobal.com/extweb/manissue.nsf/DocID/5BF8D134DFEE39A385256E5F006A0F89.

[Salamasick 03] Salamasick, Mark. PC ManagementBest Practices - A Study of the Total Cost of Ownership, Risk,Security, and Audit. The Institute of Internal AuditorsResearch Foundation, Noviembre de 2003. La informaciónde solicitud está disponible enhttp://www.theiia.org/iia/bookstore.cfm?fuseaction=pro-duct_detail&order_num=482.

[Tipton 00] Tipon, Hal, Miki Kraus.Handbook Information Security Management. AuerbachPublications, 2000.

43

GTAG — Guía de Auditoría de Tecnología Global Referencias — 13

44

GTAG — Guía de Auditoría de TecnologíaGlobal — Acerca de los autores — 14

Julia H. Allen es miembro superior del personal técnico delprograma Networked Systems Survivability en el Institutode Ingeniería de Software (SEI, en inglés), una unidad de laUniversidad Carnegie Mellon en Pittsburgh, Pensilvania. Elcentro de coordinación CERT® también forma parte de esteprograma.Allen participa en el desarrollo y transición de los enfoquesde seguridad empresarial y los programas de alcance ejecuti-vo en la seguridad y dirección empresarial. Con anterioridada esta asignación técnica, Allen se desempeñó como directo-ra suplente del SEI durante un período interino de seis mesesy como vice directora/directora de operaciones durante tresaños. Posee el título de Licenciada en Ciencias de laComputación (Universidad de Michigan) y una Maestría enIngeniería Eléctrica (Universidad de Southern California).Es autora de The CERT Guide to System and NetworkSecurity Practices (Addison-Wesley, Junio de 2001).Información de contacto:Carnegie Mellon UniversitySoftware Engineering Institute4500 Fifth Ave.Pittsburgh, PA 15213 Estados [email protected], [email protected]

Glenn L. Hyatt, CIA, CISA, CISSP es gerente de seguri-dad de datos en General Motors Acceptance Corp.(GMAC) Mortgage, donde administra las operaciones einvestigaciones de seguridad de la información. Hyatt se hadesempeñado durante más de 20 años en cargos relacionadoscon TI, desde programador hasta gestión de seguridad de lainformación, consultoría de TI y gerencia de auditoría de TI.Anteriormente trabajó en Federal Reserve Bank ofPhiladelphia, Citibank y Ernst & Young. Posee una Maestríaen Ciencias de la Computación e Información de laUniversidad de Delaware.Información de contacto:GMAC Mortgage4 Walnut Grove Dr., 190-400-215Horsham, PA 19044 Estados [email protected]

Gene H. Kim, CISA, es el director de tecnología (en inglés,CTO) y fundador de Tripwire Inc. En 1992, fue coautor deTripwire mientras estaba en la Universidad de Purdue con elDr. Gene Spafford. En el año 2004, escribió The Visible OpsHandbook y cofundó el Instituto de Procesos de TI, dedicado ala investigación, comparación y desarrollo de orientaciónprescriptiva para los auditores y la gestión de seguridad y ope-raciones de TI. Actualmente trabaja, de manera activa, con elInstituto de Ingeniería de Software y el Instituto de AuditoresInternos para investigar cómo las mejores organizaciones inte-gran las operaciones de TI, la seguridad, la administración, ladirección y el trabajo de auditoría para alcanzar los objetivoscomunes del negocio. Actualmente, Kim participa de laComisión de Tecnología Avanzada del IIA.Kim posee una Maestría en Ciencias de la Computación dela Universidad de Arizona y es Licenciado en Ciencias de laComputación de la Universidad Purdue. Recientemente,

Kim fue nombrado uno de los “Top 4 CTOs to Watch” porla revista InfoWorld debido a sus “actividades de vanguardiay de avanzada”. También fue uno de los presidentes del tallertécnico de SANS en abril del 2003, denominado AuditableSecurity Controls That Work y considerado por SANScomo uno de los cinco regalos más importantes a la comuni-dad y una de las principales iniciativas del 2003. Kim fue unode los presidentes de Best in Class Security and OperationsRoundtable (BIC-SORT) junto con el Instituto deIngeniería de Software en octubre de 2003. Kim posee certi-ficaciones en procesos de auditoría y gestión de TI, tanto deITIL Foundations como de CISA.Información de contacto:Gene KimTripwire Inc.326 SW Broadway Ave., 3rd FloorPortland, OR 97205 Estados [email protected]

Jay R. Taylor, CIA, CFE, CISA, es director general deAuditoría de Tecnología de Información de General MotorsCorp. y es el responsable de evaluar los riesgos y proporcionarauditoría interna global y servicios de consultoría con respec-to a las unidades de negocio e inversiones conjuntas deGeneral Motors y General Motors Acceptance Corp. en todoel mundo. GM opera en un entorno sumamente complejo uti-lizando numerosos proveedores de TI de todo el mundo.Taylor obtuvo su Maestría en Administración de Empresas(MBA) en la Universidad de Michigan y trabaja activamenteen el Comité Internacional de Tecnología de Avanzada delInstituto de Auditores Internos. Anteriormente, trabajó en elComité Internacional de Productos Educativos del IIA y fuepresidente del Capítulo de Mid-Michigan del IIA y miembrode la Junta de Gobierno del Capítulo de Detroit. Sus contri-buciones profesionales recientes incluyen presentaciones rea-lizadas en la Conferencia sobre la Gestión del RiesgoEmpresarial del IIA y en la Conferencia sobre Prácticas deLiderazgo y Tendencias Emergentes del IIA, ambas realizadasen el año 2004.Información de contacto:General Motors Corp.300 Renaissance CenterMail Code 482-C18-B76Detroit, MI 48265-3000 Estados [email protected]

GTAG — Equipo de Revisión de Proyecto

Equipo de Revisión de Proyecto

Charlie LeGrand, CHL Associates

Claude Cargou, AXA

Norman Marks, Maxtor

Warren Malmquist, Coors

Larry Brown, Options Clearing Corporation

Michael Prospect, SIAC

Jennifer Bayuk, Bear Stearns

Rod Brennan, Siemens

Angelina Chin, General Motors Corporation

Clint Kreitner, Center for Internet Security

Jon Stanley, General Motors Corporation

Ed Hill, Protiviti

Mark Salamasick, Universidad de Texas

Sydney Leo, KPMG

Matt Snyder, General Motors Corporation

Bill Shinn, Washington Mutual

James Christiansen, Experian

Carol Woody, Universidad Carnegie Mellon, Instituto de Ingeniería de Software

Stuart M.McCubbrey, General Motors Corporation

www.theiia.org

Controles de gestión de parches y cambios

Esta guía fue desarrollada para ayudar a los DEA a realizar las preguntas deTI correctas a la organización a evaluar su capacidad de gestión de cambio.Describe las fuentes de cambio a su probable impacto sobre los objetivos denegocio, así como también de qué manera los controles de gestión de parchey cambios ayudan a gestionar los riesgos y costos de TI.

¿Qué es GTAG?

La Guía de Auditoría de Tecnología Global (GTAG) ha sido preparada porel Instituto de Auditores Internos y está escrita en un lenguaje de negociosclaro y directo para abordar temas de actualidad relacionados con la gestión,el control o la seguridad de la tecnología de la información. GTAG es unacolección de recursos lista para ser utilizada por los directores ejecutivos deauditoría en la educación de los miembros del Consejo de Administración ydel Comité de Auditoría, Dirección, propietarios de los procesos y otros enlo que respecta a riesgos asociados a la tecnología y prácticas recomendadas.

Controles de gestión de parches y cambios: cruciales para el éxito de la organización

Documents

Transcript of Controles de gestión de parches y cambios: cruciales para el éxito de la organización