Arquitectura · Lo transversal

En 30 segundos

• Recibe nada de otra etapa y entrega «PE-T · Usuario con permisos y bitácora».
• 13 épicas, en el orden en que conviene construirlas: FT-PRD-01, FT-USR-01, FT-ARQ-01, FT-ARQ-02, FT-USR-02, FT-FLU-01, FT-RAC-07, FT-PRD-06, FT-RAC-05, FT-RAC-06, FT-RAC-08, FT-USR-03, FT-IA-06.

Cómo se pasan el producto

Las épicas

FT-PRD-01 · Modelo canónico de producto

Todo producto del PIM se guarda igual, venga de donde venga: una familia (genérico, individual, set o look) con sus variantes adentro, un tipo explícito, llaves que no se repiten (SKU inmutable y EAN único por negocio), relaciones de ida y vuelta y banderas con vigencia. Esta épica fija ese modelo y las APIs para crear, leer, ligar y comparar productos, para que el portal, Foro, SAP, la tienda y la migración vean la misma ficha.

FT-USR-01 · Identidad y autenticación de usuarios internos…

Hoy hay tres directorios que no se hablan (P360, Entrada Única y el inicio de sesión propio de Omega) y casi ningún servicio revisa quién llama. Esta épica deja una sola identidad: el proveedor de identidad de Entrada Única inicia la sesión, el BFF del portal la guarda y revisa el token en cada petición, cada módulo lo vuelve a revisar y MS-13, el directorio único, dice quién es cada persona o equipo, de qué negocio es y si está activo.

FT-ARQ-01 · Núcleo headless

El núcleo del PIM tiene una sola API de producto: los servicios de MS-02. Da igual si el alta llega de una pantalla, de un archivo, del sistema de un seller o de la migración: pasa por las mismas validaciones, nace igual en Borrador con su origen y sale una sola vez como evento. Las pantallas llegan a esa API por el BFF del portal y los sistemas de terceros por el gateway; ninguna de las dos puertas guarda datos ni decide reglas.

FT-ARQ-02 · Bitácora inmutable y versionado de producto, plantilla y…

Hoy P360 guarda 52 millones de renglones de bitácora sin el valor anterior ni el nuevo, y un repoblamiento sólo se pudo revertir de tres días. Esta épica hace de Auditoría (MS-05) la bitácora única: recibe los eventos de todos los módulos y guarda, por objeto y campo, el antes y el después, quién, cuándo, desde dónde y en qué ejecución, sin que nada se pueda cambiar ni borrar. Las versiones completas del producto las guarda Producto, para compararlas y restaurarlas.

FT-USR-02 · Matriz de roles y permisos por módulo, acción, negocio y…

Hoy cada sistema decide los permisos a su manera: el portal los tiene escritos en su código y casi ningún servicio los revisa. Esta épica carga como configuración la matriz de roles firmada por Seguridad y Gobierno de Producto. MS-13 guarda los roles, sus pantallas y quién tiene cada uno, con su negocio y sus secciones; cada módulo guarda qué puede hacer cada rol sobre sus datos y decide él mismo; el BFF arma el menú, y cada intento negado queda en la bitácora.

FT-FLU-01 · Motor de estados configurable con dos carreteras y reglas…

Es el motor que decide en qué momento de su vida está cada producto y quién tiene que hacer algo. Un solo flujo para Mercaderías, Suburbia y Marketplace: siete estados, catorce tipos de tarea y un estado por canal. Cada negocio cambia las reglas, no el camino, y el SKU se pide con lo mínimo mientras el enriquecimiento avanza aparte. Sólo el motor cambia estados; los demás módulos le informan hechos.

FT-RAC-07 · Reportes, exportes, importes y búsquedas por atributos

Los reportes del portal hoy piden los datos a P360 y se rompen al apagarlo; Gobierno de Producto lleva su lista de exportes en una hoja aparte, y contar productos por categoría tarda casi tres minutos por nivel. Esta épica hace de Reportes (MS-04) la salida de archivos del PIM: exportes de productos y categorías que se pueden reimportar, los reportes del portal, las herramientas de P360 y búsquedas con listas grandes, sin cargar la base que opera.

FT-PRD-06 · Bandeja de pendientes y depuración de borradores…

Al entrar al portal, cada persona ve en una sola bandeja lo que tiene pendiente: las altas que dejó a medias, con el paso en que se quedó, y las tareas que le tocan a ella o a su área, ordenadas por vencimiento. Los líderes reparten su cola sin pisarse, nadie pierde lo que hereda al cambiar de responsable y los borradores abandonados se depuran solos, con aviso antes y sin borrar su historia.

FT-RAC-05 · Estatus del producto y motivos visibles para seller y…

Hoy el seller y el proveedor dependen de alguien que les explique en qué va su producto, qué les falta o por qué se rechazó. Esta épica les da una vista propia: la etiqueta de su producto, en qué paso va, qué quedó a medias, los motivos de rechazo por campo y, por SKU, por qué no se creó o no se ve en la tienda. Producto la calcula con una sola tabla; el portal y la API de terceros sólo la muestran.

FT-RAC-06 · Métricas de tiempos por paso y clasificación de errores

Nadie sabe hoy dónde se atora un alta: no hay tiempos por paso, Compras aprueba sin ver y los errores no se clasifican por dónde se detectan. Esta épica hace que Reportes escuche los eventos del motor de estados, de SAP y de los canales, y guarde cuándo entra y sale cada producto de cada paso, cuántas veces vuelve y qué error tuvo. Con eso arma tarjetas de tiempos, de Compras, de errores y de publicación, donde «sin dato» nunca sale como cero.

FT-RAC-08 · Monitoreo de visibilidad y alertas de caída de SKUs…

El 23 de septiembre un seller pasó de 1,354 a 861 productos visibles y se enteró el negocio, no un sistema; las causas se buscaron a mano. Esta épica cuenta cada día, en productos, lo que se ve en la tienda por seller, por universo y del catálogo; lo compara con el día anterior y con una línea base; avisa sola cuando cae más del umbral, y deja bajar del seller a cada producto no visible con su causa.

FT-USR-03 · Control de acceso por API para terceros

Cuando un proveedor o seller catalogue por API, el PIM tiene que saber quién llama, poder cortarlo sin afectar a los demás y no dejar que lo cargue a sus anchas. Esta épica registra a cada tercero en MS-13 con sus negocios, tiendas, alcances y límites, le da credenciales propias en el proveedor de identidad, hace que el gateway de terceros revise cada llamada y su límite, y que Reportes mida el uso para avisar cuando cruce un umbral.

FT-IA-06 · Asistente conversacional para que el seller reporte errores

Un seller que oferta sobre un producto que ya existe no puede modificarlo, y hoy para reportar un error depende de su KAM. Esta épica le da un asistente: escribe en lenguaje natural qué ve mal (le falta una foto, un dato) o por qué su producto no avanza; el asistente lo entiende con el estatus y los motivos del PIM, le explica lo que pueda y le arma un reporte que el seller confirma y que llega como tarea a Gobierno de Datos.

Fuentes

1. [D] docs/arquitectura/por-epica/base/hilo.json: las etapas y los puntos de encuentro.
2. [D] docs/arquitectura/por-epica/epicas/: la arquitectura de cada épica.