Construir, configurar o comprar: cómo decide un comité con criterios claros

Hay una escena que se repite en muchos comités. Alguien presenta una necesidad: un proceso que hoy vive en hojas de cálculo, un portal que los clientes piden, una aprobación que se pierde en el correo. Tres personas en la mesa traen, cada una, una respuesta ya formada. Tecnología dice que lo construyan, porque «así queda exactamente como lo necesitamos». Finanzas dice que compren un producto, porque «es más barato y ya existe». Operaciones dice que se configure lo que ya se tiene, porque «para qué gastar más».

Las tres respuestas pueden ser correctas. Ninguna lo es por defecto. El error más caro de esta decisión rara vez es elegir el camino equivocado entre tres razonables: es elegir sin haber puesto sobre la mesa los criterios que distinguen un camino de otro, y firmar un contrato sin saber qué se está comprando de verdad.

Este artículo es para quien responde por esa decisión: dirección general, finanzas y tecnología en una empresa mediana o grande. No es una guía técnica ni una comparación de marcas. Propone seis criterios para decidir, una tabla para llevar al comité, las preguntas que conviene hacer antes de firmar un desarrollo a la medida y una explicación honesta de por qué tantos sistemas hechos a la medida terminan en rescate.

Los tres caminos, en palabras del comité

Antes de comparar, conviene que todos hablen de lo mismo.

Configurar lo que ya tiene. Su ERP, su CRM, su plataforma de flujos o su core ya traen capacidades que quizá no se usan, o se usan a medias. Configurar es ajustar parámetros, reglas, formularios y reportes dentro de lo que el fabricante soporta. No se escribe código nuevo, o se escribe muy poco, y el sistema sigue siendo el del fabricante.

Comprar un producto. Se adquiere una solución ya construida para un problema que muchas empresas comparten: facturación, nómina, administración de pólizas, conciliación. Se paga una licencia o una suscripción, se adapta a la operación mediante configuración y se acepta que algunas cosas se harán a la manera del producto. Aquí «comprar» incluye tanto el paquete tradicional como el servicio en la nube.

Construir a la medida. Se desarrolla un sistema para el proceso particular de la empresa. Hay código propio, decisiones propias y, si el contrato está bien hecho, titularidad propia. También hay responsabilidad propia sobre lo que se construyó: alguien tiene que mantenerlo, probarlo y cambiarlo.

Existe un cuarto camino, que conviene mencionar para que no se cuele sin nombre: combinar. Muchas veces la respuesta correcta es un producto para la parte que se parece a la de otras empresas y una pieza a la medida para la parte que distingue a la suya. Los tres caminos no son excluyentes; lo que cambia es dónde se traza la línea.

Seis criterios para decidir

1. Cuánto diferencia su proceso

Esta es la pregunta de fondo. Si la manera en que su empresa hace algo es parte de por qué los clientes la eligen o de por qué sus márgenes son distintos, ese proceso merece atención propia. Si es un proceso que cualquier empresa del ramo hace igual (cerrar la contabilidad, emitir un comprobante fiscal, pagar una nómina), construirlo rara vez construye ventaja.

Una prueba útil para el comité: ¿un competidor podría comprar mañana el mismo producto y operar igual que nosotros? Si la respuesta es sí, probablemente no vale la pena construirlo. Si la respuesta es no, y además esa diferencia es justo lo que se quiere proteger o escalar, entonces construir, o al menos construir la parte que diferencia, merece estar en la mesa.

La prueba tiene un reverso que se olvida: no todo lo que la empresa cree que la distingue la distingue de verdad. Con frecuencia lo «único» es una costumbre acumulada durante años, no una ventaja. Antes de pagar por reproducir una costumbre, conviene preguntarse si el cliente notaría su ausencia.

2. Cuánta urgencia hay y qué cuesta esperar

