Desarrollar o comprar: automatización a medida o software listo para usar

Compra cuando el proceso es estándar, el modelo del proveedor encaja con el tuyo y lo que necesitas sobre todo es un sistema de registro. Desarrolla cuando el proceso es lo que te diferencia, cuando abarca sistemas que ningún proveedor cubre por sí solo, o cuando el trabajo consiste en gestión de documentos y excepciones que exige criterio propio y que las herramientas de flujo de trabajo empaquetadas solo cubren en parte. La mayoría de las grandes organizaciones acaban haciendo ambas cosas: licencian las plataformas base y desarrollan la automatización conectiva que hace que esas plataformas sean utilizables tal y como opera realmente la empresa.

La pregunta que de verdad decide esto no es "qué es más barato". Es quién asume el problema del encaje. Comprar traslada el riesgo de encaje a tu equipo de operaciones, que absorberá la diferencia entre las hipótesis del producto y tu realidad mediante soluciones improvisadas, hojas de cálculo y reintroducción manual de datos. Desarrollar traslada el riesgo de encaje a ingeniería, que debe especificar, construir y seguir manteniendo algo. Ambos suponen costes reales. El error que más vemos es comparar una cuota de licencia con una estimación de desarrollo sin tener en cuenta el coste operativo de las soluciones improvisadas que la licencia exige de forma silenciosa.

La tercera respuesta, que no gusta ni a los proveedores ni a los integradores, es no automatices esto todavía. La damos más a menudo de lo que podrías esperar, y más abajo hay un apartado dedicado a ello.

Cuándo gana un producto empaquetado

Compra cuando se cumple la mayoría de lo siguiente:

• El proceso está regulado, estandarizado o definido externamente. Nóminas, declaración de impuestos, libro mayor, administración de prestaciones. Las reglas vienen de fuera de tu organización y cambian sin que tengas ni voz ni voto. Los proveedores amortizan ese trabajo de cumplimiento entre todos sus clientes; tú no puedes.
• Necesitas un sistema de registro, no un sistema de trabajo. Si lo que se entrega es un estado duradero y auditable —clientes, facturas, tickets, empleados—, cómpralo. Desarrollar un sistema de registro significa asumir tú las migraciones de esquema, las copias de seguridad, la retención y la auditoría durante el resto de su vida útil.
• Tu proceso no tiene una diferencia defendible. Si un consultor pudiera entrar y decirte que tu proceso se parece al de cualquier otro, esa es una señal de compra. Una singularidad que viene de un accidente histórico y no de un diseño deliberado no merece codificarse en software a medida.
• El modelo de datos del producto coincide con tu forma de pensar. Este es, por sí solo, el mejor indicador de una compra exitosa. Si tu equipo tiene que traducir mentalmente cada pantalla a su propio vocabulario, la adopción será pobre por muchas funciones que tenga.
• El volumen es bajo o impredecible. El precio por usuario o por transacción es eficiente a pequeña escala. Se vuelve castigador a gran escala, pero eso es un problema para más adelante, y ese momento puede que nunca llegue.
• Necesitas tenerlo funcionando en semanas. Un producto configurado gana a un desarrollo a medida en tiempo hasta el primer valor casi siempre. Si el caso de negocio depende más de la velocidad que del encaje, compra.

Cuándo gana un desarrollo a medida

• El proceso abarca sistemas que ningún proveedor cubre de principio a fin. El trabajo empieza en una bandeja de entrada, pasa por un ERP, necesita una consulta en una base de datos heredada y termina en una hoja de cálculo que alguien envía por correo. Cada proveedor cubre un tramo. El valor está en toda la cadena, y esa cadena te toca construirla a ti.
• El proceso es lo que te hace competitivo. Lógica de suscripción de riesgos, fijación de precios, admisión clínica, configuración de pedidos complejos, gestión de siniestros. Si las reglas codifican un conocimiento institucional que ha llevado años acumular, un producto lo aplanará hasta convertirlo en algo genérico y perderás la ventaja por la que pagabas.
• El trabajo tiene mucho de documentos y excepciones. Las entradas no estructuradas —contratos, remesas, extractos, correspondencia— llegan en formatos en los que no hay dos contrapartes que coincidan. Aquí es donde el trabajo de inteligencia documental y de datos suele superar a los productos de captura basados en plantillas, porque lo difícil es la ruta de excepción, no el caso habitual.
• El volumen es alto y sigue creciendo. Cuando multiplicas una cuota por transacción por un número grande y creciente, comprar deja de ser la opción barata. La economía de desarrollar mejora con el volumen; la de licenciar empeora.
• Las dos últimas implementaciones han fallado. Si ya has comprado dos veces y el equipo sigue improvisando soluciones alrededor del producto, el problema es de encaje, y un tercer producto no lo va a arreglar.
• El cambio es constante. Si tu proceso cambia varias veces al año, esperar en la cola de la hoja de ruta de un proveedor para cada cambio es insostenible. Ser dueño del código significa poder cambiarlo cuando cambia el negocio.

