Si cada venta obliga a revisar una hoja de cálculo, preguntar por existencias y volver a capturar datos para facturar, el problema no es la falta de pantallas: es que el trabajo pierde continuidad. Elegir un ERP para tu pyme empieza por identificar esos puntos de ruptura y comprobar qué solución puede resolverlos bajo tus condiciones.
Para decidir, define qué no puede fallar, pide a cada candidato que resuelva el mismo caso y compara la evidencia junto con el alcance económico. Una función indispensable sin demostrar no se compensa con más aplicaciones, una interfaz atractiva o una licencia menor.
1. Define qué necesita resolver tu empresa
Empieza por tres procesos que hoy generen retrabajo o incertidumbre. Por ejemplo: vender y entregar, comprar y recibir, y conciliar la operación con la facturación. Para cada uno, anota quién lo inicia, qué información necesita, dónde se detiene y qué resultado debe obtener.
Describe también las condiciones de trabajo: usuarios y permisos, sucursales o almacenes, operaciones habituales y momentos de mayor carga. Identifica los sistemas que deben seguir funcionando, como una tienda en línea o una aplicación sectorial. El tamaño de la empresa, por sí solo, no explica esos requisitos.
Clasifica lo que encuentres:
- Indispensable: si falla, no puedes operar dentro del alcance acordado. Debe tener una prueba de aceptación.
- Deseable: aporta valor, pero puedes posponerlo o trabajar temporalmente de otra forma.
- Fuera de alcance: no se necesita en esta decisión. Déjalo escrito para no convertir una evaluación en un proyecto sin límites.
Conviene sustituir peticiones vagas por condiciones observables. «Buen control de inventario» deja demasiado a interpretación. «Entregar parte de un pedido, identificar lo pendiente y evitar una segunda salida duplicada» permite diseñar una prueba.
Si sólo necesitas resolver una función acotada, sin conectar procesos, compara primero si una herramienta más simple basta.
2. Comprueba los requisitos con una demostración comparable
Entrega a cada candidato el mismo escenario ficticio y los mismos criterios de aceptación. Incluye el recorrido normal y una excepción relevante: una entrega parcial, una devolución o un error de integración. Pide al proveedor que muestre el recorrido con los permisos previstos para quienes usarán el sistema, no sólo desde una sesión de administrador. La preparación de esos perfiles y de la demostración es responsabilidad del proveedor; tu equipo describe el trabajo diario y valida el resultado.
Lleva tus procesos prioritarios, quién hace cada tarea y los sistemas que deben conservarse. Puedes plantear el caso sin montar un entorno, desarrollar una integración ni compartir datos personales o información comercial real.
Registra qué demuestra cada candidato
Usa una copia de la matriz por candidato. El proveedor aporta la demostración y las evidencias; las personas de tu empresa que conocen el proceso validan el resultado.
Completa la última columna con uno de cuatro estados: demostrado, parcial, pendiente o no cubierto. En evidencia, registra el documento o resultado que el proveedor presenta, no sólo el nombre de quien lo aseguró. Anota también su versión, plan y configuración declarados. El responsable interno de cada fila valida la necesidad y el resultado; no tiene que realizar la preparación técnica.
| Requisito | Criticidad | Qué pedir al proveedor y cómo aceptarlo | Modalidad de cobertura | Evidencia, versión y plan | Quién valida en tu empresa | Resultado y pendiente |
|---|---|---|---|---|---|---|
| Venta con entrega parcial | Indispensable | Mostrar un pedido de 20 unidades, entrega de 12 y después 8; comprobar cantidades, pendientes y documentos sin duplicados | Por confirmar | Por registrar | Ventas y almacén | Pendiente; acordar política de facturación |
| Permisos operativos | Indispensable | Mostrar con un perfil operativo el bloqueo de una acción reservada y el circuito de autorización acordado | Por confirmar | Por registrar | Responsable operativo | Pendiente; definir acción y perfiles |
| Integración que debe conservarse | Indispensable si sostiene la operación | Demostrar qué ocurre ante una entrada repetida y un error; mostrar recuperación sin duplicados y su rastro | Por confirmar | Por registrar | Responsable de integración | Pendiente; identificar quién recupera fallos |
| Documentos mexicanos aplicables | Indispensable para el caso definido | Demostrar el escenario definido por tu responsable contable, incluidas sus excepciones pertinentes | Por confirmar | Por registrar | Responsable contable | Pendiente; precisar documentos y configuración |
| Salida y continuidad | Indispensable según requisitos acordados | Mostrar qué datos se pueden exportar y aportar evidencia de cómo se recuperan, con alcance acordado | Por confirmar | Por registrar | Responsable de datos | Pendiente; delimitar datos, archivos y accesos |
| Reporte adicional de seguimiento | Deseable | Mostrar el indicador acordado a partir de las operaciones del caso | Por confirmar | Por registrar | Dirección operativa | Pendiente; definir cálculo |
En modalidad de cobertura, distingue nativo, configuración, extensión propia y tercero. Si un requisito combina varias, anótalas. Después identifica quién configura, mantiene y responde por cada parte. «Se puede desarrollar» expresa una posibilidad, no un requisito cubierto: faltan alcance, aceptación y mantenimiento.
Si una parte requiere desarrollo o un tercero y todavía no hay evidencia específica, consérvala como pendiente y solicita alcance y responsable por escrito.
Ejemplo: una distribuidora que entrega por partes
Imagina una distribuidora de consumibles con un almacén y una tienda en línea que seguirá activa. Ventas recibe un pedido de 20 unidades, pero sólo hay 12 disponibles. La encargada de almacén necesita despachar esas 12 sin perder de vista las 8 pendientes; administración quiere emitir los documentos conforme a la política acordada y la tienda no debe crear otro pedido si reenvía el mensaje original.
La distribuidora entrega esa situación a los proveedores para que cada uno muestre cómo la resolvería. Antes de comparar sistemas, el equipo define cuatro indispensables: entrega parcial trazable, tratamiento correcto de la facturación según su política, permisos de almacén e integración sin duplicados. Un tablero de presentación queda como deseable.
Supongamos que el proveedor de un candidato muestra la primera entrega y el pendiente, pero deja para después la demostración de recuperación de errores de la tienda. La matriz podría registrar así esa evaluación hipotética:
| Requisito | Evidencia del supuesto | Estado | Decisión |
|---|---|---|---|
| Entrega parcial | Se identifican 12 entregadas y 8 pendientes, pero no se completa la segunda salida | Parcial | Pedir al proveedor la entrega restante y la conciliación final |
| Facturación | Se muestra una factura, pero no se concilia con la política acordada | Parcial | Pedir el recorrido completo al proveedor; administración valida |
| Permisos | Se usa únicamente un perfil administrador | Pendiente | Pedir al proveedor que lo muestre con un perfil operativo |
| Integración | No se prueba el reenvío del pedido ni la recuperación del error | Pendiente | Solicitar evidencia y responsable de recuperación al proveedor |
Este candidato seguiría pendiente. La distribuidora pediría completar la segunda entrega y las demostraciones de facturación, permisos e integración antes de cambiar los estados de la matriz. Si la integración no pudiera cubrirse dentro de sus recursos aceptables, tendría que revisar la arquitectura o evaluar otra solución.
3. Compara el alcance económico completo
Compara propuestas bajo los mismos supuestos de usuarios, compañías, procesos y sistemas conectados. Separa estos rubros aunque un proveedor los agrupe comercialmente:
- Licencias y alojamiento.
- Configuración y adaptación de procesos.
- Preparación, limpieza y migración de datos.
- Integraciones y extensiones.
- Capacitación y disponibilidad del equipo interno.
- Soporte, actualizaciones y mantenimiento de código adicional.
- Exportación de información y una eventual salida o migración.
Pide aclarar cuáles son iniciales, recurrentes o dependen de cambios de alcance. No compares una licencia aislada con una propuesta que incluye servicios y mantenimiento.
Después plantea un escenario de crecimiento propio: más usuarios, otra compañía o mayor volumen de pedidos. Pide que indiquen qué cambiaría y bajo qué supuestos. No hace falta predecir un ahorro para identificar una propuesta incompleta o un mantenimiento que tu empresa no puede sostener.
4. Si evalúas Odoo, confirma sus condiciones de encaje
Odoo merece evaluarse cuando buscas conectar procesos y el proveedor demuestra que los requisitos críticos se cubren con una combinación viable de aplicaciones, configuración y servicios. Tu equipo evalúa esa evidencia frente a las necesidades de la empresa. No basta con que su catálogo mencione las áreas de tu empresa.
Para revisar esa propuesta, distingue tres conceptos que se relacionan, pero no son equivalentes. La edición identifica una variante del producto; el plan, las condiciones de contratación; el alojamiento, dónde se ejecuta y quién lo administra. En Odoo, la documentación distingue Community y Enterprise: no conviene asumir que tienen el mismo alcance funcional. Administración y ediciones de Odoo.
Si necesitas API externa, varias compañías o personalización, revisa el plan y la arquitectura: no des por suficiente Standard ni asumas que cualquier personalización cabe en Online. Estas condiciones corresponden a la oferta de Odoo y a sus restricciones de Online.
Localización mexicana: pide al proveedor que demuestre la cobertura
La documentación de Odoo para México describe módulos contables y documentos electrónicos, además de requisitos de configuración como el Registro Federal de Contribuyentes (RFC), el Certificado de Sello Digital (CSD) y un Proveedor Autorizado de Certificación (PAC). Que exista esa localización no demuestra que cualquier instalación cubra todos los documentos o escenarios de tu empresa. Solicita al proveedor que explique qué edición, módulos y configuración incluye su propuesta y que demuestre los casos que necesitas resolver. Tu responsable contable valida si esa cobertura responde a la operación de la empresa. Localización mexicana de Odoo.
Para comparar propuestas, pide que identifiquen qué está incluido, qué depende de un tercero y qué sigue pendiente. Una respuesta genérica de «cumple SAT» no sustituye esa comprobación.
Integraciones: tener API no significa tener el trabajo resuelto
Una API permite que otros sistemas se comuniquen con el producto; no define por sí sola cómo se relacionan los datos ni qué ocurre cuando falla un envío. La documentación de API externa de Odoo la vincula al plan Custom dentro de los planes comerciales descritos, no a Standard ni One App Free. Esa condición comercial no debe extrapolarse a todas las instalaciones Community. API externa de Odoo.
Pregunta quién construye o suministra el conector, qué versiones soporta, cómo detecta duplicados y quién atiende una interrupción. Incluye su mantenimiento en la propuesta: que la conexión funcione una vez no resuelve cómo se sostendrá.
Nube o servidor propio: decide por restricciones y responsabilidades
Según la oferta de Odoo, Standard utiliza Odoo Online; Custom contempla Online, Odoo.sh o instalación propia. Elegir Custom no elimina las restricciones del alojamiento. Planes de Odoo.
En particular, Odoo Online no admite módulos personalizados ni módulos de Odoo Apps Store. Esto no significa que carezca de toda posibilidad de personalización: no es lo mismo utilizar Studio que instalar un módulo propio. Si un requisito exige ese módulo y permanecer en Online es obligatorio, la combinación no encaja. Restricciones de Odoo Online.
Sea cual sea el alojamiento, deja por escrito quién administra accesos, respaldos, actualizaciones y recuperación. Online documenta la descarga de respaldos, pero disponer de una copia no equivale a trasladar automáticamente la operación a otro ERP. Pide delimitar datos, adjuntos y configuración, y cómo se recuperarán. Gestión de bases y respaldos en Odoo Online.
Presupuesto: confirma qué queda fuera del plan
En Odoo, la página de planes excluye del precio del plan, entre otros conceptos, el alojamiento Odoo.sh, la implementación y el mantenimiento de código personalizado. No compares ese precio aislado con una propuesta que sí incluya esos trabajos. Alcance de los planes de Odoo.
5. Decide qué candidato puede avanzar
Al cerrar la evaluación, cada indispensable debería tener resultado, evidencia y responsable. Si está parcial o pendiente, identifica qué falta y qué decisión impide tomar. Si no está cubierto, descarta esa combinación para el alcance definido o cambia conscientemente el requisito con quienes operan el proceso.
No compenses un indispensable sin cubrir con una puntuación alta en funciones deseables ni cambies su criticidad sólo para favorecer una propuesta.
Entre los candidatos que sí superen ese filtro, compara los deseables, el alcance económico y las responsabilidades de mantenimiento. Deja en la propuesta los supuestos, exclusiones y riesgos que aceptas. La elección debe permitir explicar por qué el sistema sirve para tu operación, no sólo por qué gustó durante la presentación.
Si no hay responsable interno ni datos mínimos para validar, resuelve esa preparación antes de comprometer la implantación. Si la integración o el mantenimiento supera los recursos aceptables, revisa el alcance o una alternativa, aunque la licencia resulte atractiva.
Nébula trabaja con Odoo. Si esa opción supera tu filtro de requisitos, la información de implementación de Odoo para empresas permite conocer ese servicio; no constituye una selección independiente de proveedores.
Después de seleccionar, toca organizar el proyecto. Las fases de implementación de Odoo ayudan a revisar esa siguiente etapa.
Cuéntanos qué procesos necesitas resolver. Comparte tus procesos prioritarios y los sistemas que utilizas para conversar sobre el alcance de tu proyecto.