Un producto que ya existe se puede poner a operar en menos tiempo que uno que apenas se va a diseñar, pero «menos tiempo» no es «poco tiempo»: hay que configurarlo, migrar datos, capacitar y conectarlo. Una configuración dentro de lo que ya se tiene suele ser la más rápida de las tres. Un desarrollo a la medida es, en general, el que más tarda en dar el primer resultado, salvo que se entregue por partes y la primera parte sea útil por sí sola.

La urgencia debe expresarse en dinero o en riesgo, no en ansiedad: qué ingreso se pospone, qué sanción se acerca, qué cliente se pierde por cada mes de espera. Con esa cifra el comité puede comparar el costo de esperar contra el costo de cada camino. Sin ella, la urgencia suele terminar decidiendo por el camino que se ve más rápido en la presentación, que no siempre es el que más rápido llega.

3. Qué tanta integración exige

Aquí se equivocan muchos comités, porque miran la pantalla y no las conexiones. Un sistema nuevo casi nunca opera solo: lee y escribe en su ERP, recibe datos de sus canales, entrega información a contabilidad, responde a una autoridad. El trabajo de integración suele ser la parte menos visible del proyecto y la que más sorprende.

Cada camino lo afronta de manera distinta. Un producto trae conectores para los sistemas más comunes, y la pregunta es si los suyos están entre ellos y a qué costo. Configurar dentro de lo que ya se tiene reduce el número de conexiones nuevas, porque el sistema ya está conectado. Construir a la medida da libertad para conectar lo que se necesite, pero cada conexión es trabajo que se paga, se prueba y se mantiene; y el fabricante del sistema al que se conecta puede cambiar sus reglas.

Una pregunta concreta para llevar a cualquier proveedor, sea de producto o de desarrollo: ¿con qué sistemas nuestros se conecta, por qué interfaz soportada por su fabricante y quién responde cuando una de las dos partes cambia?

4. Quién lo va a mantener

Un sistema no termina el día que se entrega. A partir de ahí hay que corregir fallas, adaptarse a cambios de regulación, actualizar componentes que dejan de recibir soporte y atender las peticiones del negocio. Esta es la parte del costo que menos aparece en las propuestas, y la que más pesa al cabo de unos años.

En un producto, el mantenimiento de la base lo hace el fabricante, y usted paga por ello. En una configuración, lo hace el fabricante de la plataforma, más quien haya hecho los ajustes. En un desarrollo a la medida, lo hace quien usted decida, y ahí está la pregunta de fondo: ¿esa persona o equipo existe, tiene la documentación necesaria y puede sostenerse en el tiempo? Un sistema que depende del recuerdo de quien lo programó es un riesgo disfrazado de activo.

5. Costo total, no precio de entrada

La comparación más frecuente en un comité es entre el precio del producto y el presupuesto del desarrollo. Es una comparación incompleta. Para decidir, el costo debe verse a varios años y con todos sus renglones:

• Adquisición: licencias o suscripción en un producto; horas o precio del proyecto en un desarrollo.
• Implementación: configuración, migración de datos, integración, pruebas y capacitación. En un producto, conviene pedir por separado y por escrito licencias, configuración, migración, integración, pruebas y capacitación.
• Operación: infraestructura, soporte, monitoreo y las personas que se dedican a atenderlo.
• Cambio: lo que cuesta adaptar el sistema cuando el negocio cambia. En un producto, suele depender del fabricante y su calendario; en uno a la medida, depende de su capacidad de mantenimiento.
• Salida: lo que costaría dejar el sistema y llevarse los datos y las reglas a otro lado.

Ninguno de los tres caminos gana siempre en este análisis. Un producto puede salir más barato en cinco años y más caro en diez si el negocio se aleja de lo que el producto asume. Un desarrollo puede salir más caro al inicio y más barato si lo que se construyó evita pagar licencias por usuario que crecen con la empresa. Lo importante es que la cuenta exista, que sea del comité y no de quien vende, y que se haga con los renglones de arriba.

6. La salida del proveedor

