Sincronización Bidireccional ERP-Ecommerce en Tiempo Real

¿Qué hace este flujo y qué problema resuelve?

Resumen ejecutivo: este flujo n8n implementa una sincronización bidireccional en tiempo real entre un ERP corporativo y una plataforma de comercio electrónico. Soluciona el desfase de inventario que provoca ventas pérdidas (overselling), pedidos no despachables y costosas devoluciones. El objetivo operativo es que el stock mostrado en la tienda online refleje el stock real del ERP en menos de 60 segundos y que todo pedido online quede automáticamente reservado en el ERP antes de confirmar la venta al cliente.

Problema concreto que resolvemos: cuando la tienda física y el comercio electrónico usan el mismo pool de inventario, las operaciones paralelas generan inconsistencias. Ejemplo: en ElectroNord S.A., una venta en tienda física dejaba al e-commerce con stock positivo durante varios minutos; como resultado, 12 pedidos mensuales se convertían en incidencias logísticas y reclamaciones.

Solución técnica: dos flujos complementarios desplegados en n8n.

• Flujo A (ERP → e-commerce): captura cambios de stock del ERP mediante webhook o polling de API, mapea SKU y actualiza la API del e-commerce con el nivel real ajustado por reglas de stock de seguridad.
• Flujo B (E-commerce → ERP): intercepta pedidos entrantes, valida disponibilidad aplicando reglas de stock de seguridad y crea una reserva temporal en el ERP antes de confirmar el pedido al cliente.

Resultados operativos previstos: reducción de overselling a cero en condiciones normales, disminución de reembolsos y quejas, visibilidad unificada del inventario para operaciones y atención al cliente.

Responsabilidades: el Director de Operaciones define las reglas de stock de seguridad; el equipo de IT implementa webhooks, nodos n8n y la tabla de mapeo SKU; el equipo comercial ajusta políticas de visibilidad de stock (p. ej., mostrar "bajo stock" antes de "agotado").

Ejemplo de impacto: ModaAlfa (cadena multicanal) redujo los pedidos no servidos de 9 a 1 por mes tras implementar los dos flujos y mantener una latencia media de 18 segundos entre evento ERP y actualización de la tienda online.

Cuándo usar este flujo

Prerrequisitos

Antes de implementar, confirme los siguientes prerrequisitos técnicos y de negocio. Fallar en cualquiera de ellos compromete la fiabilidad del sistema.

• ERP con webhook o API: El ERP debe exponer un webhook o endpoint API que notifique cambios de stock y eventos de recepción/envío/ajuste. Ejemplo: Odoo con webhook activado, SAP con middleware capaz de emitir HTTP POST. En ausencia de webhook usar polling de API con intervalos cortos y control de rate limit.
• Plataforma e-commerce con API de stock y pedidos: La tienda online (por ejemplo, Shopify, Magento, VTEX) debe permitir actualización de inventarios y creación/consulta de pedidos vía API.
• Tabla de mapeo SKU: Una tabla accesible desde n8n (base de datos PostgreSQL/MySQL o Google Sheet) que relacione identificadores del ERP y del e-commerce, con columnas: sku_erp, sku_store, unidad_medida, factor_conversion (si aplica), prioridad_ubicacion. Ejemplo concreto: tabla SKU_MAP de ElectroNord.
• Credenciales seguras: Almacenar en n8n las credenciales (API keys, Basic Auth, OAuth) con nombres claros: ERP_API_KEY, SHOP_HTTP_CRED. Nunca incrustar claves en nodos Function.
• Reglas de negocio definidas: Documento firmado por Operaciones que incluya stock mínimo por canal, comportamiento ante pedidos parciales, ventanas de reserva (p. ej., 30 minutos para confirmar pago), y SLA de respuesta para clientes.
• Monitoreo y alertas: Sistema de logs y alertas (emails, Slack o Microsoft Teams) para fallos críticos: webhook no recibido, error API 5xx, mismatch de mapeo de SKU.

Checklist técnico:

• Endpoint n8n (Webhook) público o en VPN para ERP.
• Credenciales de API para plataforma e-commerce almacenadas en n8n.
• Acceso de lectura/escritura a la tabla de mapeo desde n8n.
• Plan de pruebas con SKUs de control y entornos staging.

Ejemplo de prerrequisito completado: en ModaAlfa, el equipo IT creó la tabla SKU_MAP en PostgreSQL, configuró un webhook en Odoo que envía payload JSON y registró las credenciales SHOPIFY_API en n8n. Validaron con 50 eventos de prueba antes de producir.

