Modelo operativo TI: roles, decisiones y responsabilidades

Un organigrama no explica cómo se toman las decisiones

El modelo operativo describe cómo se conectan servicios, personas, proveedores, procesos y decisiones. Una empresa puede tener responsables técnicos competentes y aun así sufrir retrasos si no está claro quién prioriza cambios, acepta riesgos, aprueba gasto o coordina una incidencia entre áreas.

No existe una estructura única que sirva a todas las organizaciones. El diseño depende de tamaño, regulación, criticidad de los servicios, capacidades internas y dependencia de terceros. Conviene definir los resultados esperados antes de dibujar comités o crear nuevos puestos.

Parte del catálogo de servicios

Lista servicios entendibles para negocio: identidad, puestos de trabajo, ERP, conectividad, atención al cliente, alojamiento y aplicaciones críticas. Para cada uno registra usuarios, procesos que soporta, horario, dependencias, proveedor, propietario de negocio, responsable técnico y canal de soporte.

Después asigna derechos de decisión concretos:

Decisión	Responsable que propone	Quién aprueba	A quién se consulta
Priorizar una mejora	Propietario de servicio	Comité o responsable de cartera	Usuarios y equipo técnico
Aceptar riesgo residual	Responsable del riesgo	Autoridad definida por política	Seguridad, legal y negocio
Ejecutar cambio estándar	Equipo de operación	Flujo delegado aprobado	Propietario del servicio
Activar continuidad	Responsable de incidente	Mando de continuidad	Áreas afectadas y proveedor

Es una plantilla de conversación, no una distribución obligatoria. Sustituye roles genéricos por nombres o equipos reales y define suplencias cuando una persona clave no está disponible.

Evita responsabilidades ambiguas

Cada decisión debe tener una autoridad final identificable. Distingue quién ejecuta, quién responde por el resultado y quién debe ser informado. Documenta los límites de delegación: qué cambios son estándar, qué excepciones requieren revisión y cuándo una incidencia escala a dirección.

Revisa también la relación con proveedores. Un contrato puede asignar tareas de soporte, pero la empresa sigue necesitando un propietario interno que entienda el impacto, valide entregables y decida si acepta el riesgo o la indisponibilidad.

Mide si el modelo funciona

Revisa tiempos de decisión, cambios reprogramados por falta de aprobación, incidentes sin propietario, riesgos vencidos, servicios sin suplente y compromisos de proveedor pendientes. No uses el número de reuniones como indicador de gobierno.

Cuando se trate de ciberseguridad, el NIST CSF 2.0 incluye resultados sobre responsabilidades, autoridades, rendición de cuentas y asignación de recursos. Puede ayudar a comprobar si la gobernanza del riesgo tecnológico es explícita, sin convertirlo en un organigrama prescriptivo.

Cruza este mapa con la matriz de evaluación de proveedores tecnológicos y con la revisión de beneficios de transformación digital.

Referencias

• NIST Cybersecurity Framework 2.0, categoría Roles, Responsibilities, and Authorities
• NIST CSF 2.0, publicación oficial