Es el criterio que casi nadie pone en la hoja el día de la decisión y que más se lamenta después. Cada camino crea una dependencia distinta, y conviene nombrarla.

Con un producto, la dependencia es del fabricante: de su precio, su calendario de versiones y su permanencia. La pregunta es qué pasa con sus datos y sus reglas si mañana quiere cambiar de producto: ¿se pueden exportar, en qué formato, con qué documentación?

Con una configuración, la dependencia es doble: del fabricante de la plataforma y de quien hizo los ajustes. Las reglas de negocio quedan dentro de la herramienta; si no están documentadas fuera de ella, se vuelven difíciles de reproducir.

Con un desarrollo a la medida, la dependencia es de quien lo construyó, y se reduce o se agrava según lo que el contrato diga. Código en su repositorio, documentación, pruebas, accesos y un traspaso verificable reducen la dependencia y hacen viable evaluar el paso a otro equipo. Sin ellos, el proveedor original tiende a volverse imprescindible. La siguiente sección se ocupa de eso.

La tabla para llevar al comité

La tabla siguiente resume cómo se comporta cada camino frente a los seis criterios. Es una guía de razonamiento, no una medición: los valores describen tendencias, y su caso concreto puede apartarse de ellas.

Dos observaciones sobre cómo usarla. Primera: no cuente cuántas celdas «le favorecen» a cada columna; los criterios no pesan igual para todas las empresas. Un comité con una urgencia regulatoria puede dar al segundo criterio un peso que otro comité no daría. Segunda: la tabla sirve sobre todo para descubrir desacuerdos. Si dos miembros del comité califican distinto una celda, ahí está la conversación que vale la pena tener antes de contratar a nadie.

Escenario (ilustrativo, sin cliente). Una distribuidora mediana con operación en varios estados quiere reemplazar el proceso con el que sus ejecutivos de cuenta autorizan descuentos especiales, que hoy se resuelve por correo y una hoja compartida. El comité califica sus seis criterios. El proceso de autorización tiene reglas propias que varían por cliente y por producto, y el negocio las considera parte de su manera de vender: diferenciación alta. La urgencia es moderada: hay pérdidas, pero ninguna fecha límite. La integración exige leer precios y existencias del ERP y escribir la aprobación de vuelta: dos conexiones. El mantenimiento sería responsabilidad de un equipo interno pequeño. Al sumar costos a cinco años, un producto de flujos de aprobación general sale más barato en licencias, pero obligaría a programar justo las reglas que diferencian a la empresa, dentro de una herramienta ajena. Un desarrollo completo sale más caro, pero concentra el esfuerzo en esas reglas. El comité decide combinar: un producto de flujos para el recorrido de la solicitud y una pieza a la medida para el cálculo de qué descuento se puede autorizar, con el código y la documentación de esa pieza a nombre de la empresa. Las cifras del escenario se omiten a propósito: lo que importa es el orden de las preguntas, no los números.

Qué preguntar antes de firmar un desarrollo a la medida

Si el comité llega a la conclusión de que conviene construir, o construir una parte, el contrato pasa a ser el instrumento que determina si usted termina con un activo o con una dependencia. Cuatro bloques de preguntas ordenan esa revisión. Todas deben tener respuesta por escrito antes de firmar.

De quién es el código

La pregunta parece obvia y es la que más malentendidos genera. Quien paga por un sistema suele dar por hecho que es suyo. La Ley Federal del Derecho de Autor establece reglas específicas y conviene conocerlas. Lo que sigue es una lectura de su texto vigente en el sitio de la Cámara de Diputados; no sustituye la opinión de su área jurídica.