Definición de reglas de stock de seguridad

Explicación detallada: antes de cualquier implementación técnica, la dirección debe establecer reglas que determinen cuánto stock se considera disponible para el canal online tras ajustarlo por la operación física. Estas reglas deben cubrir mínimos permitidos, excepciones por producto (por ejemplo, productos en promoción o con demanda alta), y prioridades de ubicación (almacén central vs tienda física). Sin reglas claras, la sincronización puede reducir ventas físicas o generar escasez en tienda.

Elementos mínimos a definir:

• Stock mínimo operativo (SMO): cantidad que siempre se reserva para ventas en tienda y consumo interno. Ej: SMO = 10 unidades para el SKU "EF-200" en ElectroNord.
• Umbral de alerta: nivel que dispara notificaciones a operaciones (p. ej., 15 unidades).
• Ventana de reserva para pedidos online: tiempo que una unidad queda reservada en el ERP mientras se confirma pago o recoge el pedido (p. ej., 30 minutos).
• Política de agotado vs bajo stock: en qué momento la tienda debe mostrar "bajo stock" y cuándo "agotado"; esto impacta conversión.

Consideraciones de negocio:

• Impacto en conversión: aumentar SMO reduce stock visible online; evaluar efecto en ventas antes de elevar SMO para un catálogo completo.
• Productos críticos: para SKUs con alta rotación o gran margen, considerar reglas dinámicas basadas en Forecast (p. ej., mantener SMO 20% de forecast semanal).
• Reconciliación periódica: establecer procesos diarios/semana- l es para revisar parámetros y ajustar SMO según tendencias estacionales.

Configuración n8n relacionada: se recomienda centralizar las reglas en una tabla RULES o en un nodo Set/Function que lea parámetros desde la base de datos.

Ejemplo de nodo n8n para obtener regla de producto:

Nodo: PostgreSQL (Read) - Nombre: Get_Product_Rule
Query: SELECT smp.sku_erp, r.smo, r.alert_threshold, r.reserve_window FROM sku_map smp JOIN product_rules r ON smp.sku_erp = r.sku_erp WHERE smp.sku_store = {{$json["sku_store"]}};

Configuración detallada del nodo:

• Host: [DB_HOST]
• Base de datos: [DB_NAME]
• Usuario: [DB_USER]
• Password: guardado en n8n Credentials: POSTGRES_OPS

Ejemplo operativo: para la empresa ficticia "MueblesNova", definieron SMO = 5 para muebles pequeños y SMO = 1 para consumibles. En la tabla product_rules se mantenían estos valores; el flujo A restaba SMO al stock real antes de publicar disponiblidad en la tienda.

Prompt listo para usar (definición de regla por producto):

Crear regla para [SKU_ERP] con SMO [NUM], umbral alerta [NUM] y ventana reserva [MINUTOS]

Flujo A: ERP actualiza el e-commerce

Explicación detallada del paso: este flujo toma eventos de cambio de inventario desde el ERP y actualiza la plataforma e-commerce. Debe garantizar idempotencia y tolerancia a fallos: si el mismo evento se procesa dos veces, el stock final debe ser correcto; si la API del e-commerce responde con error temporal, el evento se debe reintentar con backoff.

Secuencia de nodos n8n recomendada:

1. Webhook (n8n) - recibe POST del ERP
2. Function / Set - normaliza el payload (campos: sku_erp, location, qty, event_type)
3. PostgreSQL (Read) - mapea sku_erp → sku_store y obtiene reglas (smo, factor_conversion)
4. Function - calcula stock_publicable = max(0, qty_total - smo) y aplica factor_conversion
5. HTTP Request - actualiza la API del e-commerce con el stock_publicable
6. If - verifica respuesta; en fallo 5xx o timeout pone evento en cola (Redis o tabla retry) y notifica a Slack/email

Configuración de nodos con detalles:

• Webhook: Method=POST, Response Mode=On Received, Path=/erp-stock-webhook, Authentication=HMAC_HEADER con secret: [ERP_WEBHOOK_SECRET].
• Function (normalización): código que mapea el body entrante a {sku_erp, qty, location, timestamp}; ejemplo de expresión: const p = items[0].json; return [{json:{sku_erp: p.item_code, qty: Number(p.qty_on_hand), location: p.warehouse}}];
• PostgreSQL (Get SKU Map): Query parametrizada usando {{$json["sku_erp"]}}; ejemplo: SELECT sku_store, smo, factor_conversion FROM sku_map JOIN product_rules ON sku_map.sku_erp=product_rules.sku_erp WHERE sku_map.sku_erp = '{{$json["sku_erp"]}}';
• Function (cálculo): calcular qty_public = Math.max(0, qty - smo) * factor_conversion; el nodo debe agregar metadatos: source_event_id y event_timestamp.
• HTTP Request (Shopify/Magento API): Method=POST/PUT, URL=https://api.[TIENDA]/inventory_levels/set.json, Auth=Header Bearer {{$credentials.SHOP_TOKEN}}, Body Raw JSON: {"sku": "{{$json["sku_store"]}}", "available": {{$json["qty_public"]}}}.
• If (comprobación): condición: response.statusCode >= 500 OR response.body.error; si true: Set Retry with exponential delay y enviar alerta a Slack.

Consideraciones técnicas y de negocio:

• Idempotencia: adjuntar event_id del ERP y conciliar con tabla events_processed para ignorar duplicados.
• Consistencia eventual: documentar que entre la modificación en ERP y la disponibilidad visible en tienda hay una latencia esperada; medir SLA.
• Seguridad: validar HMAC del webhook y restringir IPs del ERP en el firewall del servidor n8n.
• Escalabilidad: para picos usar un topic en Redis/RabbitMQ para procesar eventos de forma asíncrona y con workers n8n escalables.

Ejemplo concreto: flujo en "ElectroNord S.A.": un webhook envía payload {"item_code":"EF-200","qty_on_hand":23,"warehouse":"CEN-01"}. El nodo PostgreSQL devuelve smo=3; el cálculo publica 20 unidades en la tienda. HTTP Request actualiza Shopify y el cliente web refleja 20 unidades en 12 segundos.

Prompt listo para el webhook del ERP (texto para IT):

Enviar evento POST a https://[N8N_HOST]/webhook/erp-stock-webhook con payload JSON: {"item_code":"[SKU_ERP]","qty_on_hand":[NUM],"warehouse":"[WAREHOUSE_CODE]","event_id":"[UUID]","timestamp":"[ISO_8601]"} y HMAC header X-Hub-Signature usando secret [ERP_WEBHOOK_SECRET]

Flujo B: pedido online reserva en ERP

Explicación detallada del paso: cuando llega un pedido online, antes de confirmar el pago y el envío al cliente, el flujo debe reservar las unidades correspondientes en el ERP para evitar overselling. La reserva puede ser temporal (hold) hasta que el pago se confirme o el plazo de reserva expire. El flujo también debe permitir liberaciones automáticas y manejo de pedidos parciales según la política comercial.

Secuencia de nodos n8n recomendada:

1. Webhook/HTTP Request - recibir evento 'nuevo pedido' desde la plataforma e-commerce o poll de API si la tienda no emite webhooks.
2. Function/Set - extraer línea(s) de pedido, cantidades, SKU tienda y mapa a sku_erp.
3. PostgreSQL (Read) - obtener disponibilidad actual por ubicación y reglas (smo, min_alert).
4. Function - calcular si el pedido puede reservarse totalmente, parcialmente o debe rechazarse. Aplicar reserva_window definida en reglas.
5. HTTP Request - llamar API ERP para crear reserva (stock hold) por event_id/pedido_id; payload incluye sku_erp, qty_hold, expiry_timestamp, reason='E-COMMERCE_ORDER_[ORDER_ID]'.
6. If - verificar respuesta ERP. Si éxito: actualizar estado del pedido en e-commerce (reservado) y notificar al cliente; si fallo: anular o poner pedido en espera y notificar a operaciones.

Configuración específica de nodos:

• Webhook (Shopify Orders): Path=/shop-orders-webhook, Method=POST, Auth: HMAC using [SHOP_WEBHOOK_SECRET], Response Mode=On Received.
• Function (Map Order): extraer items: items = {{$json["line_items"]}}; mapear usando consulta a PostgreSQL para obtener sku_erp con {{$item.json["sku"]}}.
• PostgreSQL (Check Availability): Query parametrizada: SELECT SUM(qty) as on_hand FROM inventory WHERE sku_erp='{{$json["sku_erp"]}}' AND location IN ([PRIORITY_LOCATIONS]);
• HTTP Request (ERP Reserve): Method=POST, URL=https://api.[ERP]/reservations, Headers Authorization: Bearer {{$credentials.ERP_API_KEY}}, Body JSON: {"sku":"{{$json["sku_erp"]}}","qty":{{$json["qty_hold"]}},"expires_at":"{{$json["expiry"]}}","reference":"ECOM-{{$json["order_id"]}}"}.
• Set/HTTP Request (Update Store): PUT https://api.[TIENDA]/orders/{{$json["order_id"]}}/notes Body: {"status":"reserved","reservation_expires":"{{$json["expiry"]}}"}.

