Curso de PDD (Process Driven Design) para Equipos de Arquitectura

Definir PDD como un enfoque de diseño que parte de procesos de negocio, flujos operativos y coordinación real entre actores.

Diferenciar PDD de BPM tradicional, análisis funcional clásico, product discovery, service design, RPA y automatización puntual.

Comprender que un proceso no es solo un diagrama: incluye decisiones, datos, reglas, roles, excepciones, tiempos, riesgos y sistemas.

Identificar cuándo un proyecto necesita enfoque process-driven: operaciones complejas, muchos handoffs, errores recurrentes, procesos manuales o baja adopción.

Reconocer que PDD no busca documentar por documentar, sino diseñar soluciones que encajen mejor con la forma de trabajar.

Separar procesos core, procesos de soporte, procesos de gestión, procesos regulatorios y procesos de experiencia de cliente.

Analizar cómo los procesos condicionan arquitectura, UX, permisos, datos, reporting, automatización y pruebas.

Evitar el error de digitalizar exactamente el proceso actual si está mal diseñado.

Introducir la diferencia entre proceso as-is, proceso to-be y proceso operativo implantado.

Crear un marco común para que negocio, tecnología y operaciones hablen de la misma realidad.

Localizar procesos candidatos a rediseño por impacto, frecuencia, coste, riesgo, volumen, quejas, retrasos o dependencia manual.

Distinguir procesos visibles para cliente, procesos internos, procesos regulatorios, procesos técnicos y procesos de soporte.

Priorizar procesos donde el rediseño puede generar ahorro, calidad, velocidad, trazabilidad o mejor experiencia.

Evitar comenzar por procesos demasiado grandes que impiden avanzar con claridad.

Dividir macroprocesos en subprocesos manejables sin perder visión de extremo a extremo.

Detectar procesos ocultos que viven en correos, Excel, reuniones, llamadas, conocimiento informal o decisiones personales.

Identificar stakeholders clave: ejecutores, responsables, aprobadores, clientes internos, sistemas, soporte, auditoría y dirección.

Valorar madurez del proceso: estable, caótico, regulado, manual, automatizado parcialmente o dependiente de personas concretas.

Crear una ficha inicial de proceso con objetivo, alcance, dueño, participantes, sistemas y dolor principal.

Seleccionar procesos piloto adecuados para aplicar PDD sin generar resistencia excesiva.

Preparar entrevistas, observación, revisión documental y análisis de sistemas para entender cómo se ejecuta el proceso.

Preguntar por casos normales, excepciones, urgencias, errores, retrabajos, aprobaciones y decisiones no documentadas.

Observar tareas reales en lugar de aceptar únicamente la versión ideal del procedimiento.

Recoger evidencias: formularios, pantallas, correos, plantillas, hojas de cálculo, tickets, informes y registros.

Identificar diferencias entre departamentos, sedes, perfiles, turnos o tipos de cliente.

Detectar pasos que se realizan porque “siempre se ha hecho así” y no porque aporten valor.

Recoger tiempos aproximados, volúmenes, frecuencia, cuellos de botella y esperas.

Registrar sistemas usados y puntos donde se copia información entre herramientas.

Mapear responsabilidades reales, no solo cargos formales.

Documentar dudas abiertas y supuestos que deberán validarse antes de diseñar la solución.

Representar el proceso actual tal como ocurre, incluyendo excepciones, atajos, esperas y retrabajos.

Usar niveles de detalle adecuados para que el modelo sea útil y no se convierta en un mural imposible de leer.

Diferenciar actividades, decisiones, eventos, documentos, sistemas, datos y actores.

Marcar puntos de dolor: esperas, duplicidades, errores, falta de visibilidad, aprobaciones lentas y tareas manuales.

Identificar handoffs entre personas, departamentos o sistemas, porque suelen ser zonas de pérdida de información.

Documentar reglas informales que no aparecen en procedimientos pero condicionan el resultado.

Señalar dónde se generan datos, dónde se transforman, dónde se validan y dónde se pierden.

Representar variantes relevantes sin mezclar todos los casos en un único flujo ilegible.

Validar el as-is con personas que ejecutan el proceso y no solo con responsables.

Usar el modelo as-is como base de discusión, no como entregable decorativo.

Utilizar BPMN para representar procesos con eventos, actividades, gateways, roles, pools, lanes y flujos.

Decidir cuándo BPMN aporta claridad y cuándo un mapa más ligero es suficiente.

Modelar eventos de inicio, eventos intermedios, eventos de fin, esperas, mensajes, temporizadores y errores.