• Los programas de computación se protegen en los mismos términos que las obras literarias, tanto en código fuente como en código objeto (art. 102).
• Toda transmisión de derechos patrimoniales es onerosa y temporal, y los contratos por los que se transmiten, así como las licencias de uso, deben celebrarse por escrito; de lo contrario, la ley los declara nulos de pleno derecho (art. 30).
• El artículo 33 prevé un plazo de cinco años cuando la transmisión no lo fija; para los programas de computación, el artículo 103 exceptúa expresamente esa limitación. La redacción de la cesión y su alcance deben revisarse con su área jurídica.
• En una obra por encargo, el artículo 83 establece, salvo pacto en contrario, una regla a favor de quien la comisiona. Para que una obra se considere realizada por encargo, el artículo 83 bis exige que los términos del contrato sean claros y precisos, y ante la duda prevalece la interpretación más favorable al autor.
• Los derechos patrimoniales sobre un programa creado por empleados en ejercicio de sus funciones corresponden, salvo pacto en contrario, al empleador (art. 103, primer párrafo). Si quienes desarrollan el programa son empleados de su proveedor y actúan en sus funciones, esos derechos nacen en su proveedor; si intervienen subcontratistas o prestadores independientes, conviene verificar por escrito la cadena de titularidad. Lo que llega a usted llega por lo que el contrato diga.

La conclusión práctica no es que la ley le quite el código; es que la titularidad conviene dejarla por escrito, con palabras explícitas. Preguntas para el contrato:

1. ¿Quién es el titular de los derechos patrimoniales sobre el sistema entregado y su documentación, y está escrito?
2. ¿La transmisión es cesión de derechos o licencia de uso, exclusiva o no exclusiva? Son cosas distintas, con consecuencias distintas.
3. ¿Qué pasa con las herramientas, bibliotecas y componentes propios del proveedor que se reutilizan en su proyecto? Es frecuente que el proveedor conserve los suyos y le otorgue una licencia de uso; entonces conviene saber si esa licencia es perpetua, si es transferible y si permite que otro equipo mantenga el sistema.
4. ¿Hay plazo, territorio y condiciones de la transmisión, y quedan inscritos donde la ley lo prevé para surtir efectos frente a terceros (art. 32)? Esta es una consulta para su abogado, no una afirmación general.

Licencias de terceros

Casi ningún sistema moderno se escribe desde cero: se arma con componentes de código abierto, bibliotecas comerciales, servicios en la nube y herramientas de desarrollo. Cada uno tiene su propia licencia, y cada componente puede imponer condiciones distintas. El contrato debe identificar cuáles aplican a cada componente y al uso concreto que usted hará del sistema.

Preguntas para el contrato:

1. ¿Existe una lista de todos los componentes de terceros, con su licencia y su versión? Pídala como entregable.
2. ¿Alguna licencia limita cómo usted puede operar, modificar o distribuir el sistema?
3. ¿Qué componentes tienen un costo recurrente (suscripciones, servicios en la nube, claves) y a nombre de quién están contratados? Si están a nombre del proveedor, el día que termine la relación el sistema puede dejar de funcionar.
4. ¿Quién responde si un componente deja de recibir soporte o aparece una falla de seguridad en él?

Criterios de aceptación

«Entregar el sistema» no es una fecha, es una condición. Si la condición no está escrita, la entrega se negocia al final, cuando el presupuesto está gastado y la presión es máxima, y la parte que más pierde es la que menos margen tiene para esperar.

Preguntas para el contrato:

1. ¿Qué debe poder hacer el sistema para aceptarse, expresado en situaciones que usted pueda observar y repetir? «Que funcione bien» no es un criterio; «que una solicitud con estas características se apruebe en este recorrido y quede registrada con quién, cuándo y por qué» sí lo es.
2. ¿Quién ejecuta las pruebas de aceptación, en qué ambiente y con qué datos? Conviene que participe alguien que no construyó el sistema.
3. ¿Qué ocurre con los defectos encontrados después de aceptar, y por cuánto tiempo los corrige el proveedor sin costo?
4. ¿Se entregan pruebas automáticas junto con el código? Son las que permiten cambiar el sistema después sin apostar.
5. ¿Los pagos están ligados a partes entregadas y aceptadas, y no solo al paso del tiempo?

