El software a medida en España suele tener sentido cuando un proceso importante atraviesa herramientas que no se entienden bien. Un portal puede resultar elegante y seguir obligando a copiar datos entre CRM, ERP y correo. El objetivo debería ser reducir esa incertidumbre operativa, no añadir una nueva interfaz al mismo trabajo manual.
Consideremos una distribuidora con clientes profesionales. Quiere mostrar pedidos, documentación y disponibilidad en un portal. Sus comerciales usan un CRM y su almacén utiliza un ERP. Para contratar el desarrollo, necesita decidir qué información controla cada sistema y qué acciones pueden realizar los usuarios del portal.
Identifica el sistema responsable de cada dato
Escribe una tabla sencilla con cliente, producto, pedido, documento y estado de pago. Para cada elemento, identifica dónde se crea y quién puede cambiarlo. Establece identificadores que permitan relacionar los registros sin depender del nombre visible o de una búsqueda manual.
Solicita al proveedor de cada sistema sus posibilidades reales de integración. Una API disponible comercialmente puede exigir permisos, límites o contratación adicional. No apruebes un presupuesto construido sobre una conexión supuesta. Cuando una dependencia sea incierta, convierte su comprobación en una tarea temprana del proyecto.
Dibuja los permisos antes de terminar las pantallas
Un cliente puede tener varios compradores y diferentes establecimientos. Un comercial puede necesitar ver cierta información sin poder modificarla. Define esas reglas con responsables del negocio y comprueba que se aplican tanto a las consultas como a las acciones de escritura y descarga.
Una interfaz que oculta una opción no demuestra que el acceso esté protegido. Pide pruebas de solicitudes no autorizadas y de acceso a documentos de otra cuenta. Para datos personales y proveedores externos, utiliza las referencias de la AEPD durante la revisión con tus responsables de privacidad y contratación.
Diseña estados que operaciones pueda entender
Cuando el ERP no responde, el portal debe explicar si una acción está pendiente o ha fallado. Si un servicio repite una notificación, no debería aparecer un segundo pedido. Establece qué puede reintentarse automáticamente, qué necesita intervención y cómo se conserva la explicación de lo sucedido.
Pide una vista de incidencias con contexto suficiente para investigar, sin mostrar información innecesaria. Define quién puede corregir una asociación y cómo queda registrada esa acción. Esto evita que el soporte dependa de mensajes informales a una única persona del equipo de desarrollo.
Elige un piloto que atraviese la integración
Para la distribuidora, un piloto puede permitir que un cliente consulte un pedido y descargue su documento correspondiente. El recorrido debe utilizar el origen de datos acordado, aplicar permisos y representar una indisponibilidad temporal. Un conjunto de respuestas simuladas puede servir para diseño, pero debe identificarse como tal.
Solicita criterios de aceptación antes de comenzar. Incluye precisión de datos, comportamiento ante errores, acceso y documentación. No confundas la finalización de una API con el funcionamiento completo de la experiencia: la persona usuaria y la operación necesitan comprobar el resultado.
Prepara continuidad y evolución
El acuerdo debe identificar repositorios, entornos, credenciales bajo control del cliente y responsabilidades de mantenimiento. Aclara qué sucede cuando cambia la API del ERP o una nueva filial necesita permisos diferentes. Distingue corrección de defectos y ampliación de alcance.
Al pedir una propuesta a Brainbaby Labs u otro proveedor, aporta el proceso actual, un ejemplo preparado de los datos y el problema que más cuesta resolver. La conversación técnica será más útil que una lista extensa de funciones sin prioridades. Empieza por un recorrido que puedas evaluar y amplía el sistema cuando esa base esté demostrada.