Vivo de desarrollar software a medida, así que este artículo juega en mi contra. Lo escribo igualmente, porque los peores proyectos en los que he estado tenían todos el mismo origen: alguien decidió que necesitaba software antes de entender qué le estaba pasando.
Cuando alguien me cuenta un problema, hay cinco conclusiones posibles. Solo una de las cinco es «hay que desarrollar algo».
1. Basta con simplificar el proceso
Es la conclusión más frecuente y la que menos gusta escuchar, porque implica que el problema no era técnico.
Señales de que estás aquí:
- El proceso tiene pasos que nadie sabe explicar por qué existen. «Siempre se ha hecho así.»
- Hay validaciones dobles: alguien comprueba lo que otra persona ya comprobó.
- Se pide información que luego no se usa para nada.
- El cuello de botella es una única persona que tiene que aprobar algo.
Automatizar un proceso con pasos inútiles te da lo mismo que tenías, más rápido y por 8.000 €. Los pasos inútiles siguen ahí, ahora en código y más difíciles de quitar.
2. Se resuelve automatizando lo que ya existe
El proceso está bien, pero alguien lo ejecuta a mano cada día. Recordatorios que se mandan uno a uno, informes que se montan copiando celdas, correos de seguimiento escritos de cero cada vez.
Estás aquí si la tarea es repetitiva, con reglas claras y sin excepciones constantes. Ese último punto es el filtro de verdad: si cada caso tiene su matiz, no es automatizable todavía, es que el proceso no está definido. Vuelve al punto 1.
3. Hay que integrar lo que ya tienes
Tienes las herramientas correctas pero no se hablan entre ellas. Alguien copia datos de una pantalla a otra varias veces al día.
Este es el caso donde el retorno suele ser más claro y el coste más bajo de los tres primeros. Conectar dos sistemas que ya funcionan es bastante menos trabajo que construir uno nuevo, y el equipo no tiene que aprender nada: siguen usando lo de siempre.
El riesgo aquí es distinto: dependes de que ambas herramientas permitan integrarse. Antes de prometer nada hay que comprobar que existe una API razonable en las dos puntas. Si una de ellas es un programa cerrado de hace quince años, la integración puede salir más cara que empezar de nuevo.
4. Sí, toca desarrollar
Llegas aquí cuando se cumplen todas estas condiciones, no algunas:
- El proceso ya está simplificado y sigue doliendo.
- No existe una herramienta de mercado que lo cubra, y lo has comprobado de verdad, no de oídas.
- Lo que te diferencia de la competencia está precisamente en ese proceso.
- El volumen justifica la inversión: haces esto muchas veces, no tres al mes.
- Vas a poder mantenerlo. Un desarrollo a medida no se acaba el día que se entrega.
La condición 3 es la que más gente se salta. Si tu proceso de facturación es idéntico al de cualquier otro centro, desarrollar tu propio programa de facturación es pagar por reinventar algo que ya existe y que además tiene que cumplir Verifactu. En cambio, si tu forma de organizar los bonos de sesiones es tuya y es parte de por qué la gente repite, ahí sí hay algo que ninguna herramienta estándar te va a dar.
5. No merece la pena hacer nada
Existe, y es una conclusión legítima.
Si el proceso te cuesta dos horas al mes, resolverlo cuesta 6.000 € y el ahorro anual son 900 €, la respuesta es no hacer nada. No porque no se pueda, sino porque tu dinero rinde más en otro sitio.
La forma rápida de verlo: divide el coste de la solución entre el ahorro anual. Si el resultado pasa de tres años, casi siempre hay una prioridad mejor. Y si el proceso que te molesta lo ejecutas cuatro veces al año, por muy irritante que sea, no es ahí donde está tu problema.
Cómo saber en cuál estás
Cuatro preguntas, por este orden. El orden importa: cada una filtra a la siguiente.
| Pregunta | Si la respuesta es sí |
|---|---|
| ¿Hay pasos que no sabes justificar? | Simplifica primero (1) |
| ¿Es repetitivo y sin excepciones? | Automatiza (2) |
| ¿Copiáis datos entre programas? | Integra (3) |
| ¿Es un proceso que te diferencia? | Desarrolla (4) |
Si has llegado al final sin ningún sí, estás en el 5. Y eso también es una respuesta útil: te ahorra el dinero y la decepción.
Por qué te cuento esto
Porque un proyecto que no debería haberse hecho acaba mal para las dos partes. El cliente paga algo que no usa y yo me quedo con un desarrollo que nadie mantiene y una recomendación que nunca llega.
Prefiero decir «esto no lo desarrolles» tres veces y que la cuarta me llames con algo que sí tiene sentido.
Resumen
- Cinco conclusiones posibles: simplificar, automatizar, integrar, desarrollar o no hacer nada.
- Solo una implica escribir código.
- Automatizar un proceso mal diseñado te da el mismo lío, más rápido.
- Desarrolla solo si el proceso te diferencia y se cumplen las otras cuatro condiciones.
- Si el retorno pasa de tres años, hay una prioridad mejor.