Representar decisiones con gateways claros, evitando bifurcaciones ambiguas.

Separar actividades humanas, automáticas, de sistema, de usuario y de integración.

Usar lanes para visualizar responsabilidades y handoffs entre perfiles o áreas.

Incorporar excepciones sin convertir el diagrama principal en una maraña.

Relacionar BPMN con requisitos, historias, APIs, automatizaciones y pruebas.

Evitar diagramas BPMN técnicamente correctos pero inútiles para negocio.

Crear una guía de modelado BPMN mínima para equipos mixtos de negocio y tecnología.

Utilizar SIPOC para resumir proveedores, entradas, proceso, salidas y clientes del proceso.

Aplicar value stream mapping para visualizar flujo de valor, tiempos de espera, tiempos de trabajo y desperdicio.

Diferenciar actividades que añaden valor, actividades necesarias y actividades que deben eliminarse.

Detectar acumulaciones, colas, reentradas, aprobaciones redundantes y pasos de baja aportación.

Medir lead time, cycle time, touch time, espera, retrabajo y volumen.

Localizar puntos donde la información se transforma, se reintroduce o se valida repetidamente.

Visualizar el proceso completo desde necesidad inicial hasta resultado final.

Identificar actores que sufren el proceso aunque no lo ejecuten directamente.

Usar mapas de valor para priorizar rediseños con mayor impacto operativo.

Conectar la visión extremo a extremo con diseño de producto, automatización y reporting.

Identificar todos los roles que participan en el proceso, aunque no aparezcan en el organigrama formal.

Diferenciar responsable, ejecutor, aprobador, consultado, informado, auditor y propietario del proceso.

Analizar handoffs como momentos donde pueden aparecer pérdida de contexto, retrasos, errores o duplicidad.

Usar matrices RACI o variantes ligeras para aclarar responsabilidad.

Detectar tareas que nadie quiere asumir o que dependen de una persona concreta.

Revisar aprobaciones que no añaden control real pero ralentizan el flujo.

Identificar decisiones que cambian de mano sin criterio explícito.

Rediseñar responsabilidades para reducir fricción y mejorar accountability.

Traducir roles de proceso en permisos, vistas, acciones, notificaciones y tareas dentro del sistema.

Documentar responsabilidades to-be de forma clara para evitar que la solución digital nazca ambigua.

Identificar los objetos principales del proceso: solicitud, expediente, pedido, incidencia, contrato, orden, factura, caso, activo o cliente.

Mapear qué datos se crean, consultan, modifican, aprueban, archivan o eliminan en cada paso.

Revisar documentos usados: formularios, plantillas, anexos, evidencias, informes, justificantes, órdenes y comunicaciones.

Detectar duplicidad de datos entre sistemas o documentos.

Identificar campos obligatorios, opcionales, calculados, derivados, sensibles y auditables.

Analizar quién es dueño de cada dato y quién puede modificarlo.

Revisar calidad del dato: completitud, consistencia, frescura, trazabilidad y fuente fiable.

Traducir objetos de negocio en entidades, formularios, APIs, eventos, dashboards y reglas de validación.

Evitar diseñar pantallas sin entender el ciclo de vida completo de los datos.

Crear un modelo de información del proceso que sirva a negocio, desarrollo y QA.

Extraer reglas explícitas e implícitas que condicionan el proceso.

Diferenciar reglas legales, reglas internas, reglas de negocio, políticas de riesgo, criterios técnicos y acuerdos operativos.

Identificar decisiones repetitivas que podrían representarse con tablas de decisión, reglas o automatizaciones.

Detectar reglas que viven en personas, Excel, correos o código sin documentación.

Separar validaciones simples de decisiones complejas que requieren criterio humano.

Documentar entradas necesarias, criterios, resultado y consecuencias de cada decisión.

Revisar contradicciones entre reglas aplicadas por distintas áreas.

Preparar reglas para implementación en sistemas, motores de workflow, DMN, APIs o validaciones.

Asegurar trazabilidad entre regla, requisito, prueba, pantalla y proceso.

Crear mecanismos de revisión cuando las reglas cambian por normativa, estrategia o aprendizaje operativo.

Identificar excepciones frecuentes, raras, críticas y regulatorias.

Evitar diseñar solo el camino feliz del proceso.

Clasificar excepciones por causa: dato incompleto, rechazo, error técnico, falta de permiso, plazo vencido, duplicado o caso especial.

Revisar quién resuelve cada excepción y con qué información.

Diseñar caminos de recuperación para que el proceso no quede bloqueado.

