Desarrollo a medida solo donde Odoo estándar no alcanza
Diego revisa primero si basta con configurar o con integrar otro sistema. Cuando hace falta programar, el desarrollo va en un módulo aparte, con su prueba automática, y el código queda a nombre de su empresa para que cualquier proveedor pueda continuarlo.
Desarrollo en Odoo 17, 18, 19 y 20, o sobre su sistema actual si tiene API
Lo que queda a su nombre al cerrar
- Repositorio del códigoA nombre de su empresa
- Sistema base de OdooSin modificar
- Prueba automáticaUna por cada flujo entregado
- Diseño de pantallasAprobado antes de programar
- Cambio de versiónProbado en un ambiente de prueba
Un cambio hecho dentro del sistema base se paga en cada actualización
El mismo requerimiento se puede programar de dos maneras. La diferencia aparece meses después, cuando sale una versión nueva de Odoo o cuando cambia la persona que lo mantiene.
Cambio dentro del sistema base
- Cada actualización de versión rompe algo y se posterga
- Nadie sabe con exactitud qué se cambió ni por qué
- Solo quien lo programó puede tocarlo
Módulo aparte, a nombre de su empresa
- El módulo se migra y se prueba antes de pasar a producción
- Cada cambio queda en el historial, con fecha y motivo
- Otro proveedor lo continúa con el manual y las pruebas
Lo que cuesta seguir así
Rodeos diarios en pantallas que no responden la pregunta
Para ver un saldo se abren cinco pantallas o se exporta a Excel. El celular muestra la vista de escritorio encogida.
Una versión de Odoo que no se puede actualizar
Los cambios hechos dentro del código base frenan la migración. La empresa se queda sin las mejoras de las versiones nuevas.
Un proveedor del que no se puede salir
Sin repositorio, sin documentación y sin pruebas, cambiar de proveedor significa rehacer el desarrollo.
Diego programa solo lo que el diagnóstico justifica
DMG-RT, el método propio de Diego, une cada desarrollo a un indicador medido antes de tocar el sistema; en este servicio, el tiempo que toma la tarea en pantalla y cuántas veces se sale del sistema para hacerla.
Diagnóstico: se recorre la pantalla con quien la usa
Diego cuenta los rodeos de hoy: pantallas abiertas, exportaciones a Excel, tiempo por consulta. Después revisa si Odoo estándar lo resuelve con un ajuste, con otro módulo o con una integración. Programar es la última opción de la lista.
Entregable: Carta de hallazgos con la opción más corta para cada necesidad y la línea base del indicador.
Diseño: la pantalla se aprueba antes de escribir código
Boceto para escritorio y para celular, reglas de negocio y plan de pruebas. Lo aprueba el dueño del proceso. Con ese diseño se fija el monto de cada entrega.
Entregable: Diseño aprobado, ficha del indicador y presupuesto por entrega.
Implementación y control: entregas de dos semanas
Cada entrega se programa en un módulo aparte y se prueba en un ambiente con copia de sus datos. Una prueba automática recorre el flujo completo antes de cada cambio. Pasa a producción con respaldo previo y Diego la verifica en su instancia real, en escritorio y en celular.
Entregable: Módulo en operación, prueba automática por flujo e historial de cambios.
Traspaso: el código queda en su repositorio
Repositorio, credenciales y documentación pasan a su empresa. Su equipo recibe un manual por rol. Las revisiones a 3, 6 y 12 meses miden el mismo indicador de la línea base.
Entregable: Acta de cierre, manual de operación y documentación técnica.
- 1. Configurar lo que Odoo ya trae
- 2. Integrar otro módulo o sistema
- 3. Programar en un módulo aparte
- 4. Entregar código y pruebas a su nombre
Lo que recibe le permite cambiar de proveedor sin rehacer el desarrollo
La objeción habitual es quedar atado a quien programó. Por eso cada necesidad pasa primero por el estándar, y lo que sí se programa llega con repositorio, diseño, pruebas y manual a nombre de su empresa.
| Necesidad | Qué ofrece el estándar | Decisión |
|---|---|---|
| Aprobar compras según el monto | Doble validación en Compras | Configurar |
| Un dato adicional en la orden de venta | Campo personalizado con Studio | Configurar |
| Vender en línea con el mismo stock del almacén | Módulo eCommerce de Odoo | Configurar |
| Pedidos de un marketplace o de la pasarela de pagos | Conector o API entre los dos sistemas | Integrar |
| Saldo de un presupuesto con alerta, en una sola vista | Ninguna vista estándar lo reúne | Programar |
| Pantalla de celular para el técnico, con los pasos de su rubro | Servicio de campo cubre la orden, no sus pasos propios | Programar |
| Cálculo de comisiones o tarifas propio del rubro | Las reglas estándar no lo expresan | Programar |
Repositorio con el historial completo
Alojado en la cuenta de su empresa. Cada cambio tiene autor, fecha y motivo.
Documento de diseño aprobado
Bocetos de escritorio y celular, reglas de negocio y alcance de cada entrega.
Pruebas automáticas
Una por flujo. Se corren antes de cada cambio y antes de cada actualización de versión.
Manual por rol y documentación técnica
Para el usuario, para quien administra y para el próximo programador.
Credenciales y accesos
Todos a nombre de su empresa. Diego no conserva accesos que usted no haya autorizado.
Recorrido que repite la prueba automática
- Crear el pedido con un cliente de prueba
- Aprobar según el monto y el responsable
- Entregar desde el almacén correcto
- Facturar y revisar el asiento contable
- Repetir en la vista de celular
Ejemplo ilustrativo. Si un paso falla, el cambio no pasa a producción.
Traiga la pantalla que le falta y revise con Diego si conviene configurar, integrar o programar.
Agendar diagnóstico de 30 minQué necesita Diego para empezar y cuándo no conviene programar
Usted aporta
- Una persona que use la pantalla todos los días y pueda mostrar cómo trabaja hoy.
- Acceso a un ambiente de prueba con copia de sus datos.
- Un responsable del proceso que apruebe el diseño y cada entrega.
- La cuenta de su empresa donde quedará el repositorio.
Cuándo no conviene
Si un ajuste o un módulo estándar resuelven la necesidad, Diego lo dice en el diagnóstico y no se programa. Si el proceso todavía no está definido, conviene ordenarlo primero. Si lo que falta es que dos sistemas se hablen, es una integración.
Diego escribe el diseño antes que el código
Diego Muñoz es consultor de procesos y sistemas y programa en Odoo desde la versión 17 hasta la 20. Antes de desarrollar, recorre la tarea con quien la hace y busca la salida en el estándar. Cuando programa, lo hace en un módulo propio del cliente, nunca en el sistema base ni en módulos de terceros.
No da por terminada una entrega hasta verla funcionar en la instancia real del cliente, en escritorio y en celular, con su prueba automática en verde.
- Odoo 17, 18, 19 y 20
- Método DMG-RT
- Arquitectura empresarial con TOGAF
Propiedad, versiones y costo de un desarrollo
¿El código es mío?
Sí. El repositorio se crea en la cuenta de su empresa, con el historial de cambios, la documentación y las pruebas automáticas.
¿Qué pasa cuando actualizo Odoo?
El módulo se migra a la nueva versión y se prueba en un ambiente de prueba con las mismas pruebas automáticas antes de pasar a producción.
¿Puedo cambiar de proveedor después?
Sí. Con el repositorio, el documento de diseño, el manual y las pruebas, otro programador puede continuar el desarrollo sin rehacerlo.
¿Trabajan sobre sistemas que no son Odoo?
Sí, si el sistema tiene API o una base de datos accesible. Se confirma en el diagnóstico, con su caso concreto.
¿Hacen aplicaciones para celular?
Sí. Lo habitual es una pantalla de Odoo diseñada para el celular. Cuando el caso lo pide, una aplicación Android conectada al ERP, con acceso por usuario.
¿Cómo se cotiza un desarrollo?
Con un monto fijo por entrega, después de aprobar el diseño. Cada entrega tiene su alcance y su prueba, y al cerrarla usted decide si continúa.
Revise con Diego en 30 minutos si su caso pide configurar, integrar o programar
- Usted muestra la pantalla o la tarea que hoy obliga a dar rodeos.
- Diego revisa si Odoo estándar la resuelve o si hace falta programar.
- Recibe por escrito la opción más corta y su alcance.