Traspaso

El día de la entrega es cuando el conocimiento del sistema está concentrado en quien lo hizo. El traspaso es el proceso por el que ese conocimiento pasa a quien lo va a operar.

Preguntas para el contrato:

1. ¿Qué se entrega además del programa: código fuente en su repositorio, documentación de cómo está armado y cómo se instala, instrucciones de operación y de recuperación ante fallas?
2. ¿Quién recibirá el traspaso de su lado, está identificado y tiene tiempo para ello? Un traspaso a «el equipo de TI» sin nombres suele quedar en una presentación.
3. ¿Se puede reconstruir el sistema desde cero a partir de lo entregado, y alguien ajeno al proveedor lo comprobó? Esta es una de las pruebas más reveladoras que existen sobre si hubo un verdadero traspaso.
4. ¿Qué soporte hay durante un periodo posterior y bajo qué condiciones, y qué pasa si usted prefiere que lo mantenga otro equipo?

Las respuestas claras permiten detectar los temas que el contrato debe resolver; la suficiencia de sus cláusulas debe validarla su área jurídica antes de firmar. Si alguna respuesta se vuelve vaga, esa vaguedad es un dato y conviene tratarlo como tal.

Por qué tantos sistemas a la medida terminan en rescate

«Rescate» es la palabra que se usa cuando una empresa tiene un sistema que opera, que nadie quiere tocar y que ya no puede evolucionar al ritmo del negocio. No siempre empezó mal. Las causas se acumulan, y varias son visibles desde la firma.

Primera causa: el tamaño y la duración suben el riesgo más rápido de lo que se supone. Hay evidencia empírica sobre esto. Bent Flyvbjerg y Alexander Budzier analizaron 1,471 proyectos de TI y encontraron que el sobrecosto medio fue de alrededor de 27 %; pero ese promedio esconde una cola: cerca de uno de cada seis proyectos tuvo un sobrecosto promedio de 200 % y un retraso de casi 70 % [1]. Un estudio posterior, con una muestra de 5,392 proyectos de TI, encontró que los sobrecostos siguen una distribución de ley de potencias: muchos proyectos con desviaciones pequeñas y una cola de proyectos con desviaciones extremas, de modo que los proyectos de TI son «mucho más riesgosos en costo de lo que normalmente suponen quienes deciden» [2]. Los autores proponen como posible explicación la interdependencia entre componentes: un problema en uno puede desencadenar reacciones en otros [2].

Qué significa para un comité: la pregunta correcta no es «cuánto se desviará en promedio», sino «qué pasa si caemos en la cola». Un presupuesto que solo resiste el caso promedio no es un presupuesto prudente. Estas cifras son de alta confianza en cuanto a su origen (revisadas en la fuente), pero describen muestras de proyectos de TI en general, no únicamente desarrollos a la medida; no deben leerse como la probabilidad de que su proyecto falle.

Segunda causa: el fracaso se mide mal y se cita peor. Es común ver en presentaciones de venta porcentajes de fracaso de proyectos de software atribuidos al informe CHAOS del Standish Group. Conviene saber que esas cifras se han cuestionado con método. Eveleens y Verhoef, en IEEE Software (2010), sostienen que las definiciones de éxito de Standish se basan únicamente en la exactitud de la estimación de costo, tiempo y funcionalidad; que esa medida es unilateral e infla los porcentajes de proyectos «fallidos»; y que promediar cifras producidas por procesos de estimación distintos, cada uno con un sesgo desconocido, vuelve los resultados carentes de significado. Al aplicar esas definiciones a sus propios datos (5,457 pronósticos de 1,211 proyectos reales), concluyeron que las cifras de Standish no reflejaban la realidad de los casos estudiados [3]. Por eso este artículo no cita porcentajes de CHAOS como dato. Si alguien se los presenta en una propuesta, pregunte por la fuente y por la definición de fracaso que usa. La salvedad aplica en las dos direcciones: tampoco hay base para afirmar que todos los proyectos salen bien.

