Un desarrollo de 10.000 euros puede salir barato. Uno de 1.000 puede ser carísimo.
El precio, por sí solo, dice bastante poco. Lo importante es cuánto trabajo elimina, cuántas personas lo utilizarán, qué errores evita, cuánto tiempo seguirá siendo útil y qué coste tendrá mantenerlo cuando cambien el negocio o el propio Odoo.
En Odoo casi todo se puede desarrollar. Puedes añadir un campo, modificar una vista, automatizar una secuencia de acciones o construir una aplicación completa para representar una parte muy específica de la empresa. Precisamente por eso conviene frenar antes de abrir el editor.
Antes de estimar el coste, necesito entender qué problema estamos intentando resolver y si el código es realmente la mejor forma de hacerlo.
Primero hay que entender la necesidad
Mi forma de valorar una petición cambia mucho según trabaje desde dentro de una empresa o como consultor externo.
En la empresa en la que trabajo llevo años conviviendo con los procesos, los usuarios y el sistema. Cuando alguien me pide una mejora, normalmente entiendo de dónde viene la necesidad, qué partes de Odoo puede afectar y si ya existe alguna herramienta que pueda resolverla. A veces incluso conozco mejor que quien la solicita las consecuencias técnicas de lo que está pidiendo, porque puedo situarlo dentro de todo lo que ya existe.
Con un cliente externo parto con una desventaja evidente: no conozco su negocio ni su instalación. Antes de valorar el desarrollo tengo que entender cómo trabajan, por qué lo hacen así y qué esperan conseguir.
Es parecido a pedirle a un arquitecto que añada un fregadero en una habitación. Quien diseñó la casa sabe dónde están las tuberías y puede anticipar enseguida si la petición es sencilla o si exige una reforma desproporcionada. Quien llega de fuera necesita mirar los planos, revisar lo construido y entender el uso que se quiere dar a esa habitación antes de proponer nada.
Con el software ocurre lo mismo. El cliente conoce su problema, pero no necesariamente el alcance de la solución concreta que está proponiendo.
Muchas peticiones llegan formuladas como una solución:
Quiero un botón que haga esto.
Cuando ocurra aquello, quiero que el sistema confirme esto automáticamente.
Necesito que esta pantalla funcione igual que en el ERP anterior.
El trabajo de consultoría empieza un paso antes. Hay que averiguar qué necesidad hay detrás, si responde a una particularidad real del negocio o a una costumbre adquirida, y si puede resolverse mediante configuración, un módulo existente, una pequeña adaptación o un cambio en el propio proceso.
Un despacho de abogados puede utilizar Odoo para presupuestos, CRM y facturación y, al mismo tiempo, necesitar una gestión de expedientes con estados, documentación, responsables y reglas propias. Si el núcleo de su trabajo no está representado por ningún módulo estándar, construir una aplicación específica tiene sentido. Ese desarrollo cubre una necesidad propia del negocio y tiene una función clara dentro del sistema.
El retorno no se mide en horas de programación
Para decidir si un desarrollo compensa, intento valorar al menos cinco cosas: frecuencia de uso, número de usuarios, tiempo ahorrado, errores evitados y vida útil.
Si una persona pulsa una vez al día un botón que le ahorra cinco segundos, difícilmente justificará varias horas de análisis, desarrollo, pruebas y despliegue. Puede hacer su trabajo un poco más cómodo, pero la empresa tardará años en recuperar lo que ha invertido.
El cálculo cambia por completo si una persona dedica cada mañana una hora y media a revisar un informe para encontrar tres o cuatro discrepancias entre cientos de líneas. Si el sistema puede hacer el análisis mecánico y dejarle únicamente los casos que requieren criterio, el desarrollo libera tiempo de forma inmediata y repetida.
También aparece una economía de escala evidente. Ahorrar cinco segundos a una sola persona una vez al día tiene poco impacto. Ahorrar esos mismos cinco segundos a cien personas todos los días ya es otra cosa. Cuando el uso es constante y transversal, una mejora pequeña puede empezar a devolver dinero muy pronto.
Parte del retorno está en reducir errores, mejorar la trazabilidad, evitar una reclamación, acelerar una decisión o permitir que una persona dedique su tiempo a una tarea con más valor.
Una pregunta que me parece útil es esta:
Si esta persona dejara de hacer este trabajo manual, ¿qué podría aportar en su lugar?
La pregunta amplía el cálculo más allá del coste por hora. Puede que el tiempo liberado permita atender mejor a clientes, revisar excepciones, mejorar datos o evitar que una tarea repetitiva ocupe una parte importante de la jornada.
Por eso un desarrollo de 10.000 euros puede ser barato si ahorra varias horas diarias a quince personas. Uno de 1.000 puede ser muy caro si apenas se utiliza y no reduce ningún riesgo relevante.
El coste invisible de “solo un botón”
Cuando alguien imagina un desarrollo, suele pensar en el camino feliz.
Pulso el botón, el documento se procesa, se envía la notificación y todo termina correctamente.
El alcance real aparece cuando falta stock, el documento está bloqueado, el usuario no tiene permisos, el destinatario está ausente, falta un dato o alguien ejecuta la acción dos veces. También hay que decidir cómo se revierte el resultado cuando algo no sale como estaba previsto.
Un desarrollo incluye entender el proceso, documentar excepciones, programar, probar, desplegar, recoger feedback y mantener la solución. Aunque la inteligencia artificial pueda escribir parte del código, todo ese trabajo sigue existiendo.
Algunos errores tampoco se manifiestan en el momento. Una automatización puede repartir incorrectamente el coste de un producto, introducirlo en stock con una valoración equivocada y afectar después a movimientos, ventas o informes. Cuando alguien detecta el problema, ya no basta con corregir una línea: hay que reconstruir qué ocurrió y reparar las consecuencias.
Para valorar una automatización intento comparar el ahorro acumulado con el daño que puede causar una sola excepción. Si ahorra un minuto cada vez, pero una vez al mes provoca una incidencia que exige una hora de investigación y corrección, el balance real cambia bastante.
El tiempo ahorrado y los errores evitados forman parte de la misma cuenta. En procesos con impacto sobre stock, costes o contabilidad, la confirmación y la posibilidad de revertir una operación forman parte del desarrollo desde el principio.
Automatizar no siempre significa decidir por el usuario
Siempre he defendido una idea sencilla: cuando una persona trabaja para el ordenador en lugar de que el ordenador trabaje para ella, existe una oportunidad de mejorar el proceso.
Los casos deterministas deben resolverlos las máquinas. No tiene sentido que una persona repita cálculos, copie datos o revise cientos de registros para encontrar una excepción que el sistema podría detectar por sí solo.
El problema aparece cuando tratamos como determinista algo que en realidad admite excepciones.
En una ocasión trabajé sobre una operativa en la que un producto recibido debía descomponerse en varios componentes de stock, con su correspondiente reparto de costes. Automatizar completamente la descomposición parecía elegante, pero obligaba a mantener sincronizados cambios de pedido, recepciones, cantidades, devoluciones y valoraciones.
Una alternativa más segura consiste en detectar la situación, avisar a la persona responsable y proponer la operación. El sistema prepara el trabajo, muestra qué va a ocurrir y pide confirmación. Idealmente, también permite revertirlo.
La operación sigue siendo rápida, pero queda bajo control cuando aparece un caso distinto del previsto.
Un buen desarrollo también puede añadir pasos
En el almacén de la empresa en la que trabajo, preparar un pedido era hasta hace poco un proceso mucho menos guiado. La aplicación que hemos introducido obliga ahora a escanear números de serie, validar líneas y hacer una fotografía antes de cerrar el paquete.
Para la persona que prepara el pedido hay más pasos que antes y, en algunos momentos, menos agilidad.
La empresa obtiene a cambio trazabilidad, puede comprobar qué unidad se envió a cada cliente, revisar una incidencia, ver cómo salió el paquete y reducir determinados errores.
La decisión corresponde a quienes pueden valorar el proceso completo: operaciones, dirección y los responsables de calidad o del departamento. Son ellos quienes deben comparar el coste de esos pasos adicionales con el valor de la información que se obtiene.
En nuestro caso lo planteamos como una decisión de operación y calidad, no como una simple reducción de clics.
Configurar, reutilizar, adaptar y solo después desarrollar
Antes de construir una solución desde cero, conviene comprobar cómo resuelven otros el mismo problema.
A veces la necesidad ya está cubierta por Odoo mediante configuración. Otras existe un módulo de la OCA o de un tercero que resuelve gran parte del caso. Si el módulo es fiable, está mantenido y cubre el 90 % de lo que necesitamos, suele ser más sensato extenderlo con una pieza pequeña que reconstruirlo todo.
Eso reduce horas de desarrollo y volumen de código propio. También puede facilitar futuras migraciones, especialmente cuando se parte de módulos mantenidos entre versiones y con unos criterios de calidad conocidos.
No instalaría cualquier cosa que aparezca en una búsqueda. Hay que revisar el código, las dependencias, el mantenimiento, la licencia y la compatibilidad con nuestra instalación. Aun así, merece la pena buscar antes de reinventar la rueda.
La jerarquía que intento seguir es sencilla:
- Ver si puede resolverse con configuración.
- Buscar una funcionalidad estándar o un módulo fiable.
- Adaptar o extender una solución existente.
- Desarrollar desde cero cuando la necesidad sea realmente propia.
También conviene revisar el proceso. Las empresas, igual que las personas, adquieren hábitos y vicios. Una tarea pudo tener sentido cuando había cinco clientes y convertirse en un problema cuando hay dos mil.
El envío manual de un Excel con los pedidos pendientes puede empezar como una atención útil cuando hay pocos clientes y mantenerse durante años por pura costumbre.
Antes de automatizar ese envío, comprobaría si el cliente sigue valorándolo, si existe una forma estándar de ofrecer la información y si la tarea aporta algo diferencial. Si no es así, primero cambiaría el proceso.
La vida útil y la adopción también cuentan
No todos los desarrollos tienen que durar diez años.
A veces una pieza temporal sirve como puente entre dos formas de trabajar. Durante una migración puede ser razonable construir una ayuda que permita a los usuarios adaptarse poco a poco al sistema nuevo. Su vida útil será limitada, pero puede resultar necesaria para que el cambio funcione.
Conviene saber desde el principio que estamos construyendo una transición y decidir qué ocurrirá después. Sin documentación ni una fecha para revisarla, esa ayuda temporal puede acabar convertida en arqueología dentro del sistema.
La adopción forma parte del retorno.
En una ocasión desarrollamos una especie de asistente comercial que permitía a cada usuario definir reglas para priorizar los pedidos que quería revisar. En vez de recorrer decenas de documentos todos los días, podían quedarse únicamente con los que cumplían sus criterios.
El desarrollo funcionaba y estaba bien resuelto, pero solo una parte pequeña del equipo terminó utilizándolo de forma habitual. Para quienes lo incorporaron a su trabajo aportó valor durante años. El retorno global quedó limitado por la adopción.
He visto el caso contrario con una mejora menos vistosa: unos filtros dinámicos reutilizables en muchas vistas del sistema. Su alcance era relativamente acotado, pero terminó aportando agilidad de forma constante a numerosos usuarios y en contextos muy distintos. Se utiliza continuamente y ha acabado siendo mucho más valiosa de lo que sugería su tamaño.
La inteligencia artificial cambia el coste, pero no la pregunta
La IA ayuda en dos cosas concretas: permite ordenar mejor el problema antes de programar y abarata parte de la ejecución técnica.
Puede preparar un guion para analizar una petición, obligarte a responder preguntas que todavía no habías formulado, explorar alternativas, revisar código, proponer casos límite, generar una primera implementación o escribir pruebas. Hay tareas que antes resultaban tediosas y que ahora pueden hacerse con mucha más agilidad.
El análisis del negocio, la validación en condiciones reales y la responsabilidad sobre el resultado siguen recayendo en las personas.
La velocidad de ejecución no arregla una mala decisión de partida. Por eso utilizo la IA para preparar análisis y acelerar trabajo, pero nunca como argumento suficiente para justificar una funcionalidad.
La responsabilidad de decir que no
Con la experiencia, algunas peticiones empiezan a reconocerse bastante rápido.
Una necesidad real, utilizada de forma constante, adaptable a los cambios del negocio y capaz de reducir tiempo, errores o riesgo suele ser una buena candidata.
Una solución muy específica, ligada a una excepción concreta, con poco uso y escaso valor añadido suele apuntar en la dirección contraria.
La intuición debe contrastarse. Antes de desarrollar intentaría responder estas preguntas:
- ¿Qué necesidad real resuelve y cómo mediremos el valor que aporta?
- ¿Existe ya una solución estándar o reutilizable?
- ¿Cuántas personas la utilizarán, con qué frecuencia y durante cuánto tiempo?
- ¿Qué tiempo ahorra, qué errores evita o qué riesgo reduce?
- ¿Qué coste tendrá mantenerla cuando cambien Odoo o el propio proceso?
- ¿Qué puede salir mal y cómo se revierte el resultado?
El trabajo del consultor incluye presupuestar lo técnicamente viable, pero empieza antes: señalar cuándo basta con configurar Odoo, cuándo conviene adaptar un módulo existente, cuándo merece la pena cambiar el proceso y cuándo el desarrollo no se amortizará.
No desarrollar por desarrollar evita frustraciones a las dos partes. El cliente no paga por una pieza que terminará sin usar o que le impondrá una rigidez innecesaria. El consultor puede concentrarse en trabajos que aporten valor y que tenga sentido mantener.
Si no tengo respuestas claras a estas preguntas, prefiero no presupuestar todavía. Antes de abrir el editor necesito separar la necesidad de la costumbre y comprobar que el código va a devolver algo a cambio.
Solo entonces tiene sentido desarrollarlo.