Actualizado el .
Un proyecto ERP necesita algo más concreto que una lista de módulos: un acuerdo sobre cómo debe trabajar el equipo. Antes de desarrollar, documenta los procesos, quién decide, qué sistema mantiene cada dato y cómo se demostrará que la primera entrega funciona.
Esta guía propone una ficha de trabajo para empresas que necesitan ordenar pedidos, inventario, compras o aprobaciones. El ejemplo de distribución que sigue es ilustrativo; no describe resultados de un cliente.
1. Define el problema y sigue una operación completa
Empieza con una frase verificable: «El equipo registra el mismo pedido en la tienda y en una hoja de cálculo, y necesita conciliar las diferencias antes de preparar el envío». Después recorre una operación desde la entrada hasta su cierre con las personas que la ejecutan.
Anota pasos, esperas, herramientas y decisiones. Distingue el proceso actual del que se quiere implantar. La guía de Microsoft sobre procesos empresariales recomienda relacionar requisitos y objetivos, comparar el flujo actual con el deseado e identificar qué cubre la solución estándar. El principio es útil también al evaluar un ERP a medida.
Registra una referencia inicial: pedidos que requieren corrección, tiempo dedicado a conciliarlos y responsable de medirlo. Así podrás evaluar el cambio con tus propios datos, sin asumir un ahorro antes de probarlo.
2. Completa un inventario de procesos
Usa una fila por proceso. Sustituye los ejemplos por operaciones reales y muestras anonimizadas. En móvil, desplaza la tabla horizontalmente para ver todas las columnas.
| Proceso y entrada | Responsable | Datos y origen | Salida y excepción |
|---|---|---|---|
| Pedido confirmado en la tienda | Ventas valida; operaciones tramita | ID de pedido, cliente, SKU y cantidad; tienda | Pedido registrado una sola vez; SKU desconocido pasa a revisión |
| Reserva y preparación | Almacén | Existencia, ubicación y reservas; sistema de inventario acordado | Reserva confirmada; falta de stock requiere una decisión |
| Solicitud de compra | Compras propone; responsable autorizado aprueba | Proveedor, artículo, precio y límite de aprobación; catálogo y reglas internas | Compra aprobada; exceso del límite sigue una aprobación adicional |
| Devolución recibida | Atención al cliente y almacén | Pedido original, unidades y estado del producto; registro de devolución | Ajuste trazable; material dañado no vuelve automáticamente a stock vendible |
Para cada fila, añade volumen habitual y máximo, frecuencia, plazo operativo, sistema de destino y criterio de cierre. Una captura de pantalla ayuda a explicar una tarea; no sustituye la regla de negocio.
3. Asigna decisiones y responsabilidad sobre los datos
Una misma persona puede asumir varios papeles en un equipo pequeño, pero cada decisión debe tener un responsable identificado:
- Responsable del proceso: valida el recorrido, sus excepciones y el resultado esperado.
- Responsable de los datos: decide qué registro prevalece y aprueba correcciones e importaciones.
- Usuarios operativos: prueban pedidos, reservas y devoluciones con los permisos que tendrán al trabajar.
- Responsable técnico: define conexiones, accesos, registros de errores y recuperación.
- Responsable del proyecto: aprueba prioridades y cambios de alcance, con sus efectos sobre coste y calendario.
Para clientes, productos, proveedores y existencias, fija una fuente de referencia. Si dos sistemas modifican el mismo campo, documenta quién puede hacerlo y cómo se resuelve un conflicto. La lista de gestión de datos de Microsoft incluye responsables, reglas para datos maestros y evaluación de calidad.
Prepara una correspondencia de campos: origen, destino, formato, identificador, obligatoriedad y tratamiento de errores. Por ejemplo, el código de artículo de la tienda debe corresponder con un SKU del ERP; una cantidad vacía debe revisarse según la regla acordada, sin convertirse silenciosamente en cero.
Antes de migrar, decide qué históricos hacen falta, depura duplicados y ensaya una carga. Compara registros e importes o cantidades pertinentes; conserva un registro de rechazos y quién los corrige. La lista de comprobación para migrar el inventario al ERP detalla identificadores, conciliación y validación de existencias.
4. Delimita una primera entrega que pueda operar
En el ejemplo, una primera versión podría recibir pedidos, validar artículos, reservar existencias y mostrar incidencias. Debe incluir los permisos, las excepciones críticas y la trazabilidad necesarios para utilizar ese recorrido.
Deja expresamente fuera, si no son necesarios para operar, los paneles personalizados, nuevas filiales o la migración de históricos antiguos. Indica también qué sistema seguirá gestionando facturación u otras funciones que no se sustituyen. «Fuera de alcance» necesita una alternativa operativa y un responsable.
Valora primero si basta configurar el sistema existente, si conviene conectarlo o si hay una necesidad real de desarrollo. Nuestro servicio de desarrollo de ERP a medida e integración de sistemas parte de procesos, módulos y datos definidos. Cada petición nueva debe quedar registrada con su prioridad, dependencia y efecto en la entrega.
5. Diseña las conexiones y sus excepciones
Una conexión entre tienda y ERP necesita un origen, un destino, un momento de actualización y una regla de confirmación. Revisa qué permite realmente cada proveedor. La integración de API para sitios web, ERP y aplicaciones debe contemplar estos casos desde el diseño:
- Pedido repetido: reconocer el identificador de origen para evitar crear dos pedidos al recibir el mismo evento.
- SKU desconocido o dato incompleto: registrar la incidencia y enviarla a la persona responsable.
- Servicio no disponible: acordar espera, reintentos y aviso; comprobar el resultado anterior antes de repetir una operación que modifica datos.
- Cancelación o devolución: definir quién autoriza el cambio y cómo afecta a reservas, existencias y sistemas relacionados.
- Diferencias entre sistemas: conciliar periódicamente y registrar la resolución, sin sobrescribir datos por defecto.
Si después quieres añadir clasificación o extracción con IA, primero establece este recorrido y su revisión humana. Puedes continuar con nuestra guía sobre cómo convertir una tarea repetitiva en un flujo útil con IA.
6. Acuerda criterios de aceptación antes de desarrollar
Cada requisito necesita una prueba observable. Escribe el escenario, los datos de partida, el resultado esperado, la persona que valida y la evidencia que conservará. La guía de pruebas de Microsoft propone definir alcance, criterios de entrada y salida, seguimiento de incidencias y aceptación de la solución.
Ejemplo: dado un pedido confirmado con dos artículos conocidos y existencias suficientes, al recibirlo dos veces el ERP mantiene un único pedido vinculado al ID de origen y una única reserva por la cantidad acordada. El usuario de operaciones comprueba el resultado y registra la evidencia.
- Probar el recorrido completo y repetirlo con datos incompletos, stock insuficiente y una devolución.
- Verificar que cada perfil puede ejecutar solo las acciones acordadas.
- Conciliar una muestra migrada y los totales definidos con el responsable de los datos.
- Simular una interrupción de la conexión y comprobar recuperación y avisos.
- Registrar incidencias con responsable, prioridad y condición de cierre; acordar cuáles bloquean la puesta en marcha.
Antes del cambio, confirma formación, soporte, ventana de transición y plan de retorno. Decide cómo se tratarán las operaciones realizadas durante la transición si hay que volver al sistema anterior. Usa la lista de pruebas de aceptación del ERP (UAT) para concretar escenarios, evidencias y responsables.
Preguntas frecuentes sobre un proyecto ERP
¿Qué documentos necesito para pedir una propuesta?
Un inventario de procesos, sistemas actuales, muestra anonimizada de datos, roles, alcance inicial y criterios de aceptación. Señala las dudas pendientes; no hace falta resolverlas todas antes de la primera conversación.
¿Hay que sustituir todos los sistemas?
No necesariamente. Puede mantenerse una herramienta y conectarla si cubre su función. La decisión depende de los problemas observados, sus interfaces y el coste de mantener la operación conjunta.
¿Cuánto cuesta y cuánto tarda?
No hay una cifra útil sin revisar procesos, usuarios, datos, conexiones y pruebas. Una propuesta debe explicar entregables, supuestos, exclusiones y dependencias, incluida la disponibilidad de tu equipo para validar.
¿Qué ocurre si aparecen nuevos requisitos?
Regístralos y revisa su impacto antes de incluirlos. Si son imprescindibles, reajusta el alcance o la planificación; si pueden esperar, asígnales una fase posterior.