Los costes ocultos de comprar

Las cuotas de licencia son la parte visible, negociable y menos interesante. Lo que de verdad dispara la factura:

• Proliferación de usuarios. El precio por usuario te empuja a restringir el acceso, lo que empuja el trabajo hacia el correo y las hojas de cálculo para que puedan participar personas sin licencia. Pagas dos veces: una en usuarios, otra en proceso en la sombra.
• Implementación y configuración. A menudo es un múltiplo del coste de licencia del primer año, y con frecuencia lo entrega un partner y no el propio proveedor. Pregunta quién hace el trabajo antes de firmar.
• Integración. Los conectores de la demo cubren el caso habitual. El resto es problema tuyo, y suele ser la mitad más grande.
• Solicitudes de cambio. Una vez en producción, cada cambio de proceso se convierte en un ticket a un proveedor cuyas prioridades marcan sus clientes más grandes. Tienes influencia proporcional a tu gasto, es decir, normalmente ninguna.
• Distorsión del proceso. El coste más caro y menos controlado. Los equipos remodelan su forma de trabajar para encajar con la herramienta, y luego contratan para cubrir las costuras. Esto aparece en la plantilla, no en el presupuesto de software, así que nadie lo atribuye a la compra.
• Dependencia del proveedor (lock-in). Pregunta, antes de firmar: ¿podemos exportar nuestros datos en un formato utilizable, incluyendo historial, adjuntos y pista de auditoría? ¿Cuánto tarda la exportación? ¿Lo garantiza el contrato? Si la respuesta es vaga, incorpora esa vaguedad al precio.
• Ventaja negociadora en la renovación. Una vez que el producto tiene tu historial operativo, tu posición negociadora en la renovación es débil. Las subidas de precio llegan en el peor momento posible.

Los costes ocultos de desarrollar

Nosotros desarrollamos sistemas para vivir, y preferimos que entres con los ojos bien abiertos a que firmes algo de lo que luego te arrepientas.

• La especificación es el verdadero trabajo. La mayor parte del esfuerzo en un desarrollo consiste en descubrir qué hace realmente el proceso, incluidas las partes que nadie documentó y las excepciones que gestiona una sola persona que lleva quince años en la empresa. Si no puedes acceder a esa persona, el desarrollo saldrá mal.
• El mantenimiento no termina nunca. Los sistemas ascendentes cambian, las API quedan obsoletas, los formatos derivan, la normativa se mueve. Presupuesta capacidad continua desde el primer día, no como contingencia.
• Riesgo de persona clave. Los sistemas a medida construidos por una sola persona, sin documentar, se convierten en un pasivo el día que esa persona se marcha. Exige documentación, pruebas y más de una persona que entienda el sistema.
• La seguridad y el cumplimiento son cosa tuya. Control de acceso, cifrado, registro de auditoría, retención, respuesta a incidentes. Con un proveedor todo esto viene incluido, de forma imperfecta, pero incluido. Desarrollar significa asumirlo tú, por eso tratamos la seguridad como parte del desarrollo y no como una revisión al final.
• Ampliación descontrolada del alcance. El "ya que estamos aquí" es como un desarrollo acotado se convierte en una plataforma sin dueño. La disciplina de entregar algo concreto, validarlo y luego ampliarlo es lo que mantiene honestos los costes de desarrollo.
• Coste de oportunidad. La capacidad de ingeniería dedicada a un desarrollo es capacidad que no se dedica a otra cosa. Si tu equipo ya va sobrecargado, ese es un argumento legítimo para comprar, independientemente del encaje.

