No todo problema operativo necesita software propio

Cuando algo se traba en una empresa, la primera reacción suele ser la misma: hace falta un sistema. Un software que ordene esto, una herramienta a medida que lo resuelva de una vez.

A veces es cierto. Pero muchas veces ese sistema nuevo termina siendo la respuesta más cara a una pregunta que nadie llegó a hacerse bien: ¿el problema es de software, o es de otra cosa?

Por qué saltamos tan rápido a pedir software

Pedir un sistema da la sensación de estar haciendo algo concreto contra el desorden. Es visible, se puede presupuestar y deja la impresión de avance. El detalle es que esa reacción aparece antes de entender qué falla en realidad. Se da por hecho que una herramienta nueva va a poner orden por su cuenta, cuando en general la tecnología adopta la forma del proceso que encuentra: si el circuito está claro, lo acelera; si está enredado, lo deja igual de enredado pero más rápido.

Tres problemas que parecen iguales y no lo son

Antes de decidir construir, conviene clasificar el problema. Casi siempre cae en una de tres categorías, y cada una pide una respuesta distinta:

Recién cuando descartás las tres aparece el caso en que construir tiene sentido de verdad.

Lo que cuesta construir lo que no hacía falta

Desarrollar software propio rara vez sale como se imagina. Los datos de la industria son duros: según los relevamientos del Standish Group, alrededor de un tercio de los proyectos de software terminan bien. La mitad se entrega tarde, por encima del presupuesto o con menos de lo prometido, y el resto se cancela directamente. Los proyectos chicos funcionan bastante mejor que los grandes, pero el sobrecosto promedio, cuando se desvían, es enorme.

Y el gasto no se termina cuando el sistema se enciende. Buena parte del costo total de un software a lo largo de su vida no está en construirlo, sino en mantenerlo: corregirlo, adaptarlo, actualizarlo. Distintas estimaciones de la industria ubican ese mantenimiento entre el 60% y el 80% del costo total. A eso se suma un clásico: el software que se compra o se construye y después nadie usa. Una porción grande de las licencias que las empresas pagan queda sin uso real, mes a mes.

Construir, en otras palabras, no es un pago único. Es asumir un compromiso que sigue costando todos los meses, tenga o no el uso que justificó hacerlo.

Cuándo sí conviene construir

Nada de esto significa que construir esté mal. Significa que conviene reservarlo para donde rinde. Tiene sentido desarrollar algo propio cuando el proceso es central para tu negocio, es parte de por qué te eligen, y ninguna herramienta del mercado lo resuelve bien. Si eso que querés ordenar es justo lo que te diferencia, un producto genérico te empuja a trabajar como todos, y ahí lo propio se paga solo.

Para todo lo demás, que suele ser la mayoría, la decisión es la misma que conviene mirar antes de cualquier inversión grande: qué estandarizar comprando, qué diferenciar construyendo y qué conectar integrando.

Señales de que tu problema no necesita software nuevo

Antes de pedir un presupuesto de desarrollo, fijate si aparece alguna de estas señales:

Si reconocés varias, el primer paso casi seguro no es construir, sino ordenar, comprar o conectar: sale más barato y se resuelve antes. Vale lo mismo que para cualquier circuito, porque sumar tecnología sobre un proceso desordenado no lo arregla.

Cómo lo pensamos en Lirroy

Cuando alguien llega pidiendo un sistema, no arrancamos cotizando. Primero miramos el problema: si lo que traba la operación es el orden, una capacidad que falta o piezas que no se conectan. Ese diagnóstico es el plano sobre el que se construye después; sin él, cualquier sistema se apoya en arena.

Por eso trabajamos en dos tiempos. Primero ordenamos el circuito, dejamos claras las reglas y conectamos lo que ya tenés funcionando. Y sobre esa base, recién ahí, construimos lo que de verdad valga la pena, que casi siempre termina siendo más chico, más barato y más sólido que el sistema enorme del principio. En ningún momento te quedás con las manos vacías: salís con una operación que ya rinde y un plan claro de qué construir encima.

Antes de pedir el presupuesto

La próxima vez que sientas que hace falta un sistema, frená un segundo en la pregunta del principio. Mirá si el problema es de proceso, de herramienta o de integración antes de dar por hecho que es de desarrollo. Y tené presente que ordenar primero es lo que te deja mejor parado para construir: sobre una base firme, lo que se levanta después sale mejor, más barato y más tuyo que el sistema que se pedía de entrada.