Seis reglas de TI que merece la pena romper y salirte con la tuya

Llega un momento en la vida de todo líder de TI en el que se debe tomar una decisión clave: seguir una regla establecida o, por necesidad, romper precedentes y embarcarse en un rumbo alternativo.

Las reglas de gestión suelen existir para permitir una toma de decisiones impecable, sentar las bases para una operación consistente y brindar protección contra riesgos, observa Ola Chowning, socio de la firma global de asesoría e investigación tecnológica ISG. “La violación de una regla ocurre a menudo después de que el CIO sopesa el riesgo de eliminar o mantener un mandato”, señala. "Ambas opciones representan cierto nivel de riesgo financiero, regulatorio o de desempeño".

Las reglas pueden ser amplias o precisas, continúa Chowning. Pueden aplicarse a personas, procesos, comportamiento empresarial y requisitos y riesgos tecnológicos. Todos están establecidos para ayudar a la organización a cumplir con el compliance y lograr objetivos esenciales.

Aun así, hay ocasiones en las que seguir una regla establecida desde hace mucho tiempo simplemente no tiene sentido. A continuación se presenta un resumen de seis políticas o protocolos de TI que, en determinadas situaciones, con ciertas barreras establecidas, se pueden ignorar.

 

Procesos de gestión de cambios de código

Una regla que ocasionalmente se puede romper sin repercusiones externas es enviar código nuevo o una nueva capacidad a producción sin seguir primero el proceso de gestión de cambios requerido, dice Chowning.

La gestión de cambios tiene como objetivo garantizar un nivel consistente de supervisión, confirmando que se han completado los niveles prescritos de pruebas, que las operaciones están listas para aceptar el cambio y que existen suficientes planes alternativos en caso de que el cambio resulte en una interrupción del cliente o del negocio. Sin embargo, cuando es necesario implementar rápidamente un cambio específico, puede estar bien omitir el proceso de gestión de cambios o revisarlo posteriormente.

El mayor riesgo que enfrenta un líder de TI que elude el proceso de gestión de cambios es la posibilidad de un impacto negativo significativo en las operaciones comerciales y/o internas. "Un aspecto importante de este tipo de infracción de reglas es mitigar el riesgo lo más rápido posible siguiendo, después del cambio, las actividades que habrían abordado estos elementos si se hubiera seguido la regla inicial de gestión de cambios”.

Es necesario sopesar los factores relevantes de forma clara y concisa para justificar la decisión de omitir el proceso de gestión de cambios. Los líderes que pueden establecer beneficios financieros o relacionados con el tiempo para mitigar el riesgo de romper la regla pueden demostrar que han pensado en las repercusiones de la decisión y tienen una visión objetiva del equilibrio entre riesgo y valor, comenta el ejecutivo.

 

Cambiar las reglas del período de congelación

Una regla de TI que a veces se puede descartar es la regla del período de congelación de cambios, durante la cual no se permiten nuevas implementaciones o actualizaciones del sistema durante un período de tiempo específico, generalmente alrededor de ciclos comerciales clave o días festivos.

Hay situaciones en las que es posible que sea necesario romper esta regla, como cuando un parche de seguridad crítico o una necesidad comercial urgente exigen cambios inmediatos en el sistema, dice el consultor de estrategia de producto Michael Hyzy. "En tales escenarios, el beneficio inmediato de implementar el cambio supera la precaución estructurada que la norma pretende imponer".

Los riesgos potenciales a considerar incluyen tiempo de inactividad del sistema, interrupciones en el flujo de trabajo o incluso vulnerabilidades de seguridad si la cancelación no se gestiona de manera inteligente. "Por lo tanto, es vital realizar un análisis de impacto riguroso y contar con planes de reversión antes de continuar", aconseja.

Justificar la decisión requiere una comunicación abierta con los miembros del equipo de TI y los líderes gerenciales. "Empieza por exponer la situación, los riesgos de no realizar el cambio y las medidas de preparación implementadas para mitigar las posibles consecuencias", dice Hyzy. "El objetivo es que todos estén en sintonía y tomen una decisión colectiva e informada".

Si bien las reglas son esenciales para mantener el orden y la previsibilidad, las situaciones excepcionales exigen acciones excepcionales, afirma Hyzy. "Ser demasiado rígido a veces puede poner a la organización en mayor riesgo que una infracción calculada de las reglas, siempre que se haga de manera transparente, inteligente y con plena preparación para cualquier contingencia".

 

Compromisos de priorización de la automatización

La automatización, particularmente cuando incorpora inteligencia artificial, presenta muchos beneficios, incluida una mayor productividad, eficiencia y ahorro de costes. Debería ser, y suele ser, una máxima prioridad de TI. Es decir, a menos que una organización esté lidiando con una tarea compleja o novedosa que requiera un toque humano matizado, dice Hamza Farooq, fundador de una startup y profesor adjunto en UCLA y Stanford.