Evitar que las excepciones se gestionen fuera del sistema mediante correos o mensajes informales.

Determinar qué excepciones deben automatizarse, escalarse, notificarse o auditarse.

Crear estados intermedios que permitan visibilidad sin ocultar problemas.

Incorporar excepciones en pruebas, dashboards y documentación.

Usar el análisis de excepciones como fuente de mejora del proceso principal.

Convertir actividades, decisiones, reglas y datos del proceso en funcionalidades concretas.

Diferenciar épicas, features, historias, tareas técnicas, automatizaciones, informes y mejoras de proceso.

Redactar historias conectadas con momentos del proceso y resultados esperados.

Priorizar funcionalidades según dolor operativo, valor, riesgo, frecuencia y dependencia.

Evitar backlogs formados por pantallas aisladas sin relación con el flujo completo.

Relacionar cada elemento del backlog con una parte del proceso as-is o to-be.

Identificar funcionalidades habilitadoras: permisos, datos maestros, integraciones, estados, notificaciones y auditoría.

Añadir criterios de aceptación basados en reglas, excepciones y resultados del proceso.

Crear trazabilidad entre proceso, requisito, historia, prueba y entrega.

Mantener el backlog vivo cuando cambia el diseño del proceso.

Diseñar interfaces que acompañen el flujo real de trabajo del usuario.

Priorizar información según la tarea, decisión o estado del proceso.

Evitar pantallas genéricas que obligan al usuario a recordar el proceso fuera del sistema.

Crear vistas por rol: solicitante, gestor, aprobador, supervisor, auditor, técnico o cliente.

Diseñar formularios que capturan datos en el momento adecuado y con validaciones claras.

Mostrar estado del proceso, responsables, próximos pasos, plazos y acciones disponibles.

Reducir carga cognitiva agrupando acciones según contexto operativo.

Diseñar alertas, confirmaciones y mensajes pensando en errores reales del proceso.

Incorporar accesibilidad y usabilidad para usuarios que trabajan bajo presión o con alta carga.

Validar prototipos observando si el usuario puede completar el proceso sin apoyos externos.

Modelar estados de los objetos principales del proceso: borrador, enviado, validado, rechazado, aprobado, cerrado o archivado.

Definir transiciones permitidas, responsables, condiciones y efectos de cada cambio de estado.

Evitar estados ambiguos como “pendiente” sin indicar de quién o de qué depende.

Diseñar historial de cambios para auditoría, soporte y análisis.

Controlar versiones de documentos, solicitudes, expedientes, órdenes o registros relevantes.

Asociar cada transición con fecha, usuario, motivo, comentario o evidencia cuando proceda.

Relacionar estados con permisos, vistas, acciones disponibles y notificaciones.

Incorporar SLAs y plazos a estados críticos.

Preparar pruebas de ciclo de vida para validar caminos normales y excepcionales.

Convertir el modelo de estados en base para workflow, APIs, reporting y control interno.

Traducir procesos en módulos, servicios, casos de uso, componentes, APIs, eventos y datos.

Evitar arquitecturas diseñadas solo por capas técnicas cuando el proceso exige límites funcionales claros.

Identificar servicios o módulos que corresponden a capacidades del proceso.

Separar coordinación de proceso, lógica de negocio, persistencia, integración y presentación.

Diseñar casos de uso que representan acciones significativas del flujo operativo.

Determinar cuándo usar workflow engine, orquestación, eventos, colas o lógica de aplicación.

Evaluar si un proceso debe vivir en una aplicación monolítica, varios servicios o una plataforma de automatización.

Diseñar integraciones con ERP, CRM, BI, correo, firma, DMS, ticketing u otras plataformas implicadas.

Revisar arquitectura pensando en cambios futuros del proceso.

Crear diagramas C4, secuencia o componentes conectados con pasos concretos del proceso.

Diseñar APIs que soportan acciones reales del proceso y no solo operaciones CRUD.

Identificar eventos de negocio relevantes: solicitud creada, orden aprobada, pago registrado, incidencia escalada o expediente cerrado.

Definir payloads con datos suficientes para consumidores sin exponer información innecesaria.

Decidir qué integraciones deben ser síncronas, asíncronas, batch, manuales o event-driven.

Mapear puntos donde se intercambia información entre sistemas.

Gestionar errores de integración como parte del proceso, no como fallos invisibles.

Diseñar reintentos, compensaciones, idempotencia y trazabilidad para operaciones críticas.

Documentar ownership de cada integración y datos transferidos.

Evitar integraciones punto a punto sin visión de proceso.

