La pregunta más frecuente que nos hacen los Heads of Ops en el primer diagnóstico es la misma: *"Tenemos como treinta procesos candidatos. ¿Por dónde empezamos?"*
La respuesta más común que escuchan en otros lugares es subjetiva: empieza por el que más duela, por el que tenga mejor ROI estimado, por el que el CEO quiere ver primero. Cada criterio es válido y al mismo tiempo insuficiente — porque todos dependen de un juicio que cambia según quién esté en la sala.
Después de 200+ diagnósticos en retail, eCommerce y logística en Chile, México y Perú, descubrimos que esa pregunta tiene una respuesta más estructural. La priorización deja de ser política cuando puedes describir cada proceso con el mismo vocabulario.
Esto es lo que llamamos la taxonomía de procesos de Puente OS. Cinco dimensiones, cinco preguntas, una clasificación que convierte un mapa de operaciones caótico en una matriz comparable.
---
El insight que cambia la pregunta
Cuando llevas más de 200 reuniones mapeando operaciones reales, una verdad incómoda emerge: cerca del 80% de los procesos que las empresas describen como "únicos" son variaciones de los mismos patrones.
El equipo que describe su pesadilla de generar guías de despacho manualmente entre cinco couriers está describiendo el mismo patrón estructural que el equipo que sufre con la conciliación de comisiones de mil ochocientos puntos de retiro. Las herramientas son distintas. Los sistemas son distintos. La estructura del proceso es la misma.
Ese hallazgo cambia la pregunta de fondo. Pasa de *"¿qué automatizo primero?"* a *"¿qué patrón de proceso tengo entre manos, y cuál es el MVP probado para ese patrón?"*
Esa segunda pregunta sí tiene respuesta objetiva.
---
Las cinco dimensiones de cualquier proceso operativo
Todo proceso que se puede automatizar — sin excepción que hayamos encontrado en 200+ diagnósticos — se puede describir con cinco dimensiones. Las cinco preguntas son simples, y la conversación de discovery suele tomar quince minutos por proceso una vez que tu equipo internaliza el formato.
1. Input — ¿De dónde vienen los datos?
Siete patrones cubren prácticamente todos los casos: archivos Excel/Sheets cargados a mano, APIs de plataformas, web scraping, OCR de documentos físicos, mensajes de WhatsApp, webhooks en tiempo real, archivos batch FTP. Saber qué patrón aplica determina qué módulo técnico hay que activar y qué bloqueantes anticipar.
2. Transformación — ¿Qué se hace con esos datos?
También siete patrones: enriquecer con fuentes externas, calcular un score o ranking, filtrar y rutear según reglas, eliminar duplicados o reconciliar entre fuentes, agregar y consolidar, convertir entre formatos, o aplicar procesamiento con AI. Esta dimensión es la que más confusión genera al cliente — porque suelen describir la transformación con el lenguaje del problema ("el equipo revisa cada caso") en vez del lenguaje del patrón ("filtering por reglas").
3. Output — ¿Cómo se entrega el resultado?
Siete patrones de salida: un dashboard o app interna, un agente conversacional, un flujo de email automatizado, un PDF o reporte, una notificación de WhatsApp, una sincronización via API a otro sistema, o un trigger físico (impresión de guías, picking lists). El output define la experiencia del usuario final y suele ser donde el equipo de operaciones mide el éxito del proceso.
4. Integración — ¿Qué sistemas externos toca?
Siete categorías: eCommerce, CRM, courier/logística, financiero/contable, data warehouse, comunicación, document processing. Cada categoría tiene sus propios bloqueantes recurrentes — accesos, credenciales, rate limits, calidad de data — que ya tenemos mapeados de implementaciones anteriores.
5. Business Process — ¿Qué tipo de proceso de negocio es?
Aquí entran nueve arquetipos: gestión de órdenes, pricing intelligence, comunicación con clientes, gestión de catálogo, operaciones financieras, ventas/CRM, marketing automation, logística avanzada, e inventario. Esta es la dimensión más estratégica porque conecta el proceso con un MVP probado, un timeline base, y un pricing estimado.
Las primeras cuatro dimensiones son técnicas. La quinta es la que conecta el proceso con el negocio.
---
Por qué la taxonomía cambia la priorización
Una vez que tienes los treinta procesos clasificados con este formato, la priorización deja de ser una pelea de opiniones.
Tres criterios objetivos emergen automáticamente:
Patrón de implementación conocido versus patrón nuevo. Un proceso que cae limpio en un BP type ya implementado en otros clientes tiene un MVP probado, un timeline conocido, y bloqueantes anticipados. Un proceso que cruza varios BP types o que requiere una integración nueva merece más discovery antes de comprometerse.
Volumen e impacto del patrón I→T→O. El mismo patrón puede tener impacto radicalmente distinto según el volumen. Un proceso de generación de PDFs (O4) que corre cien veces al día es candidato fuerte; el mismo patrón corriendo cinco veces a la semana probablemente puede esperar.
Concentración de integraciones (C). Procesos que viven dentro de una sola categoría de integración (todo en eCommerce, todo en data warehouse) son más rápidos de implementar que procesos que cruzan tres o cuatro categorías. Los procesos críticos a veces son los más cruzados — y vale la pena hacerlos, sólo no como primera apuesta.
Con estos tres criterios, la conversación deja de ser *"¿este proceso o ese otro?"* y pasa a ser *"este proceso tiene un patrón probado, alto volumen y dos integraciones limpias — esa es la primera apuesta. Este otro tiene patrón probado pero cinco integraciones — segunda apuesta. Este otro requiere un patrón nuevo — discovery adicional."*
La política se vuelve análisis.
---
Los nueve tipos de proceso de negocio
Los nueve arquetipos cubren prácticamente todo lo que vemos en operaciones de retail, eCommerce y logística. En orden aproximado de frecuencia con la que aparecen como prioridad de primer Sprint:
Order Management (BP1). Ciclo de vida de órdenes: recepción multi-canal, ruteo a courier, generación de documentación, confirmación de fulfillment. Pain típico: horas diarias copiando datos entre sistemas. Suele ser el primer proceso por automatizar en eCommerce multicanal.
Pricing Intelligence (BP2). Monitoreo de precios de competidores y ajuste de estrategia comercial. Pain típico: revisión manual semanal con planillas de miles de filas. Alto ROI cuando el competitive landscape se mueve rápido.
Customer Communication (BP3). Agentes AI para soporte, ventas o cobranza. Pain típico: equipo dedicado a responder lo mismo una y otra vez. Alta visibilidad porque toca CX directamente.
Catalog Management (BP4). Sincronización de catálogo a múltiples canales de venta. Pain típico: una persona dedicada a carga manual, sólo una fracción del catálogo publicada. Crítico para empresas con presencia en marketplaces.
Financial Operations (BP5). Scoring crediticio, reconciliación financiera, retenciones fiscales. Pain típico: proceso manual propenso a errores con impacto financiero directo. Alto stakeholder buy-in del CFO.
Sales & CRM (BP6). Unificación de datos de clientes y gestión del funnel. Pain típico: datos fragmentados entre sistemas, sin vista única del cliente. Foundation para casi todo lo demás.
Marketing Automation (BP7). Flujos de email, lifecycle marketing, campañas. Pain típico: campañas manuales sin segmentación. Suele esperar hasta que CRM esté limpio.
Logistics (BP8). Multi-courier, tracking, reverse logistics, warehouse ops. Pain típico: selección manual de courier, devoluciones caóticas. Crítico para volúmenes altos.
Inventory (BP9). Stock sync, purchase orders, demand forecasting. Pain típico: quiebres de stock, sobre-stock, compras sin visibilidad. Suele ser un Sprint posterior una vez que el OMS está estable.
La frecuencia con la que un BP type aparece como prioridad de Sprint 1 dice algo sobre dónde están los pain points más agudos en operaciones de retail/eCommerce LatAm hoy. Order Management, Pricing Intelligence y Customer Communication suelen ganar.
---
Cómo se ve el ejercicio en una sesión real
El ejercicio toma una sesión de noventa minutos por área operacional, con dos a tres personas de tu equipo presentes — la persona que ejecuta el proceso, su jefe directo, y alguien de tecnología si hay integraciones complejas.
El formato es simple. Por cada proceso candidato:
- Una persona lo describe en un párrafo, en lenguaje natural, sin restricciones.
- Hacemos las cinco preguntas en orden, traduciendo la narrativa a códigos.
- Comparamos contra el mapa de procesos de clientes existentes para identificar los más similares.
- Asignamos un nivel de complejidad (S/M/L/XL) basado en el patrón identificado.
Al final de noventa minutos, una empresa típica tiene entre cinco y ocho procesos clasificados, con una recomendación clara de cuál es el candidato más fuerte para el primer Sprint.
La parte que sorprende al cliente es que la clasificación misma genera insights. Procesos que parecían distintos resultan ser el mismo patrón. Procesos que parecían simples resultan tener integraciones cruzadas que los hacen complejos. Procesos que parecían críticos resultan ser secundarios cuando se compara su volumen con los demás.
El output del ejercicio es una matriz: filas con los procesos, columnas con I/T/O/C/BP, una columna de complejidad estimada, y una columna de patrón cliente similar. Esa matriz es el insumo que lleva la decisión de priorización del comité a un documento.
---
Por qué importa que esto sea repetible
La razón por la que insistimos en una taxonomía formal — y no en el "criterio del consultor" — tiene que ver con qué tipo de relación queremos con el cliente.
Un consultor tradicional vende su intuición. Cada diagnóstico es único, cada recomendación es artesanal, y la calidad depende de quién esté del otro lado de la mesa. Eso funciona, pero no escala y no mejora con el tiempo.
Una taxonomía formal hace lo opuesto. Cada nuevo diagnóstico alimenta el mismo modelo. Los patrones se vuelven más finos. Los MVPs se vuelven más rápidos. Los bloqueantes se anticipan mejor. La empresa cliente número 50 recibe el aprendizaje destilado de las primeras 49, sin esfuerzo extra.
Para tu equipo, la diferencia se siente concreta. La conversación de priorización pasa de tres semanas de comités a noventa minutos de matriz. La decisión queda documentada en un formato comparable. Y cuando llegue el siguiente Sprint, la pregunta *"¿qué automatizo ahora?"* tiene un punto de partida más sólido que la última vez.
---
Empieza por mapear cinco procesos
Si quieres aplicar este formato sin esperar a un diagnóstico formal, agarra cinco procesos que tu equipo describiría como "los que más duelen" y respóndelos con las cinco preguntas:
- ¿De dónde vienen los datos? (archivo, API, scraping, WhatsApp, webhook, FTP)
- ¿Qué transformación se hace? (enriquecer, filtrar, calcular, deduplicar, agregar, convertir formato, AI)
- ¿Cómo se entrega el resultado? (dashboard, chatbot, email, PDF, WhatsApp, API, acción física)
- ¿Qué sistemas externos se conectan? (eCommerce, CRM, courier, financiero, BD, comunicación, documentos)
- ¿Qué tipo de proceso es? (órdenes, pricing, comunicación, catálogo, finanzas, CRM, marketing, logística, inventario)
Si los cinco caen en el mismo BP type, ya tienes una pista clara — ese es probablemente el área de mayor concentración de pain en tu operación. Si caen distribuidos, la priorización se vuelve un ejercicio de volumen y complejidad.
El modelo operativo de tu empresa se armó solo. Es momento de mapearlo y diseñarlo con un vocabulario común.