Modelos contractuales en outsourcing: T&M, Fixed Price y Outcome-based
- Por Amparo Silva | Amsoft
Introducción
Cuando una empresa contrata outsourcing de TI, la decisión que más se discute suele ser el proveedor. Se comparan referencias, se revisan casos anteriores y se evalúa la experiencia técnica del equipo. Pero hay otra decisión que impacta el resultado tanto como esa elección. Recibe mucha menos atención: el modelo contractual bajo el que se firma el trabajo.
Tiempo y materiales, precio fijo o pago por resultados no son simples cláusulas administrativas que se definen al final de la negociación. Son la estructura que determina quién asume el riesgo si el proyecto se desvía del plan. También definen cómo se gestiona un cambio de alcance a mitad de camino, y qué incentivos tiene el proveedor durante toda la ejecución. Elegir el modelo equivocado no arruina un proyecto por sí solo. Sí determina cuánta fricción, sobrecosto o rigidez enfrentará el cliente cuando algo no salga exactamente como se planificó.
El outsourcing tecnológico en Chile sigue creciendo, y eso hace la elección del modelo más relevante, no menos. El gasto mundial en TI alcanzará los USD 6,15 billones en 2026, un 10,8% más que en 2025, según G5 Noticias. El mercado cloud chileno proyecta una expansión superior al 20% anual hacia 2028. La escasez de talento especializado empuja a más empresas a externalizar capacidad: se esperan más de 63.000 vacantes críticas en ciberseguridad hacia 2026.
A nivel global la tendencia también se mueve. El ISG Index de enero de 2026 señala que el mercado de servicios gestionados se concentra en contratos más grandes y selectivos, con énfasis en compromisos cortos y alcances modulares. También crece el peso de las estructuras basadas en resultados. Este artículo compara los tres modelos más usados en outsourcing de TI: cuándo protegen, cuándo generan riesgo y cómo elegir el correcto.
1. Por qué el modelo contractual impacta el resultado del proyecto tanto como el proveedor elegido
1.1 El error de elegir el modelo por costumbre, no por el proyecto
Muchas empresas eligen el modelo contractual por costumbre más que por análisis. Usan el mismo formato en todos sus proyectos de TI. No importa si se trata de una consultoría exploratoria, un desarrollo con alcance definido o un servicio continuo de soporte. Ese hábito parte de un supuesto equivocado: que el modelo contractual es un detalle de forma. En realidad, distribuye el riesgo de manera distinta entre cliente y proveedor en cada caso.
Un proyecto con alcance incierto, forzado a un contrato de precio fijo, termina generando conflictos apenas aparece el primer cambio de requerimientos. El proveedor interpreta cualquier ajuste como trabajo fuera de contrato. El cliente lo interpreta como parte natural del desarrollo. Un servicio de soporte continuo, forzado a un esquema de tiempo y materiales sin ningún indicador de resultado, puede terminar pagando por horas trabajadas. Eso ocurre sin que se traduzca en mejoras medibles para la operación. El modelo correcto responde al tipo de proyecto, al nivel de certeza sobre el alcance y a la relación que existe con el proveedor, no a la costumbre de la empresa.
1.2 El contexto chileno: por qué este tema cobra más relevancia hoy
La escasez de talento técnico y el crecimiento sostenido del gasto en TI están llevando a más empresas chilenas a externalizar funciones. Antes las mantenían con equipos internos. Áreas de desarrollo, soporte y operación de sistemas que antes se resolvían con contratación directa hoy dependen, en parte o por completo, de un proveedor externo. Cuando el outsourcing crece en volumen, también crece el costo de elegir mal el modelo contractual. Un error de gestión en un proyecto puntual tiene un impacto acotado. El mismo error, replicado en varios contratos simultáneos, multiplica el costo y la fricción interna.
A esto se suma la tendencia identificada por ISG hacia contratos más cortos y orientados a resultados. Esa tendencia no elimina a los modelos tradicionales ni los vuelve obsoletos. Sí obliga a las empresas chilenas a entender mejor sus alternativas antes de firmar. Replicar el mismo contrato que se usó la última vez, sin evaluar si el proyecto actual tiene las mismas características, es exactamente el hábito que este artículo busca cuestionar.
2. Tiempo y materiales (T&M): cuándo da control y cuándo genera riesgo de costo
2.1 Qué es y cuándo conviene
En el modelo de tiempo y materiales, el cliente paga por las horas efectivamente trabajadas y por los recursos consumidos, a una tarifa acordada previamente. No hay un monto total cerrado desde el inicio del proyecto. Este modelo conviene cuando el alcance todavía no está completamente definido. También conviene cuando se espera que los requerimientos evolucionen durante la ejecución, o cuando el cliente necesita flexibilidad real para reorientar el trabajo a medida que aprende más sobre el problema que está resolviendo.
Es el modelo natural para proyectos de exploración, prototipos, consultorías iniciales o desarrollos donde la innovación es parte explícita del objetivo. En esos contextos, fijar un alcance detallado antes de empezar sería contraproducente. Se estaría comprometiendo una solución antes de entender bien el problema. T&M también da al cliente control directo sobre las prioridades día a día. Puede redirigir el esfuerzo del equipo sin necesidad de renegociar un contrato completo cada vez que cambia una prioridad.
2.2 El riesgo real: costo sin techo si no hay gobernanza
El riesgo de T&M está en la ausencia de gobernanza, no en el modelo en sí. Sin un presupuesto de referencia, revisiones periódicas de avance y objetivos claros por sprint o por etapa, el costo total puede crecer sin que nadie lo note. Muchas veces se descubre recién al cierre del período de facturación. En ese escenario, el cliente termina pagando por tiempo consumido, no necesariamente por progreso concreto hacia el objetivo del proyecto.
La forma correcta de mitigar ese riesgo es administrar el modelo con disciplina, no descartarlo. Eso implica definir un techo de gasto orientativo desde el inicio. También implica revisar el avance cada dos semanas con métricas concretas, y exigir que cada ciclo de trabajo entregue algo verificable, aunque el contrato en su conjunto no tenga un monto cerrado. Una práctica habitual entre proveedores serios es fijar checkpoints de reporte quincenal. Ahí se compara el gasto acumulado contra el avance real. Así cualquier desviación se detecta a tiempo, y no al final del proyecto, cuando ya es tarde para corregirla sin sobrecosto adicional.
3. Precio fijo (Fixed Price): cuándo protege y cuándo genera conflictos
3.1 Qué es y cuándo conviene
En el modelo de precio fijo, cliente y proveedor acuerdan un monto total por un alcance definido de antemano. Ese alcance se documenta con el mayor detalle posible antes de iniciar el trabajo. El proveedor asume el riesgo de que el proyecto le tome más tiempo o más recursos de los estimados originalmente. Este modelo conviene cuando el alcance está bien especificado y el proyecto tiene requerimientos estables. También conviene cuando el cliente necesita certeza presupuestaria para aprobar el gasto ante su propia organización.
Es habitual en proyectos con especificaciones técnicas claras, migraciones de sistemas bien delimitadas o desarrollos donde el resultado final se puede describir con precisión antes de empezar a construir. Para un área de finanzas o un directorio que debe aprobar presupuesto con anticipación, la previsibilidad del precio fijo suele ser el argumento decisivo. Se prefiere sobre otros modelos incluso cuando eso implica ceder algo de flexibilidad durante la ejecución.
3.2 El riesgo real: rigidez frente al cambio y conflictos de alcance
El riesgo de precio fijo aparece cuando el alcance inicial no estaba tan claro como parecía en la etapa de negociación. Cualquier cambio, por pequeño que sea, exige una negociación formal de alcance adicional. Eso trae retraso y costo administrativo. Esa rigidez puede convertirse en un punto de fricción constante entre cliente y proveedor. El problema se agrava si el cliente asume que el precio fijo cubre cualquier ajuste razonable, mientras el proveedor interpreta el contrato de forma más literal.
El riesgo inverso también existe y suele quedar menos visible. Un proveedor que subestimó el esfuerzo al momento de cotizar puede compensarlo recortando calidad en las áreas que el contrato no especificó con suficiente detalle. La forma de mitigar ambos riesgos es la misma, aunque exige tiempo antes de firmar. Hay que invertir esfuerzo real en definir el alcance con precisión, incluyendo qué queda explícitamente fuera. Eso evita resolver esas ambigüedades durante la ejecución, cuando ya hay presión de plazo y presupuesto comprometido.
4. Outcome-based: el modelo emergente orientado a resultados de negocio
4.1 Qué es y por qué está ganando terreno
En un contrato basado en resultados, el pago del proveedor está ligado a un indicador de negocio acordado previamente. No depende de las horas trabajadas ni del alcance técnico entregado. Puede ser un tiempo de respuesta objetivo, una tasa de disponibilidad del sistema o un volumen de transacciones procesadas correctamente. También puede ser cualquier métrica que el cliente valore de forma directa y pueda medir con datos propios.
El ISG Index de enero de 2026 documenta que el mercado global de servicios gestionados se está moviendo hacia estructuras de acuerdo más flexibles. Hay énfasis creciente en resultados de alto impacto, por sobre los enfoques tradicionales basados en horas o en alcance técnico detallado. Este modelo alinea el incentivo del proveedor con el objetivo real del cliente de una forma que los otros dos no logran del todo. Si el proveedor no logra el resultado acordado, no cobra el total del contrato, sin importar cuánto tiempo o cuántos recursos haya invertido en el intento.
El ISG Index de enero de 2026 documenta que el mercado global de servicios gestionados se está moviendo hacia estructuras de acuerdo más flexibles. Hay énfasis creciente en resultados de alto impacto, por sobre los enfoques tradicionales basados en horas o en alcance técnico detallado. Este modelo alinea el incentivo del proveedor con el objetivo real del cliente de una forma que los otros dos no logran del todo. Si el proveedor no logra el resultado acordado, no cobra el total del contrato, sin importar cuánto tiempo o cuántos recursos haya invertido en el intento.
4.2 Los requisitos que exige para funcionar bien
Outcome-based exige que el resultado se pueda medir de forma objetiva, con datos verificables por ambas partes, así que no es un modelo que se pueda aplicar a cualquier proyecto sin ajustes. También exige que cliente y proveedor acuerden esa métrica antes de empezar, sin ambigüedad sobre qué cuenta como éxito. Además, requiere que el proveedor tenga control real sobre las variables que determinan ese resultado. De lo contrario, el modelo deja de ser justo para cualquiera de las dos partes.
El indicador puede depender de factores fuera del control del proveedor: decisiones internas del cliente que se demoran, sistemas de terceros que fallan, cambios regulatorios a mitad de proyecto. Cuando eso ocurre, el esquema pierde sentido y se convierte en un origen de disputas. Cuando esas condiciones sí se cumplen, con métricas claras y control efectivo sobre las variables relevantes, outcome-based suele ser el modelo que mejor alinea los intereses de cliente y proveedor. Cuando no se cumplen, se convierte rápidamente en una fuente de conflicto sobre qué contó como resultado logrado y qué no.
5. Cómo elegir el modelo correcto según el tipo de proyecto, equipo y nivel de madurez
5.1 Criterios de decisión
La elección del modelo correcto depende, en la práctica, de tres preguntas concretas. Conviene responderlas antes de negociar el contrato. La primera es qué tan definido está el alcance del proyecto. Mientras menos definido esté, más sentido tiene un esquema de tiempo y materiales que permita ajustar el rumbo sobre la marcha. Mientras más definido y estable esté, más sentido tiene un precio fijo que entregue certeza presupuestaria.
La segunda pregunta es si existe un resultado de negocio medible, y que esté efectivamente bajo control del proveedor. Si existe, outcome-based es una alternativa real. Suele ser la que mejor alinea los incentivos de ambas partes. La tercera es qué tan madura es la relación entre cliente y proveedor. Los contratos basados en resultados funcionan mejor cuando ya existe historial de trabajo conjunto y confianza construida a lo largo de proyectos anteriores. Ninguna de estas tres preguntas tiene una respuesta universal válida para toda la organización. Dos proyectos del mismo cliente, en la misma industria, pueden requerir modelos distintos si su nivel de definición o de madurez con el proveedor es distinto.
5.2 Modelos híbridos: cuándo conviene combinar más de uno
En la práctica, muchas relaciones de outsourcing combinan modelos según la etapa del proyecto. Evitan forzar todo el ciclo de vida bajo un único esquema contractual. Es habitual iniciar con tiempo y materiales durante el descubrimiento y la definición de alcance, cuando todavía hay demasiadas incógnitas para comprometer un precio cerrado. Luego se migra a precio fijo una vez que el alcance queda claro y ambas partes tienen certeza sobre qué se va a construir. Finalmente se suman componentes de outcome-based sobre indicadores específicos de la operación en régimen, como disponibilidad del sistema o tiempos de respuesta del soporte.
Este enfoque híbrido suele ser, más que una solución de compromiso débil, la forma más realista de estructurar un contrato. Refleja cómo evoluciona efectivamente un proyecto de tecnología a lo largo del tiempo, en lugar de forzar toda la relación bajo un único modelo definido antes de conocer el proyecto en profundidad. Para el cliente, esto implica aceptar que el contrato puede, y probablemente debería, evolucionar junto con el proyecto. No debería quedar fijo desde el primer día.
Conclusión
El modelo contractual es una decisión de gestión con el mismo peso que la elección del proveedor mismo, no un detalle administrativo que se resuelve después, cuando ya hay presión por avanzar y firmar. Determina quién asume el riesgo, qué incentivos existen durante la ejecución y cómo se gestiona el cambio cuando el proyecto se desvía del plan original. Eso ocurre en la mayoría de los proyectos de cierta duración.
Tiempo y materiales da flexibilidad a cambio de exigir gobernanza activa por parte del cliente. Precio fijo da certeza presupuestaria a cambio de exigir un alcance bien definido antes de firmar. Outcome-based alinea los incentivos de ambas partes a cambio de exigir métricas claras y una relación de confianza previamente construida. Ninguno de los tres modelos es superior en abstracto. Cada uno resuelve bien un tipo de proyecto y genera fricción cuando se aplica al proyecto equivocado.
La tendencia global hacia estructuras más flexibles y orientadas a resultados, documentada por el ISG Index, no vuelve obsoletos al precio fijo o al tiempo y materiales. Muestra que las empresas tienen hoy más alternativas disponibles que hace algunos años. Elegir bien exige entender primero el proyecto y solo después elegir el contrato, no al revés como suele hacerse por costumbre.
Para una empresa chilena que está externalizando más funciones tecnológicas en un contexto de escasez de talento, esa elección importa cada vez más. El costo de un modelo mal elegido no aparece en el momento de firmar el contrato, cuando todo parece resuelto sobre el papel. Aparece meses después, en forma de sobrecosto acumulado, conflicto de alcance sin resolver o un resultado que nunca se logró medir con la claridad prometida al inicio.
¿Cómo puede Amsoft ayudarte en este camino?
En Amsoft trabajamos con distintos modelos contractuales según el contexto real de cada proyecto. No empujamos un formato único porque sea el que nos resulta más cómodo administrar internamente. Evaluamos junto al cliente qué tan definido está el alcance, qué resultados de negocio son efectivamente medibles y qué nivel de flexibilidad necesita el proyecto en cada etapa. Recién ahí proponemos una estructura de contrato específica.
Nuestro compromiso es la transparencia en la propuesta desde el primer momento. Explicamos qué riesgos asume cada parte bajo el modelo elegido de outsourcing, sin dejar esa conversación pendiente para después de la firma, cuando ya es más difícil de tener sin generar desconfianza. Esa conversación temprana suele ahorrar meses de fricción posterior.
¿Tu próximo proyecto de outsourcing todavía no tiene claro qué modelo contractual usar? Contáctanos.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- G5 Noticias. (2026, marzo 29). Chile apuesta al negocio del outsourcing tecnológico: cinco tendencias para 2026. https://g5noticias.cl/2026/03/29/chile-apuesta-al-negocio-del-outsourcing-tecnologico-cinco-tendencias-para-2026/
- Morgan Lewis (Sourcing at Morgan Lewis). (2026, enero 26). Key Takeaways from the ISG Index Q4’25 Technology Industry Update. https://www.morganlewis.com/blogs/sourcingatmorganlewis/2026/01/key-takeaways-from-the-isg-index-q425-technology-industry-update