Consideraciones técnicas y de negocio:

• Reserva temporal vs permanente: definir duración de hold. Ejemplo: 30 minutos para pagos con tarjeta, 24 horas para transferencias bancarias.
• Pedidos parciales: si no hay stock suficiente para todos los ítems, decidir si reservar parcialmente (y notificar al cliente) o marcar como pendiente. La política debe estar definida en la fase de reglas.
• Operaciones offline: si la API ERP falla, poner el pedido en cola y marcar como "pendiente de reserva"; no confirmar al cliente hasta garantizar la reserva.
• Auditoría: registrar reservation_id, pedido_id y event_id en tabla reservations para reconciliaciones diarias.

Ejemplo concreto con datos ficticios: Cliente "HomeGear Ltd." recibe pedido #HG-2026 con dos líneas: SKU tienda TG-55 (2 unidades) y SKU tienda TG-72 (1 unidad). Mapeo devuelve sku_erp HG-TG55 y HG-TG72. Postgres indica on_hand: HG-TG55=5 (smo=1) → disponible para reservar 4 unidades; HG-TG72=0 → no disponible. El flujo reserva 2 unidades de HG-TG55 y marca la línea TG-72 como "backorder"; se envía actualización al cliente y al equipo de operaciones para preparación de abastecimiento.

Prompt listo para integración de pedidos (para equipo IT o tienda):

Al recibir pedido, enviar POST a https://[N8N_HOST]/webhook/shop-orders-webhook con payload completo del pedido JSON y header X-Shop-Signature: [SHOP_SECRET]

Alertas de stock crítico

Explicación detallada: las alertas de stock crítico son un mecanismo proactivo que notifica a operaciones y compras cuando el nivel real o publicable de un SKU cae por debajo de un umbral definido. Estas alertas permiten reabastecer a tiempo y evitar roturas de stock.

Tipos de alertas recomendadas:

• Alerta de reposición inmediata: cuando stock_publicable < reorder_point (ej. reorder_point = lead_time * avg_daily_sales + safety_stock).
• Alerta de agotado inminente: cuando stock_real ≤ SMO + margen de error.
• Alerta por discrepancia: cuando el stock reportado por ERP y el stock calculado por el e-commerce difieren más que un umbral (ej., >5 unidades o >10% de la cantidad).

Configuración n8n para alertas:

1. Scheduler (Cron) - nodo que corre cada 15 minutos o según SLA.
2. PostgreSQL (Query) - obtiene SKUs cuyo stock_publicable ≤ alert_threshold.
3. Function - formatea el mensaje de alerta con links a dashboard y prioridad.
4. Notifiers - nodos para enviar alerta por correo, Slack y crear ticket en el sistema de incidencias (Jira/ServiceNow).

Ejemplo de nodo Cron: Cron Trigger: Minute Interval = 15. Query de ejemplo:

SELECT sku_store, sku_erp, qty_publicable, alert_threshold FROM inventory_publicable WHERE qty_publicable <= alert_threshold;

Contenido del mensaje recomendado (ejemplo para Slack):

ALERTA: SKU [SKU_STORE] (ERP: [SKU_ERP]) tiene stock publicable [QTY_PUBLICABLE] ≤ umbral [ALERT_THRESHOLD]. Acción recomendada: validar stock físico y emitir OC si procede. Link: [DASHBOARD_SKU]

Consideraciones operativas:

• Prioridad: clasificar alertas por criticidad de SKU (alto, medio, bajo) para no sobrecargar a compras con notificaciones de baja prioridad.
• Frecuencia: evitar alertas repetidas para la misma incidencia; usar suppression window (ej. no enviar la misma alerta más de 1 vez por 4 horas).
• Integración con KPIs: ligar alertas a indicadores de cumplimiento OTIF y fill rate para medir impacto en la cadena de suministro.

Ejemplo concreto: en "ModaAlfa", la alerta de reposición envía un correo al buyer responsable con subject "URGENTE - Reabastecer SKU MA-PLUSH-01 - 8 unidades" y genera ticket en Jira con prioridad P2. Gracias al proceso, el tiempo de reabastecimiento se redujo de 10 a 5 días promedio.