Romper un compromiso general con la priorización de la automatización puede justificarse cuando las tareas implican resolución creativa de problemas, consideraciones éticas o situaciones en las que la comprensión de la IA de una actividad o proceso en particular puede ser limitada. "Por ejemplo, manejar quejas delicadas de los clientes que exigen empatía e inteligencia emocional podría ser más adecuado para la interacción humana", dice Farooq.

Si bien dejar de lado la automatización puede, en algunas situaciones, conducir a resultados más éticos y una mayor satisfacción del cliente, también existe el riesgo de obstaculizar un proceso organizacional clave. "La dependencia excesiva de la intervención manual podría afectar la escalabilidad y la eficiencia en las tareas rutinarias", advierte Farooq, señalando que es importante establecer pautas claras para identificar casos en los que se debe evitar un proceso de automatización. "Esta decisión debe comunicarse de forma transparente tanto a los clientes como a los equipos internos", recomienda.

 

Prohibiciones de conexión a redes externas

Cuando se trata de infraestructura crítica, una regla de TI común es nunca vincular los sistemas de producción directamente a redes externas. Sin embargo, Kristin Demoranville, directora ejecutiva de AnzenSage, una consultora de ciberseguridad centrada principalmente en la industria alimentaria, no está de acuerdo. "Si bien esta regla se establece con la mejor intención de proteger los sistemas sensibles de amenazas externas, hay casos en los que podría ser necesario hacer excepciones", defiende.

Hay momentos en los que compartir datos en tiempo real se vuelve imperativo, afirma Demoranville. "Por ejemplo, si es necesario realizar controles de calidad inmediatos con laboratorios externos o cuando se colabora con proveedores a escala global con fines de trazabilidad". En tales casos, la conectividad directa puede acelerar los procesos, garantizando que los productos alimenticios cumplan sin demora los estándares de seguridad y calidad.

Si bien las reglas y protocolos de TI son esenciales, deberían servir a la misión, no obstaculizarla. "A medida que tomamos estas decisiones, siempre debemos priorizar la seguridad, la calidad y la transparencia".

 

Regulación de la gestión de activos

Romper esta regla puede tener sentido siempre que surja un problema técnico en los datos de inventario que se capturan, o en situaciones en las que se bloquea el acceso de los usuarios finales a los sistemas empresariales, asevera David Scovetta, director de Seguridad y Cumplimiento del desarrollador de formularios personalizados FormAssembly. También es posible que sea necesario dejar de lado temporalmente la regulación de la gestión de activos cada vez que se implementa un nuevo sistema que no se ajusta a los criterios de inventario existentes.

Antes de infringir esta regla, asegúrese de considerar los riesgos, advierte Scovetta. “Abordar estos escenarios generalmente requiere la cooperación entre TI y los líderes de seguridad; sin embargo, puede tener sentido romper la regla siempre que existan salvaguardas que puedan caracterizar los dispositivos mediante políticas de configuración, incluso si no se cuenta con una empresa que registre el dispositivo o su dueño”.

 

Cualquier regla o política de TI, en caso de emergencia

A veces las reglas establecidas pueden ser ignoradas cuando surge repentinamente una situación de crisis. "Hay algunos escenarios en los que tiene sentido pedir perdón en lugar de permiso", dice Jesse Stockall, arquitecto jefe de Snow Software.

Los incidentes de seguridad, por ejemplo, a menudo requieren que se tomen decisiones rápidamente, y si los tomadores de decisiones de alto nivel no están disponibles, determinar una respuesta puede ser crítico. Stockall señala, sin embargo, que las decisiones importantes aún deben basarse en la antigüedad y la confianza. "Los empleados jóvenes no deberían comportarse de forma deshonesta", advierte.

Aun así, TI es un espacio inherentemente innovador, lo que significa que hacer las cosas según las reglas no siempre producirá los resultados deseados. Alguien con experiencia y buen juicio probablemente pueda modificar las reglas según sea necesario y, a menudo, a este tipo de empleados se les da un control más largo.

No obstante, las políticas existen por una razón, dice Stockall. La infracción de las reglas nunca debería convertirse en una práctica rutinaria de TI. "Los empleados deshonestos invitan al riesgo, arruinando la flexibilidad en el lugar de trabajo para todos con un comportamiento atroz", incide. "Sugerir que existe una política de TI que siempre se puede anular es una mala práctica".

Stockall cree que la TI está entrando en una era en la que habrá aún más reglas y políticas. "Estas barreras existirán por una razón, incluido el aumento de los ataques a la ciberseguridad, los riesgos para la propiedad intelectual y las incógnitas que rodean a la IA generativa".