Una compañía hace buenos negocios con sus proveedores cuando los contratos están bien diseñados. Los contratos están bien diseñados cuando su estructura de incentivos alinea el comportamiento del proveedor con los objetivos del negocio definidos por el mandante.
Jean-Jacques Laffont y Jean Tirole, este último Premio Nobel de Economía 2014, dedicaron más de una década de trabajo teórico a formalizar por qué ese diseño no puede dejarse en manos del proveedor ni resolverse sin análisis técnico riguroso del mandante. Aunque su análisis se desarrolló sobre el escenario de la regulación pública y la contratación gubernamental, los elementos estructurales que aborda son replicables en cualquier relación contractual entre un comprador y un proveedor.
Procurement existe para ejercer esa responsabilidad. Cuando la ejerce, la empresa mandante determina cómo se reparte el valor económico del contrato. Cuando no la ejerce con plenitud, ese valor se transfiere por defecto hacia la otra parte de la mesa (el proveedor).
La afirmación parece obvia, pero en muchas organizaciones esta responsabilidad no está claramente asignada a Procurement, o estando asignada, Procurement no toma el control de ella.
Vale la pena desarmar la cadena lógica paso a paso.
—
Hacer Buenos Negocios con Proveedores Requiere Hacer Buenos Contratos
Cuando una compañía establece una relación económica con un proveedor, esa relación se materializa en un contrato. Puede ser un documento de muchas páginas, una orden de compra o un pedido spot con unos pocos términos. La forma varía, pero la función es la misma.
El contrato es el instrumento donde queda escrito qué se va a intercambiar, en qué condiciones y con qué consecuencias.
La calidad del negocio queda determinada por la calidad del contrato. Un buen contrato no garantiza un buen resultado, porque su materialización se juega en la ejecución. Pero un mal contrato produce casi siempre un mal resultado.
Esto tiene una implicación directa. Si Procurement existe para que la compañía haga buenos negocios con sus proveedores, Procurement existe también para que los contratos sean buenos. No para redactarlos, que es función legal. Para que funcionen como vehículo del negocio que está detrás.
—
Hacer Buenos Contratos Requiere Diseñar Buenos Modelos de Negocio del Contrato
Por modelo de negocio del contrato me refiero a la arquitectura económica y de control bajo la cual se estructurará la relación con el proveedor: qué se compra realmente, cómo se paga, cómo se mide el desempeño, qué se incentiva, qué se penaliza y cómo se distribuyen los riesgos entre las partes.
Ese diseño no es un detalle administrativo. Define el tipo de comportamiento que el contrato va a inducir durante su ejecución. Determina cuánto riesgo asume cada parte, qué señales recibe el proveedor, qué tan observable será el desempeño real y, en último término, cómo se distribuirán los beneficios económicos del contrato entre las partes.
Operativamente, el modelo de negocio del contrato se articula en cinco componentes que funcionan como un sistema.
El primero son las partidas. El objeto del contrato define el propósito del contrato, es decir, qué se contrata. Las partidas son el medio que permite especificar ese objeto, descomponiéndolo en los servicios concretos que lo conforman. Al definir los servicios, las partidas establecen también qué se contrata y, por tanto, a qué hay que ponerle precio.
La definición de partidas no es un acto descriptivo. Es un acto de diseño. Una misma necesidad puede descomponerse en partidas muy distintas según qué se quiera incentivar y qué se quiera controlar.
El segundo son los objetivos, metas y KPIs. Si las partidas definen qué se contrata, los objetivos, metas y KPIs definen qué resultado se espera de eso.
Los tres elementos operan juntos. Los objetivos declaran la intención. Las metas la cuantifican. Los KPIs la hacen verificable.
Un contrato con KPIs sin metas mide actividad sin contrastarla con el resultado esperado. Un contrato con objetivos sin KPIs declara intenciones sin forma de verificar si se cumplen. Los tres niveles deben estar presentes y articulados entre sí.
El tercero es la asignación de riesgos. Qué parte asume qué contingencias durante la ejecución del contrato. La asignación de riesgos es una decisión previa al diseño económico porque determina las reglas del juego.
Quién asume el riesgo de variaciones en los costos de insumos, quién asume el riesgo de cambios en el volumen demandado, quién asume el riesgo de factores externos como condiciones climáticas o normativas, quién asume el riesgo de desempeño por debajo del esperado. Cada una de esas decisiones condiciona todo el resto del diseño.
El cuarto es el modelo de pago. Qué se paga, por qué unidad, con qué periodicidad, contra qué verificación. El modelo de pago traduce la asignación de riesgos en flujos reales.
Una asignación de riesgo al proveedor se materializa típicamente en esquemas cercanos al precio fijo. Una asignación al mandante se materializa en esquemas cercanos al cost-plus. Entre ambos extremos existe todo un espectro de formas intermedias que comparten el riesgo entre las partes.
El quinto son los incentivos y las penalidades, que operan como los dos mecanismos con los que la asignación de riesgos y el modelo de pago se vuelven exigibles durante la ejecución.
Los incentivos premian el esfuerzo del proveedor en el terreno de riesgo que le corresponde. Un contrato sin incentivos comunica al proveedor que cumplir lo mínimo y cumplir con excelencia producen la misma retribución. El proveedor racional, que opera con criterio puramente económico, tenderá a cumplir lo mínimo.
Las penalidades, por su parte, hacen exigible la asignación cuando el proveedor falla en lo que le tocaba asumir. Un contrato con penalidades que nunca se aplican termina siendo equivalente a un contrato sin penalidades. Un contrato con penalidades desproporcionadas termina siendo un contrato que nadie quiere firmar o que el proveedor compensa inflando el precio.
Los cinco componentes funcionan como un sistema. Partidas sin objetivos, metas y KPIs son volumen sin resultado esperado. Objetivos, metas y KPIs sin asignación de riesgos son compromisos sin reglas sobre quién asume qué. Asignación de riesgos sin modelo de pago coherente es una intención sin materialización. Modelo de pago sin incentivos ni penalidades es flujo de caja sin gobernanza.
Diseñar un contrato es articular los cinco componentes de manera coherente con el objetivo del negocio que está detrás.
No existe un formato universalmente óptimo. La elección entre suma alzada o precios unitarios, entre precio fijo o cost-plus, entre contratar por recursos o por resultado, no es una preferencia personal ni una costumbre organizacional.
Es una decisión técnica que depende de la naturaleza del servicio, del grado de incertidumbre, de la información disponible sobre costos y desempeño, y de qué parte del resultado depende realmente del esfuerzo del proveedor y qué parte depende de factores externos o del propio mandante.
—
Cuando Procurement no Diseña el Modelo de Negocio del Contrato, Alguien lo Hace en su Lugar
En muchas organizaciones, el diseño del modelo de negocio del contrato no está formalmente asignado a Procurement. Procurement participa en la licitación, en la negociación de precios, en la selección del proveedor, en la formalización del contrato. Pero el diseño de fondo lo hace otro.
Dos manifestaciones concretas de este fenómeno aparecen con frecuencia.
La primera es la contratación de recursos en lugar de servicios. La necesidad operativa se traduce en un requerimiento de personas con tal perfil, equipos con tales características, horas-hombre disponibles durante tal período. Pocas veces se define qué servicio se espera, qué resultado se busca, qué métricas se usarán para verificarlo.
Las razones se entrelazan. Especificar recursos es siempre más fácil que especificar un servicio porque los recursos son tangibles: se observan, se cuentan, se miden y se costean directamente. Los servicios definidos como resultado son por esencia intangibles: hay que construir una representación medible de algo que en su naturaleza no es directamente observable.
Eso requiere recursos y competencias que no siempre están disponibles, y disposición a comprometerse con un resultado específico que después habrá que defender.
Lo que sigue es previsible. Durante la ejecución, el cliente interno termina administrando los recursos del contratista. Decide qué hace cada persona, a qué horas, con qué prioridades. El contratista se libera de la obligación de entregar un resultado (output), porque su responsabilidad contractual queda reducida a proveer los recursos comprometidos en el contrato.
Cuando el resultado no satisface, el cliente interno atribuye el problema al contratista, cuando en realidad el problema fue el diseño del contrato. Y se queja del esfuerzo de supervisión, sin advertir que ese esfuerzo es el costo directo de no haber diseñado el modelo de negocio correcto desde el inicio.
La segunda manifestación aparece cuando el cliente interno termina apropiándose del diseño completo del modelo de negocio del contrato. Define cómo se cotizará, si con suma alzada o precios unitarios, cuál será la unidad de medida, qué KPIs se usarán, qué multas aplicarán, qué incentivos existirán. Procurement queda reducido a ejecutar el proceso de licitación y formalizar el contrato resultante.
Aquí conviene hacer una precisión importante. El cliente interno sí aporta algo indispensable: conocimiento de la necesidad, de la demanda y de la operación. Ese aporte es crítico y no puede ser reemplazado.
Pero conocer la necesidad, la demanda y la operación no equivale, por sí solo, a saber diseñar un contrato.
Diseñar bien un contrato exige comprender cómo la unidad de medida afecta el comportamiento del proveedor, cómo el esquema de pago interactúa con los KPIs, cómo la asignación de riesgos cambia los incentivos, cuánto esfuerzo o eficiencia puede realmente controlar el proveedor y cómo todo eso se articula para producir un resultado coherente con el objetivo del negocio. Esa es una competencia técnica distinta.
Cuando el contrato falla, la responsabilidad se difumina. El cliente interno culpa al proveedor o a Procurement. Procurement responde que el diseño no fue suyo. El proveedor alega, muchas veces con razón, que cumplió exactamente lo que el contrato pedía.
El error no estaba en la ejecución. Estaba en el diseño.
En ambos casos, el patrón es el mismo. El diseño del modelo de negocio del contrato no es una función que desaparece cuando Procurement no la ejerce. Es una función que queda asignada por defecto a quien tenga la necesidad operativa o la capacidad de imponer criterios.
Y casi siempre, el resultado es un contrato que no cumple lo que debería cumplir.
—
La Cadena de Responsabilidad
La cadena lógica es directa. La compañía hace buenos negocios con sus proveedores cuando los contratos funcionan. Los contratos funcionan cuando el modelo de negocio del contrato está bien diseñado. El modelo de negocio del contrato está bien diseñado cuando alguien con competencia técnica asume esa responsabilidad como propia.
Eso no significa que Procurement diseñe solo. Los contratos se diseñan considerando distintos insumos de las partes interesadas: operaciones, HSEC, RRHH, finanzas, legal, entre otras.
Pero sí significa que existe una función cuya responsabilidad metodológica y liderazgo técnico estructuran esa relación de forma coherente antes de salir al mercado.
La competencia técnica incluye entender cómo operan los incentivos, cómo se estructuran los costos, cómo afecta cada componente contractual al comportamiento de las partes, y cómo se articulan entre sí para producir un resultado coherente con el negocio buscado.
No es una competencia que se improvisa ni que se adquiere por la práctica de contratar muchas veces. Es una disciplina que requiere estudio, método y experiencia acumulada.
Laffont y Tirole la formalizaron durante décadas bajo el nombre de diseño de contratos bajo información asimétrica, y sintetizaron ese trabajo en el libro que en 1993 publicaron con el título A Theory of Incentives in Procurement and Regulation.
En una compañía, esa disciplina se ejerce desde una función específica. Se llama Procurement.
Todo lo demás que hace Procurement (el análisis de mercado, la gestión de categorías, la licitación, la negociación, la administración de contratos, la gestión de proveedores) son competencias específicas que se despliegan dentro de esta responsabilidad marco.
—
El diseño del modelo de negocio del contrato es un trabajo técnico que se hace antes de salir al mercado, no durante la negociación ni después de la firma.
Exige definir con claridad las partidas, los KPIs, el modelo de pago, los incentivos y las penalidades, y articularlos como un sistema coherente con el objetivo del negocio.
Ese trabajo define qué relación económica tendrá la compañía con el proveedor durante los próximos meses o años. Todo lo que sucede después, en la negociación, en la adjudicación, en la administración, ejecuta esa relación. La diseña no.
Por eso el diseño del modelo de negocio del contrato no es una etapa más del proceso de compra. Es la etapa que determina qué van a poder hacer todas las siguientes.