Output esperado del flujo

Descripción del output: tras la ejecución correcta de ambos flujos, los sistemas deben reflejar las siguientes condiciones operativas y datos trazables.

Resultados esperados a nivel funcional:

• Stock publicado en el e-commerce igual al stock real del ERP menos SMO, actualizado en menos de 60 segundos tras evento ERP.
• Pedidos online reciben una reserva en el ERP (reservation_id) antes de confirmarse al cliente.
• Logs y tabla events_processed con registro de event_id, tipo de evento, estado (processed, retried, failed) y timestamp para auditoría.

Ejemplo concreto de output (registro en tabla events_processed y respuesta API):

{
  "event_id": "e7f3b2a4-9c1d-4d2a-8b12-abcdef123456",
  "source": "ERP_CEN01",
  "type": "stock_update",
  "sku_erp": "EF-200",
  "sku_store": "ELEC-EF200",
  "qty_erp": 23,
  "smo": 3,
  "qty_publicable": 20,
  "store_update_status": "success",
  "store_update_timestamp": "2026-07-15T10:22:18Z"
}

Ejemplo de output de una reserva de pedido:

{
  "order_id": "HG-2026",
  "reservation_id": "RES-20260715-00091",
  "sku_erp": "HG-TG55",
  "qty_reserved": 2,
  "expiry": "2026-07-15T10:52:18Z",
  "erp_status": "reserved",
  "store_status": "reserved"
}

Métricas que debe reportar el sistema tras la puesta en producción:

• Latencia media ERP → e-commerce (segundos).
• Tasa de fallos HTTP a e-commerce y ERP (5xx y 4xx).
• Número de reservas creadas / liberadas por día.
• Incidencias de overselling mensuales (debe tender a 0).

Procedimiento de verificación: ejecutar 100 eventos de prueba (mix de ventas físicas y pedidos online), comprobar que los registros events_processed suman 100 y que las discrepancias son 0 o dentro del umbral acordado.

Problemas frecuentes y cómo resolverlos

Se listan los errores más frecuentes con síntoma, causa probable y acciones correctivas. Esta sección es fundamental para el equipo de soporte y operaciones.

• Error 1 - Webhook no recibido
  • Síntoma: no hay eventos entrantes en n8n; la tabla events_processed no registra actividad.
  • Causa probable: webhook endpoint inaccesible (DNS, firewall), secret HMAC incorrecto o el ERP no envía eventos.
  • Solución: comprobar disponibilidad pública del endpoint (curl desde ERP), validar HMAC usando secret en ERP y n8n; revisar logs del ERP; si necesario, solicitar a IT que permita la IP del ERP o crear VPN/NGROK para pruebas.
• Error 2 - Duplicado de eventos / sobrescritura de stock
  • Síntoma: el stock publicado fluctúa erráticamente o se procesan eventos repetidos.
  • Causa probable: el ERP reintenta sin idempotencia o no hay control de event_id.
  • Solución: implementar registro de event_id en events_processed y comprobar antes de procesar; usar un nodo Function para validar event_id y descartar duplicados; añadir respuesta 2xx rápida desde n8n al ERP para evitar reintentos innecesarios.
• Error 3 - Fallos al actualizar la API del e-commerce (5xx)
  • Síntoma: HTTP Request devuelve 500/502 y stock no se actualiza.
  • Causa probable: saturación de la API, cambios en autenticación, payload no válido.
  • Solución: activar reintentos con backoff exponencial en n8n; validar esquema JSON; revisar credenciales y permisos; aplicar throttling en n8n para evitar superar límites de la tienda; habilitar alertas cuando tasa de 5xx supere umbral.
• Error 4 - Reserva en ERP fallida
  • Síntoma: pedido marcado como reservado en tienda pero sin reservation_id en ERP.
  • Causa probable: API del ERP rechaza petición por falta de stock real, o formato de reserva incorrecto.
  • Solución: cuando ERP devuelve rechazo, revertir estado en tienda a "pendiente" y notificar al cliente; registrar motivos de rechazo en tabla reservations_error; coordinar con operaciones para validar stock físico y ajustar SMO o procesos de picking.
• Error 5 - Mismatch en mapeo SKU
  • Síntoma: al procesar pedido o stock update, no existe mapeo para el SKU y el flujo falla o actualiza SKU incorrecto.
  • Causa probable: tabla SKU_MAP incompleta o discrepancias en nomenclatura.
  • Solución: crear proceso de fallback que notifique automáticamente a IT y operaciones cuando no se encuentre mapeo; permitir un modo "manual override" desde interfaz donde un operador pueda asignar el mapeo y reintentar el evento; revisar y auditar importaciones de catálogo entre sistemas.