Relacionar APIs y eventos con pruebas, monitorización y dashboards operativos.

Identificar tareas repetitivas, estables y basadas en reglas que son candidatas a automatización.

Evitar automatizar procesos rotos sin rediseñarlos primero.

Diferenciar workflow, RPA, low-code, scripts, integración API y automatización con IA.

Elegir la herramienta según tipo de tarea, estabilidad del proceso, criticidad, volumen y mantenimiento.

Diseñar automatizaciones con entradas, salidas, errores, logs, responsables y fallback.

Mantener intervención humana en decisiones ambiguas o de alto impacto.

Documentar qué parte del proceso está automatizada y bajo qué condiciones.

Medir ahorro real de tiempo, reducción de errores y mejora de trazabilidad.

Evitar bots frágiles que dependen de interfaces cambiantes cuando existe API.

Crear una matriz de automatización para priorizar iniciativas con impacto y bajo riesgo.

Identificar usos de IA en procesos: clasificación, resumen, extracción de datos, recomendación, priorización, generación de borradores y detección de anomalías.

Separar tareas asistidas por IA de decisiones que deben conservar revisión humana.

Diseñar prompts, reglas y validaciones conectadas con el proceso real.

Usar IA para acelerar análisis documental, atención interna, generación de respuestas o preparación de informes.

Evitar introducir IA sin datos, criterios, ownership o controles de calidad.

Diseñar mecanismos de trazabilidad cuando una recomendación de IA influye en una decisión.

Incorporar revisión, aprobación y corrección humana en procesos sensibles.

Medir impacto de la IA en tiempo, calidad, errores y satisfacción.

Gestionar riesgos de privacidad, confidencialidad, sesgo y alucinaciones.

Integrar IA en el proceso como capacidad controlada, no como sustituto genérico de la operativa.

Entender process mining como técnica para descubrir procesos reales a partir de eventos registrados en sistemas.

Identificar datos necesarios: case id, actividad, timestamp, recurso, estado y atributos contextuales.

Comparar proceso esperado con proceso ejecutado.

Detectar variantes, bucles, retrabajos, esperas, caminos raros y desviaciones.

Analizar tiempos entre actividades y frecuencia de rutas.

Validar modelos as-is con evidencias de sistemas cuando existen logs suficientes.

Identificar oportunidades de automatización y simplificación a partir de datos reales.

Evitar conclusiones erróneas cuando los eventos están incompletos o mal definidos.

Conectar process mining con mejora continua, auditoría y rediseño to-be.

Diseñar desde PDD pensando en capturar eventos que permitan analizar el proceso en el futuro.

Definir indicadores de proceso: volumen, tiempo de ciclo, espera, retrabajo, errores, cumplimiento, coste y satisfacción.

Separar métricas de actividad, eficiencia, calidad, riesgo, experiencia y resultado.

Crear SLAs realistas vinculados a estados y responsabilidades.

Diseñar dashboards que muestren qué procesos requieren atención y por qué.

Evitar medir solo tareas completadas sin medir valor generado.

Incorporar métricas de excepción, backlog, ageing, cuellos de botella y capacidad.

Segmentar indicadores por área, equipo, tipo de caso, prioridad, cliente o canal.

Definir responsables de cada métrica y frecuencia de revisión.

Relacionar métricas con acciones: escalar, reasignar, automatizar, formar, corregir o rediseñar.

Usar cuadros de mando como herramienta de gestión del proceso, no solo como reporting pasivo.

Identificar datos sensibles, acciones críticas, aprobaciones reguladas y evidencias obligatorias.

Diseñar permisos según rol, estado del proceso, propiedad del caso y segregación de funciones.

Evitar que todos los usuarios puedan ver o modificar todo por comodidad de implementación.

Incorporar auditoría en acciones relevantes: aprobación, rechazo, modificación, borrado, cambio de estado o excepción.

Documentar controles internos asociados al proceso.

Gestionar retención, archivo, trazabilidad y eliminación de información.

Revisar riesgos de cumplimiento, fraude, error humano, acceso indebido y modificación no autorizada.

Diseñar workflows que refuercen control sin generar burocracia innecesaria.

Preparar evidencias para auditoría y revisión externa cuando sea necesario.

Integrar privacidad y seguridad desde el diseño del proceso, no como capa final.

Diseñar pruebas a partir del flujo completo, no solo de pantallas o endpoints.

Cubrir camino principal, caminos alternativos, excepciones, rechazos, plazos y errores de integración.

Crear casos de prueba por rol, estado, permiso, dato y regla de negocio.

