Una tensión organizativa común en muchas empresas medianas
En muchas empresas medianas existe una tensión recurrente entre los departamentos de IT y Operaciones. No suele ser un conflicto visible ni explícito, pero sí aparece en la práctica diaria: solicitudes que tardan meses en resolverse, proyectos que cambian de prioridad o equipos que sienten que trabajan con objetivos diferentes.
El origen de esta tensión rara vez está en las personas. En la mayoría de los casos responde a una diferencia estructural en incentivos y responsabilidades.
Los equipos de IT suelen medirse por variables como:
- estabilidad de los sistemas
- cumplimiento de estándares técnicos
- seguridad y gestión del riesgo
- fiabilidad de la infraestructura
Mientras que Operaciones suele estar evaluado por indicadores como:
- eficiencia de procesos
- cumplimiento de plazos
- reducción de costes operativos
- satisfacción del cliente interno o externo
Cuando un equipo de IT afirma que un proyecto no puede priorizarse en el corto plazo, normalmente está intentando proteger la estabilidad de sistemas críticos. Cuando Operaciones insiste en que necesita una solución con urgencia, suele estar reaccionando al impacto real que un problema operativo tiene en el negocio.
Comprender esta asimetría suele ser el primer paso para mejorar la colaboración entre ambos departamentos.
Causas habituales del conflicto entre IT y Operaciones
Aunque cada organización tiene su contexto, hay varios factores que aparecen con frecuencia.
El problema del backlog infinito
En muchas organizaciones, el número de solicitudes que recibe IT supera claramente su capacidad disponible.
Sin un proceso claro de priorización, estas solicitudes pueden terminar organizándose según criterios poco estructurados, como:
- urgencia percibida
- visibilidad del solicitante
- presión interna
- orden de llegada
Este tipo de dinámicas rara vez optimiza el valor global para la organización.
La asimetría de información
Otro factor habitual es la falta de información compartida.
IT muchas veces no conoce el impacto económico real que tiene para el negocio no resolver un problema concreto. Operaciones, por su parte, puede no tener visibilidad sobre la complejidad técnica o las dependencias entre proyectos.
Cuando ambas partes toman decisiones con información incompleta, la priorización tiende a generar frustración.
Diferencias en el horizonte temporal
IT suele trabajar con una perspectiva de medio y largo plazo: arquitectura tecnológica, deuda técnica, actualizaciones de sistemas o ciclos de seguridad.
Operaciones, en cambio, suele centrarse en horizontes más cortos: semanas o meses, campañas comerciales, cierres financieros o picos de actividad.
Sin un marco compartido que permita reconciliar estos horizontes temporales, cada reunión de priorización puede convertirse en una negociación difícil entre perspectivas distintas.
Modelos de financiación que incentivan el conflicto
En muchas organizaciones, IT funciona como un centro de coste mientras que las áreas operativas están orientadas a resultados.
Este modelo puede generar incentivos contradictorios.
Operaciones tiene incentivos para solicitar tantas mejoras como sea posible, mientras que IT tiende a ser conservador porque cada proyecto consume recursos limitados. El resultado es una dinámica estructural de fricción que luego se intenta resolver mediante coordinación informal.
Un posible framework para mejorar la alineación
Distintas organizaciones han abordado este problema con enfoques relativamente similares. A continuación se describen algunas prácticas que, en muchos contextos, han demostrado mejorar la colaboración entre IT y negocio.
1. Establecer un proceso formal de priorización conjunta
Una de las intervenciones más simples y efectivas suele ser introducir un proceso de priorización compartido.
En lugar de que cada área envíe solicitudes de forma aislada, las iniciativas se revisan periódicamente en un foro conjunto donde participan IT, negocio y dirección.
Para estructurar esta conversación, algunas organizaciones utilizan frameworks de priorización como ICE (Impact, Confidence, Ease) o RICE (Reach, Impact, Confidence, Effort).
El objetivo no es el modelo en sí, sino crear un proceso percibido como legítimo por todas las partes.
En muchos casos, una reunión mensual de priorización de una hora puede mejorar notablemente la transparencia del proceso.
2. Estimar el coste de no resolver el problema
Otro cambio útil consiste en que cada solicitud incluya una estimación del coste de no actuar.
Esto puede expresarse, por ejemplo, en:
- horas de trabajo manual necesarias
- errores que se producen en el proceso actual
- oportunidades comerciales que se pierden
Este ejercicio suele tener dos efectos positivos.
Por un lado, obliga a las áreas de negocio a cuantificar mejor sus necesidades. Por otro, permite a IT comparar solicitudes utilizando criterios más objetivos.
3. Separar capacidad entre mantenimiento e innovación
En muchas organizaciones, las tareas de mantenimiento compiten directamente con proyectos nuevos por los mismos recursos.
Esto suele generar tensiones porque actividades como:
- corrección de errores
- actualizaciones de seguridad
- cambios regulatorios
son necesarias pero no generan visibilidad inmediata.
Una práctica habitual consiste en asignar explícitamente porcentajes de capacidad a distintos tipos de trabajo. En algunos entornos se observa una distribución aproximada como:
- alrededor de 40-50% para mantenimiento y mejora continua
- en torno a 30-40% para proyectos nuevos
- aproximadamente 10-20% para reducción de deuda técnica
La distribución concreta dependerá del contexto tecnológico de cada organización.
4. Permitir citizen development con gobernanza
Otra forma de aliviar el problema de capacidad es ampliar quién puede construir soluciones dentro de la organización.
Con el marco adecuado de gobernanza, algunos equipos de negocio pueden desarrollar herramientas de baja complejidad mediante plataformas low-code o no-code aprobadas.
Esto permite que el departamento de IT concentre sus recursos en proyectos que realmente requieren conocimiento técnico especializado, mientras que las necesidades operativas más simples se resuelven de forma más rápida.
En este modelo, IT mantiene un papel clave como habilitador, definiendo estándares, herramientas aprobadas y prácticas de seguridad.
5. Introducir métricas de éxito compartidas
Uno de los cambios más profundos suele ser redefinir cómo se mide el éxito de ambos departamentos.
Si IT se evalúa exclusivamente por estabilidad técnica y Operaciones solo por eficiencia operativa, es probable que los incentivos sigan estando desalineados.
Algunas organizaciones introducen indicadores que cruzan ambas perspectivas, como por ejemplo:
- impacto en negocio de proyectos tecnológicos
- nivel de adopción de herramientas internas
- reducción de trabajo manual en procesos clave
Cuando ambos equipos comparten objetivos medibles, la conversación cambia de naturaleza.
Cómo introducir estos cambios sin generar más política interna
Intentar resolver el conflicto entre IT y Operaciones puede generar nuevas tensiones si se plantea como una reforma organizativa demasiado amplia desde el inicio.
En muchos casos, resulta más efectivo empezar con iniciativas acotadas.
Un enfoque habitual consiste en seleccionar un proceso concreto —por ejemplo, la priorización de proyectos de un área— y aplicar el nuevo modelo durante unos meses. Si el resultado es positivo, puede ampliarse progresivamente.
El patrocinio de la dirección suele ser importante en este tipo de iniciativas. Cuando el liderazgo ejecutivo comunica que la alineación entre tecnología y negocio es una prioridad organizativa, el proceso suele percibirse como una mejora estructural y no como una pérdida de poder para alguno de los departamentos.
El papel de soluciones externas en determinados proyectos
En algunos casos, las organizaciones complementan la capacidad interna con equipos externos especializados para determinados tipos de proyectos.
Este enfoque puede resultar útil cuando existen necesidades operativas urgentes que no encajan fácilmente en el roadmap actual de IT.
Por ejemplo, herramientas como:
- dashboards operativos
- automatizaciones de procesos
- portales internos
- aplicaciones departamentales
pueden desarrollarse externamente en paralelo, siempre que exista coordinación con IT y claridad sobre la propiedad y el mantenimiento posterior.
No todos los proyectos son adecuados para este modelo. Sistemas críticos, integraciones profundas con el core tecnológico o aplicaciones con requisitos estrictos de seguridad suelen requerir una supervisión directa del departamento de IT.
Sin embargo, en algunos contextos, combinar capacidad interna y externa puede reducir tensiones organizativas y acelerar la resolución de problemas operativos concretos.
Referencias bibliográficas
[1] Weill,P., & Ross, J. W. (2021). IT Governance: How Top PerformersManage IT Decision Rights for Superior Results. Harvard BusinessReview Press.
[2] Westerman,G., Calméjane, C., Bonnet, D., Ferraris, P., & McAfee, A.(2022). Digital Transformation: A Roadmap for Billion-DollarOrganizations. MIT Center for Digital Business.https://www.capgemini.com/wp-content/uploads/2017/07/Digital_Transformation__A_Road-Map_for_Billion-Dollar_Organizations.pdf
[3] Gartner.(2024). How to Build a Productive IT-Business Relationship. GartnerResearch.https://www.gartner.com/en/documents/it-business-relationship
[4] McKinsey& Company. (2023). The CIO agenda: How to become a strategicpartner to the business. McKinsey Digital.https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-new-cio-playbook
[5] ForresterResearch. (2024). The Business Technologist: Bridging The IT-BusinessGap. Forrester Reports.https://www.forrester.com/report/business-technologist-bridging-it-business-gap
Artículos destacados
Explora nuestros últimos artículos y tendencias.
¿No sabes por dónde empezar?
Cuéntanos tu reto y te ayudaremos a identificar la solución más efectiva para tu empresa.Ya sea automatizar un proceso, crear una plataforma o formar a tu equipo, estamos aquí para ayudarte a avanzar sin fricciones.