El híbrido que suele ganar

En la práctica, el patrón más sólido es: compra los sistemas de registro, desarrolla los sistemas de trabajo. Licencia el ERP, el CRM, la plataforma de tickets, el sistema de RR. HH. Luego desarrolla la capa que mueve el trabajo entre ellos, aplica tus reglas, gestiona las excepciones y le da a tu equipo un único lugar desde el que actuar. Esa capa es donde la automatización inteligente de procesos demuestra su valor, y está pensada para ser deliberadamente fina: contiene lógica y orquestación, no registros duraderos.

Esto mantiene el alcance del desarrollo pequeño y reemplazable. Si más adelante cambias de proveedor, reescribes un adaptador, no un negocio entero. También evita el peor desenlace que vemos: una personalización pesada dentro de una plataforma comprada, que combina el coste de desarrollar con la dependencia de comprar y te impide actualizar.

Cuando la respuesta es "no automatices esto todavía"

Algunos procesos deben dejarse como están, y decirlo pronto ahorra mucho dinero.

• El proceso está a punto de cambiar. Una reorganización, una migración de sistemas, una adquisición o un cambio normativo pendientes significan que estarías automatizando algo con poca vida útil por delante. Espera.
• Nadie se pone de acuerdo sobre cuál es el proceso. Si tres personas lo describen de tres formas distintas, la automatización codificará una versión y romperá las otras dos. Estandariza primero, automatiza después.
• El proceso está roto, no es lento. Automatizar un proceso deficiente produce malos resultados más deprisa y hace que sean más difíciles de detectar. Corrige primero el diseño.
• El volumen no lo justifica. Una tarea que hace unas pocas veces al mes alguien que se le da bien puede sencillamente no merecer la ingeniería, el mantenimiento ni el riesgo. Nuestra calculadora de valor es una forma rápida de comprobar si los números cuadran antes de que nadie construya nada.
• El verdadero cuello de botella está más arriba en el proceso. Si un paso posterior es lento porque las entradas llegan tarde o incompletas, automatizar ese paso posterior desplaza la cola sin acortarla.
• Nadie es responsable del resultado. La automatización sin un responsable claro se degrada en silencio. Si no puedes nombrar a la persona cuyas cifras mejoran, no empieces.

Una lista de verificación para decidir

Repasa esto antes de comprometerte con una opción u otra. Las respuestas honestas suelen apuntar claramente en una dirección.

Dos pruebas adicionales. Primero, la prueba de las soluciones improvisadas: durante una prueba piloto, cuenta cuántas soluciones improvisadas inventa tu equipo. Unas pocas son normales. Si inventan una por pantalla, el encaje no existe. Segundo, la prueba de la reversibilidad: supón que esta decisión es errónea y lo descubres dentro de un par de años. ¿Qué opción es más barata de deshacer? Prefiere la reversible cuando las evidencias estén igualadas.

Cómo lo abordamos

Empezamos por el proceso, no por la tecnología: qué dispara el trabajo, quién lo toca, dónde se atasca y cuáles son realmente las excepciones. Eso suele producir una división clara: las partes que un producto gestiona bien, las que hay que desarrollar y las que deberían rediseñarse o retirarse antes de que nadie automatice nada. Te diremos cuándo comprar es la decisión correcta, incluso cuando la decisión correcta sea un producto que nosotros no implementamos.

Puedes leer más sobre cómo trabajamos, ver el catálogo de nuestros servicios de automatización o consultar casos de éxito sobre cómo se han tomado estas decisiones en la práctica. Si el trabajo es de cara al cliente, operaciones de atención al cliente con IA cubre las decisiones de desarrollar frente a comprar específicas de las cargas de trabajo de contacto y servicio, donde las herramientas empaquetadas son fuertes en canales y débiles en tu lógica de resolución.

Si estás valorando una decisión concreta y quieres una segunda opinión de ingenieros que no tienen ninguna licencia que venderte, habla con nosotros. Una breve conversación de alcance sobre un proceso suele bastar para saber hacia dónde apunta.

Preguntas que nos hacen sobre esto