Recomendaciones operativas generales:

• Implementar retiros automáticos y circuitos de notificación para evitar confirmaciones erróneas a clientes.
• Mantener runbook con pasos para recuperación rápida: 1) pausar ingest de webhooks, 2) revisar tabla retry, 3) ejecutar reconciliación offline, 4) liberar colas.
• Pruebas periódicas: simular fallos de API, duplicados y picos de eventos para validar resiliencia.

Adaptaciones del flujo para otros contextos

El diseño base puede adaptarse a distintos modelos de negocio. A continuación, variantes operativas con cambios técnicos y ejemplos prácticos.

• Modelo marketplace multivendedor: En plataformas donde el inventario pertenece a vendedores distintos, centralizar la tabla de mapeo por seller_id y añadir validaciones legales. En n8n: añadir nodo HTTP Request para consultar disponibilidad del seller antes de crear la reserva en ERP central. Ejemplo: Marketplace "MercatoPlus" integra SKU_map con seller_id y ejecuta reservas condicionadas.
• Inventario distribuido por ubicación (fulfillment por tienda): Si el almacén que sirve un pedido depende de la proximidad, el flujo debe seleccionar ubicación óptima según prioridades. En n8n: ampliar la consulta PostgreSQL para devolver un ranking de ubicaciones y modificar el HTTP Request a ERP con location_id. Ejemplo: "ClickCollect Co." usa prioridad: tienda local > centro de distribución.
• Canal B2B con pedidos por catálogo y contratos: Para clientes con condiciones especiales, añadir tabla contract_rules que modifique SMO y ventanas de reserva por cuenta. En n8n: antes de reservar, checkear contract_rules por customer_id y aplicar condiciones.
• Operación offline o sin API de ERP: Si el ERP no tiene API, usar un adaptador de base de datos (lectura directa) o un middleware que exporte eventos por FTP/CSV procesados por n8n. Consideraciones: mayor latencia y menor seguridad; añadir reconciliación diaria.
• Alta variabilidad estacional: Para picos (Black Friday), activar un modo degradado que reduzca la frecuencia de actualizaciones no críticas y priorice reservas de pedidos confirmados. En n8n: ajustar cron y usar variables de entorno MODE=peak para cambiar comportamiento de nodos.

Ejemplo práctico - variante por ubicación: la cadena ficticia "HouseStyle" utiliza algoritmo de asignación: si stock_local >= qty → asignar tienda; sino asignar DC. En n8n, el nodo Function implementa la regla y el HTTP Request llama al ERP con location_id adecuado.

Consideración de coste vs beneficio: cada variante añade complejidad y costes de desarrollo; priorizar según impacto en ventas y número de SKUs afectados.

¿Qué hacer ahora?

Pasos ejecutivos inmediatos:

1. Validar y firmar las reglas de stock de seguridad (Documentar SMO, ventanas de reserva y políticas de parcialidad). Responsable: Director de Operaciones.
2. Preparar entorno técnico: habilitar webhook en ERP y credenciales API de la tienda; crear tabla SKU_MAP y product_rules en la base de datos. Responsable: IT.
3. Implementar prototipo en staging: desplegar dos flujos en n8n y ejecutar pruebas con 50 eventos de control. Responsable: Equipo de Integración.
4. Definir runbook de incidentes y métricas a monitorizar (latencia, tasa de errores, overselling). Responsable: Soporte/Operaciones.
5. Plan de despliegue a producción en ventana de baja actividad y con monitorización en tiempo real. Responsable: IT y Operaciones.

Prompt ejecutivo para iniciar el proyecto (email para IT y Operaciones):

Asunto: Inicio proyecto sincronización ERP–Ecommerce

Equipo,

Iniciamos el proyecto "Sincronización Bidireccional ERP–Ecommerce". Requisitos iniciales: 1) Validación de reglas SMO por producto (Operaciones). 2) Credenciales API / Webhooks activas (IT). 3) Tabla SKU_MAP disponible en Postgres (IT). Plazo: pruebas en staging en 10 días. Acción: confirmar disponibilidad y recursos.

Atte,
[TU_NOMBRE] - Director de Operaciones

Contacto y seguimiento: agendar reunión de 30 minutos entre Operaciones e IT para el día 3 del proyecto y establecer checkpoints diarios durante la fase de pruebas.