Validar que cada transición de estado produce los efectos esperados.

Probar notificaciones, auditoría, documentos generados, integraciones y dashboards.

Diseñar pruebas end-to-end para procesos críticos.

Complementar pruebas automáticas con revisión funcional por usuarios clave.

Usar el modelo BPMN o flujo to-be como base de cobertura.

Detectar huecos cuando una actividad del proceso no tiene prueba asociada.

Incorporar QA al diseño del proceso para anticipar errores antes de construir.

Reconocer que rediseñar un proceso implica cambiar hábitos, responsabilidades y expectativas.

Identificar resistencias por pérdida de control, aumento de visibilidad, nuevas herramientas o temor a automatización.

Involucrar usuarios clave desde el levantamiento hasta la validación del to-be.

Comunicar beneficios concretos por rol, no solo objetivos generales de transformación.

Preparar formación, guías, soporte y materiales de transición.

Diseñar un plan de implantación por fases cuando el proceso afecta a muchas áreas.

Mantener canales para recoger incidencias y mejoras tras el arranque.

Medir adopción real: uso del sistema, reducción de atajos, calidad de datos y cumplimiento del flujo.

Ajustar el proceso tras observar comportamiento real.

Evitar imponer un proceso perfecto sobre el papel que nadie adopta en la práctica.

Definir propietarios de proceso con autoridad para revisar, priorizar y mejorar.

Establecer una cadencia de revisión basada en datos, incidencias, feedback y cambios normativos.

Mantener documentación viva del proceso, no archivos estáticos olvidados.

Gestionar cambios mediante versiones, impacto, comunicación y pruebas.

Crear un backlog de mejoras de proceso conectado con producto y tecnología.

Revisar periódicamente reglas, excepciones, SLAs, automatizaciones y permisos.

Medir beneficios de cada mejora implantada.

Evitar que cada área modifique el proceso por su cuenta sin visión global.

Crear un modelo de gobierno ligero que no ralentice mejoras pequeñas.

Convertir PDD en una disciplina continua, no en un proyecto puntual de documentación.

Diseñar pantallas antes de entender el flujo de trabajo completo.

Automatizar tareas manuales sin cuestionar si deberían existir.

Modelar procesos ideales ignorando excepciones y atajos reales.

Crear diagramas enormes que nadie usa para tomar decisiones.

Confundir BPMN con PDD y pensar que dibujar equivale a diseñar.

Digitalizar aprobaciones innecesarias que solo añaden demora.

Diseñar permisos sin comprender roles y responsabilidades reales.

Separar proceso, datos, UX y arquitectura como si fueran mundos independientes.

Crear dashboards sin acciones asociadas.

Implantar un proceso nuevo sin gestionar adopción, formación y feedback.

Evaluar la madurez actual de la organización en gestión de procesos, documentación, automatización y datos.

Elegir un proceso piloto con impacto claro y alcance controlado.

Preparar sesiones de descubrimiento con personas que ejecutan, supervisan y reciben el resultado del proceso.

Modelar as-is y validar la realidad antes de proponer mejoras.

Diseñar to-be con simplificación, automatización, controles, métricas y experiencia de usuario.

Traducir el to-be en backlog, arquitectura, datos, pruebas y plan de implantación.

Definir métricas iniciales para medir si el rediseño funciona.

Implantar por fases si el proceso es crítico o afecta a muchas áreas.

Recoger feedback y datos de uso tras la puesta en marcha.

Escalar la práctica PDD a otros procesos con una metodología interna reutilizable.

Seleccionar un proceso empresarial con roles, datos, sistemas, decisiones, excepciones y oportunidades de mejora.

Crear ficha de proceso con objetivo, alcance, dueño, participantes, entradas, salidas y dolor principal.

Levantar el proceso as-is mediante entrevistas, evidencias, eventos, documentos y sistemas implicados.

Modelar el proceso actual usando BPMN, SIPOC, value stream map o combinación adecuada.

Detectar cuellos de botella, retrabajos, handoffs, riesgos, reglas ocultas, datos duplicados y tareas automatizables.

Diseñar un proceso to-be simplificado, medible, trazable y alineado con roles reales.

Traducir el to-be en backlog funcional, modelo de datos, estados, permisos, APIs, eventos, dashboards y pruebas.

Proponer automatizaciones, IA o integraciones donde aporten valor sin aumentar fragilidad.

Definir plan de implantación, adopción, métricas, gobierno y mejora continua.

Presentar la solución final justificando decisiones, beneficios esperados, riesgos, controles y evolución futura.