Lo que sí queda en pie, con las dos fuentes anteriores, es una conclusión prudente: el riesgo existe, es asimétrico y se subestima si se juzga por el caso típico.

Tercera causa: se compra una pantalla y no un activo. Muchos sistemas a la medida se contratan por lo que se ve: las pantallas, el flujo. Lo que no se ve (las pruebas, la documentación, el repositorio, la lista de componentes de terceros) es lo que decide si el sistema puede evolucionar. Cuando esos entregables no se pidieron, el sistema funciona el día de la entrega y se vuelve inmanejable en el primer cambio importante. Esta es la causa más evitable de todas, y las cuatro series de preguntas de la sección anterior existen para eso.

Cuarta causa: el sistema depende de una persona. Un programador que conoce todo el sistema es una fortaleza mientras esté, y un riesgo cuando se va. Es la razón por la que la documentación y el traspaso deben pesar en el contrato tanto como las funciones.

Quinta causa: se construyó lo que ya existía. Con frecuencia, una parte del sistema reproduce capacidades que un producto ofrecería a menor costo de mantenimiento. Cuando esa parte requiere cambios constantes por regulación o por estándares, la empresa termina sosteniendo, con su propio presupuesto, lo que un fabricante sostiene para miles de clientes. El criterio de diferenciación de la primera sección existe para evitar esto.

Sexta causa: no hay un criterio de salida. Ningún sistema es para siempre. Si el contrato no previó cómo se extraen los datos y las reglas, reemplazarlo es otro proyecto de alto riesgo. Un sistema que no puede abandonarse termina conservándose por inercia, lo que lo convierte en una versión lenta de un rescate.

Ninguna de estas causas es inevitable ni exclusiva de los desarrollos a la medida: los productos tienen sus propias versiones (adaptar el negocio al producto sin darse cuenta, por ejemplo). La diferencia es que en un desarrollo a la medida varias de estas causas pueden reducirse con decisiones que se toman antes de firmar y con seguimiento durante la ejecución, que es el motivo de este artículo.

Cómo llevarlo al comité: una hoja, cinco preguntas

Para que esta conversación no se quede en general, proponemos una hoja de una página que cualquier comité puede armar en una tarde:

1. ¿Qué proceso es, y cuánto lo distingue? Con la prueba del competidor que podría comprar el mismo producto.
2. ¿Qué cuesta esperar? En dinero o en riesgo, por mes.
3. ¿Con qué sistemas se conecta y por qué interfaz? Una lista, no una frase.
4. ¿Quién lo mantendrá dentro de tres años? Con nombre o con perfil, y con su documentación.
5. ¿Cómo salimos? Qué se lleva usted, en qué formato y a nombre de quién queda.

Si el comité no puede responder alguna de las cinco, ese hueco es el primer entregable, antes que cualquier propuesta. Y si varias respuestas son «no sabemos», probablemente no falta un proveedor: falta información para decidir.

Qué hace Hábil

Hábil ayuda a organizaciones a ordenar esta decisión antes de comprometerse con un camino: qué conviene configurar, qué conviene resolver con un producto y qué sí vale la pena construir. Esa es la idea de la página Desarrollo a la medida, donde se explica cómo se acuerda el alcance, qué se entrega y a nombre de quién queda.

Si una parte de lo que usted necesita se parece a lo que hacen otras empresas, revise el alcance, las condiciones y las integraciones aplicables de nuestros productos: Retícula, Pauta y Cuadre. Lo que uno de ellos cubre se configura en lugar de programarse, y un proyecto a la medida puede concentrarse en lo que sí es solo suyo.

Si su comité ya identificó el proceso, las integraciones y los criterios de salida, puede contrastar su caso con Hábil en una primera conversación, sin costo. Escríbanos por WhatsApp para pedirla.