Cuándo una pantalla no debe vivir dentro del ERP

Hay una escena que se repite en casi cualquier planta. Alguien de pie frente a una mesa, con guantes puestos, termina una orden de fabricación y tiene que reportar tres datos: cuánto salió, cuánto se echó a perder y una nota. Para eso abre el ERP en una tablet compartida, navega hasta la orden, encuentra el campo, lo captura y valida.

Tres datos. Catorce toques de pantalla.

La conclusión fácil es que el ERP está mal diseñado. No lo está. Un ERP está diseñado para la persona que necesita verlo todo —la que planea, la que costea, la que audita— y para esa persona cada campo en pantalla es información útil. El problema no es el diseño: es que le estamos pidiendo a una herramienta que sirva a dos usuarios con necesidades opuestas.

Este artículo es sobre cómo decidir cuándo separarlos, y —más importante— cuándo no.

Las cuatro preguntas

Antes de dibujar nada, conviene contestar cuatro cosas sobre la persona que va a usar la pantalla. No sobre el proceso: sobre la persona.

1. ¿Cuántos campos toca al día, de cuántos que ve?

Es la pregunta que más rápido resuelve la discusión. Cuenta los campos que esa persona modifica y divídelos entre los que tiene enfrente.

Un comprador toca veinte campos de treinta: la vista completa le sirve. Un operador de línea toca dos de sesenta. Ese cociente —dos entre sesenta— es la medida real de cuánto ruido le estás pidiendo que filtre, ocho horas al día, con prisa.

Cuando el cociente baja de uno a diez, la pantalla ya no es una herramienta para esa persona. Es un obstáculo que aprendió a sortear.

2. ¿Cuánta gente, y con qué acceso?

Aquí entra un dato que suele decidir el proyecto entero: cuántas de esas personas necesitan una cuenta del ERP y cuántas no deberían tenerla nunca.

Un jefe de almacén sí: consulta, corrige, decide. Cuarenta operadores de piso que sólo reportan avance, no — no por el costo, que también, sino porque cada cuenta es una superficie más donde algo se puede tocar por error.

Y hay un caso todavía más claro: la gente que no trabaja en tu empresa. Un distribuidor que va a levantar su pedido, un proveedor que va a consultar una orden de compra. Esa persona nunca va a tener una cuenta de tu ERP, y no es una limitación técnica: es que no debe tenerla.

3. ¿En qué aparato y en qué postura?

La palabra clave es postura, no dispositivo. No es lo mismo:

• Sentado frente a una computadora, con teclado y mouse y sin prisa.
• De pie frente a una mesa, con guantes, con un lector en la mano y una fila de cajas esperando.
• En el teléfono propio, de alguien que no es empleado tuyo, con la conexión que haya.

Un ERP está pensado para la primera. Las otras dos piden botones grandes, pocos pasos y una pantalla que no cambie de lugar entre una captura y la siguiente.

4. ¿Qué pasa si se equivoca?

La última pregunta es de radio de daño. Si esa persona teclea mal un número, ¿qué se rompe? Si la respuesta es «una cantidad producida que se corrige después», el riesgo es bajo. Si es «se validó una transferencia que movió inventario en tres almacenes», el riesgo es que le diste demasiada pantalla a alguien que sólo quería reportar.

Restringir por permisos resuelve parte. Pero un permiso quita el botón; no quita el ruido de los otros cincuenta campos.

La escalera, de abajo hacia arriba

Con esas cuatro respuestas, la decisión es una escalera. La regla es subir sólo un peldaño a la vez, y sólo cuando el anterior se quedó corto.

Peldaño 1 — Una vista propia. Una lista o un formulario con los campos que importan, un filtro por defecto y el resto escondido. Se hace con Studio, sin programar, y resuelve la mayoría de los casos que la gente plantea como «necesito una app». Empieza siempre aquí.

Peldaño 2 — Una vista con una acción. Lo mismo, más un botón que hace el paso completo en una operación: capturar la cantidad y validar, en lugar de capturar, guardar, buscar el botón y validar. Studio admite código en acciones de servidor, así que el botón puede hacer bastante más de lo que la gente supone.

Peldaño 3 — El portal. Odoo trae un portal para gente de fuera: clientes y proveedores que consultan sus documentos sin ser usuarios internos. Si lo que necesitas es que alguien externo vea lo suyo, este peldaño suele bastar y casi nadie lo intenta antes de saltar al siguiente.

Peldaño 4 — Una aplicación aparte que se conecta. Vive fuera del ERP, se comunica con él y presenta sólo el proceso. Es el peldaño que resuelve todo, y por eso es el que se elige demasiado pronto.

Lo que cuesta el peldaño cuatro

Aquí está la parte que rara vez se dice en una junta de venta, y que conviene decir antes de empezar y no después.

Una aplicación aparte es otro servidor que hay que pagar, monitorear y actualizar. Es otra puerta de acceso que administrar, con sus contraseñas y sus altas y bajas. Es una cosa más que se puede caer un martes a las diez de la mañana. Y no tiene modo sin conexión mágico: si el ERP no responde, la aplicación tampoco opera, porque la única fuente de verdad sigue siendo el ERP — y eso es una virtud, no un defecto, pero hay que saberlo de antemano.

Nada de eso es caro comparado con el problema que resuelve cuando el problema es real. Todo eso es carísimo cuando el problema se resolvía en el peldaño uno y nadie lo intentó.

La forma de equivocarse no es elegir mal el peldaño cuatro. Es no haber probado el uno.

Una prueba de dos minutos

Si la discusión se atora, hay una prueba que la destraba: siéntate a un lado de la persona y cuenta los toques.

No preguntes si le parece difícil —siempre dirá que ya se acostumbró—. Cuenta cuántos toques necesita para hacer lo que hace cincuenta veces al día, y cuántos de esos toques tienen que ver con el dato y cuántos con encontrar el dato.

Si de catorce toques, dos son la captura y doce son navegación, ya sabes de qué tamaño es el problema. Y si esa navegación se resuelve con un filtro por defecto, también sabes que no necesitas una aplicación.

Lo que no cambia al separarlas

Una advertencia que vale por todo el artículo: separar la pantalla no significa separar el dato.

La tentación, cuando ya tienes una aplicación aparte, es darle su propia base de datos «para que vaya rápido». En el momento en que existen dos lugares donde vive la misma información, existe la posibilidad de que difieran — y van a diferir. El día que difieran, nadie va a saber cuál de los dos tiene razón.

La aplicación presenta el proceso. El ERP sigue siendo el único que sabe.

Cómo lo resolvimos nosotros

Construimos tres aplicaciones sobre exactamente esta escalera, y cada una llegó al peldaño cuatro por una razón distinta.

El Portal Operativo subió por las preguntas 2 y 3: cuarenta operadores que sólo reportan avance, de pie y con guantes. El Portal B2B subió por la pregunta 2 en su forma más clara: son clientes, no empleados, y nunca van a ser usuarios del ERP. OneButtonPrint subió por la 1: en la mesa de empaque la razón entre lo que se toca y lo que se ve es de uno a muchos, y el ahorro está en los toques.

Ninguna de las tres se instala en Odoo. Viven fuera y se conectan, que es lo que las hace funcionar igual en Odoo Online, en Odoo.sh y en servidor propio.

Y en muchos otros proyectos la respuesta fue el peldaño uno: una vista con los campos correctos, hecha con Studio en una tarde. Ésos no tienen ficha en el catálogo, pero son la mayoría.

Si tienes un proceso donde alguien pelea con una pantalla todos los días, la conversación empieza contando los toques. Cuéntanos cuál es.