Tiene los mapas de procesos. Quizá tiene bastantes. Algún miembro del equipo creó un diagrama de carriles en Lucidchart hace dos años. Otro departamento mantiene una página de Confluence con diagramas de flujo que se actualizaron por última vez cuando todos aún iban a la oficina. Y cuando algo falla en un punto de traspaso entre Ventas y Finanzas, o cuando un nuevo proyecto de automatización tropieza consigo mismo al intentar integrar tres sistemas distintos que describen el mismo concepto de forma diferente, alguien dice: "Deberíamos documentar esto mejor".
Ese es el diagnóstico equivocado. Los mapas no son el problema, y más mapas no lo solucionarán. Lo que falta es la estructura que los conecta: el modelo rector que le indica qué procesos existen, cómo se relacionan entre sí, quién es responsable de ellos y cómo se mejoran. Eso es arquitectura de procesos de negocio. Y no es documentación. Es una disciplina.
La afirmación central aquí es refutable: la mayoría de los esfuerzos de mejora y automatización de procesos fracasan en sus límites no porque los mapas de procesos individuales sean incorrectos, sino porque no existe una arquitectura que los mantenga unidos. Corrija los mapas sin construir la arquitectura y volverá al mismo punto dentro de 18 meses.
La parte que la mayoría de los equipos aprende después de la segunda iniciativa fallida
- La arquitectura de procesos de negocio (BPA) es un modelo operativo jerárquico, no una colección de diagramas.
- Un único mapa de procesos no es BPA: la arquitectura organiza toda la jerarquía y la gobernanza que la rodea.
- La BPA requiere responsables de proceso, métricas y gestión del cambio para funcionar; la jerarquía por sí sola no es suficiente.
- La señal práctica de que necesita BPA: los proyectos de automatización siguen fallando en los puntos de integración entre departamentos.
Qué es realmente la arquitectura de procesos de negocio
La arquitectura de procesos de negocio es un modelo jerárquico de los procesos empresariales de una organización, que cubre como mínimo dos niveles de la jerarquía de procesos: el nivel de procesos de extremo a extremo y el nivel de grupos de procesos que los contienen. Esa es la definición operativa de la investigación de Eficio sobre arquitectura de procesos, y es más específica de lo que la mayoría de los equipos espera.
La palabra "jerárquico" es fundamental aquí. Un único diagrama de carriles que muestra cómo un representante de ventas mueve una oportunidad a través de distintas etapas es un mapa de procesos. Documenta un proceso. La arquitectura de procesos de negocio es el modelo organizativo que sitúa ese mapa junto a todos los demás procesos de la empresa, en múltiples niveles de abstracción, y define las relaciones entre ellos. Sin la jerarquía, no tiene una arquitectura. Tiene un diagrama. No son lo mismo.
La confusión es comprensible. Ambos incluyen cajas y flechas. Pero una arquitectura da contexto a cualquier mapa individual: quién es responsable de este proceso, dónde se sitúa respecto a los procesos que lo rodean, qué lo alimenta y qué produce, y cómo saber cuándo necesita cambiar. Un mapa de procesos no le proporciona nada de eso. Solo muestra los pasos.
En qué se diferencia la arquitectura de procesos de negocio de un único mapa de procesos de negocio
Un mapa de procesos es una vista de un proceso. La arquitectura de procesos de negocio es el sistema organizativo para todos ellos. La capa arquitectónica establece un contexto que los mapas individuales no pueden proporcionarse por sí mismos, que es precisamente la razón por la que los equipos que invierten mucho en el mapeo terminan con contradicciones que no pueden resolver.
Esto es lo que sigo viendo en la práctica: Marketing crea un mapa de procesos de cualificación de leads. Ventas crea un mapa de procesos de traspaso. Ninguno de los equipos se coordina a nivel arquitectónico, lo que significa que los nombres de los campos difieren, el desencadenante del traspaso se define de manera distinta en cada diagrama y, cuando alguien intenta automatizar ambos, la automatización falla porque trata de reconciliar dos mapas que se crearon sin un marco común. Puede corregir ambos mapas y el problema volverá la próxima vez que alguien actualice uno sin modificar el otro.
La arquitectura de procesos en la gestión de procesos de negocio resuelve esto estableciendo primero la estructura rectora. La arquitectura define grupos de procesos (como "Del lead al cobro" o "Incorporación de clientes"), sitúa los procesos de extremo a extremo dentro de esos grupos y, después, los mapas individuales viven dentro de esa estructura. Ahora, cuando Marketing actualiza su parte, existe un marco claro que determina qué afecta ese cambio en las etapas posteriores.
Sin arquitectura, los mapas de procesos se desvían. Se contradicen entre departamentos. La responsabilidad se vuelve poco clara. Y los esfuerzos de mejora se estancan porque nadie puede acordar el alcance, dado que nunca se definió el alcance a nivel arquitectónico desde el principio.
La jerarquía que hace que la arquitectura sea más que un diagrama
La arquitectura de procesos mínima viable cubre dos niveles: grupos de procesos (conjuntos de procesos relacionados por área de negocio o flujo de valor) y los procesos de extremo a extremo dentro de esos grupos. Por debajo se encuentran los subprocesos, las actividades y, finalmente, las instrucciones de trabajo, aunque no todas las organizaciones necesitan llegar tan lejos.
Lo que hace que esto sea una jerarquía en lugar de una lista plana es que cada nivel hereda el contexto del nivel superior. Un proceso de extremo a extremo para "Devolución de pago" solo tiene sentido cuando sabe que pertenece al grupo de procesos de servicios de pago, que se sitúa dentro de un conjunto más amplio de operaciones financieras. El caso de estudio de mBank sobre la mejora de procesos de pago muestra exactamente esto: los arquitectos del banco primero mapearon la arquitectura de servicios de pago y luego utilizaron esa estructura para localizar y rediseñar el proceso específico de "devolución de pago". La arquitectura hizo posible el esfuerzo de mejora porque proporcionó al equipo un lugar donde encontrar el problema dentro del panorama más amplio de procesos.
Esta visión por capas es lo que separa la arquitectura de la documentación. La documentación registra lo que existe. La arquitectura ofrece una estructura coherente dentro de la cual existe todo, para que siempre sepa dónde se encuentra.
Dónde se superponen y se separan la arquitectura de negocio y la arquitectura de procesos de negocio
Estas dos disciplinas suelen confundirse, y esa confusión descarrila las conversaciones sobre alcance en los peores momentos posibles.
La arquitectura de negocio es la disciplina más amplia: cubre la estrategia, las capacidades, los flujos de valor y el diseño organizativo de una organización. Responde a preguntas como "qué capacidades necesitamos para competir" y "cómo crean nuestros flujos de valor resultados para los clientes". Los elementos de la arquitectura de negocio —capacidades, flujos de valor, flujos de información— operan a nivel estratégico y organizativo.
La arquitectura de procesos de negocio se sitúa dentro de ella. Toma los flujos de valor y las capacidades que define la arquitectura de negocio y pregunta: ¿cuáles son los procesos reales que los ofrecen, cómo se organizan, quién es responsable de ellos y cómo mejoran? Una práctica de arquitectura de negocio normalmente informa el nivel superior de la jerarquía de procesos, orientando la BPA hacia las agrupaciones y prioridades adecuadas.
Versión corta: la arquitectura de negocio cubre el porqué y el qué a escala estratégica. La arquitectura de procesos de negocio cubre el cómo a escala de procesos. Ambas son necesarias. Ninguna sustituye a la otra.
Qué contiene realmente una arquitectura de procesos de negocio funcional
La investigación de Gluu sobre BPA lo deja claro: una arquitectura de procesos funcional no es solo el gráfico jerárquico. Es un plano que incluye estructuras de gobernanza, responsables de proceso, estándares, definiciones de interfaces entre procesos, medidas de rendimiento y etiquetas que conectan los procesos con los sistemas y datos que utilizan. La jerarquía es el esqueleto. Todo esto es el resto del cuerpo.
La mayoría de los equipos construye el esqueleto y se detiene. Se produce el diagrama de jerarquía, se incorpora a Confluence y todos sienten que el trabajo está terminado. Luego, seis meses después, alguien pregunta quién es responsable del proceso de cualificación de leads y la respuesta está entre un encogimiento de hombros y tres hilos de Slack en competencia. La arquitectura existe visualmente. Falla operativamente.
Las etiquetas de sistemas y datos importan más de lo que la gente espera. Cuando un proceso está etiquetado con los sistemas que toca, sabe de inmediato qué automatizaciones y herramientas están dentro del alcance cuando el proceso cambia. Sin esas etiquetas, cada proyecto de automatización comienza con una fase de descubrimiento en la que alguien pregunta: "esperen, ¿este proceso toca Salesforce o HubSpot?" y la respuesta es: "creemos que ambos, tal vez".
Las medidas de rendimiento son la otra pieza que normalmente se omite. Una arquitectura sin métricas es aspiracional. Una arquitectura con métricas es un modelo operativo: realmente puede ver cuándo un proceso se está deteriorando y responder.
🤔 Piense en esto:
La mayoría de los equipos invierte mucho tiempo en el mapeo de procesos y casi nada en la responsabilidad sobre los procesos. Se construye el diagrama de jerarquía. No se designa a nadie responsable de mantenerlo. No se definen métricas. Por tanto, cuando un proceso falla, no hay un responsable que lo corrija ni una medida que confirme que se ha corregido. La arquitectura existe como documento. Nunca se convierte en una disciplina.
Gobernanza, responsables de proceso y las partes que la mayoría de los equipos omite
La investigación de BPMInstitute sobre BPA es directa al respecto: una arquitectura de procesos eficaz requiere gobernanza, responsables de proceso, gestión del cambio y medición. Elimine cualquiera de estos elementos y la arquitectura se degrada hasta convertirse en un artefacto estático.
La gobernanza significa que existe una estructura definida de toma de decisiones para los cambios de proceso. ¿Quién puede modificar un proceso? ¿Qué desencadena una revisión? ¿Quién resuelve los conflictos cuando los procesos de dos departamentos se contradicen? Sin gobernanza, cada equipo optimiza su propia parte y los puntos de integración entre equipos se convierten en territorio de nadie.
Los responsables de proceso son las personas específicas que rinden cuentas por el rendimiento del proceso. No el equipo. No el departamento. Una persona designada. Este es el elemento que veo omitirse con mayor frecuencia en la práctica. Un proceso sin responsable es un proceso que nadie actualiza cuando cambia la realidad y que nadie corrige cuando algo falla a lo largo de él.
La gestión del cambio y las métricas son lo que hace que la arquitectura esté viva en lugar de archivada. El rendimiento de los procesos se degrada con el tiempo. Las condiciones del mercado cambian. Los sistemas se sustituyen. La arquitectura debe tener un ciclo definido para revisar y actualizar los procesos, así como las métricas que le indiquen cuándo una revisión está atrasada.
Ahí es donde entran la gobernanza, los responsables, la gestión del cambio y la medición. Si los omite, tendrá un diagrama caro.
Marcos arquitectónicos y diseño de arquitecturas de procesos
Dos marcos aparecen con mayor frecuencia cuando los equipos empiezan a diseñar arquitecturas de procesos, y resuelven problemas distintos.
El primero proporciona una taxonomía de referencia: una forma de comprobar si ha cubierto el panorama de procesos y un punto de referencia para comparar su estructura con la de otras organizaciones. El segundo proporciona una metodología de diseño: una forma de tomar decisiones estructurales sobre cómo organizar su arquitectura cuando la construye desde cero. Normalmente necesita ambos. Uno le dice qué debe estar en la arquitectura. El otro le dice cómo organizarlo.
Los profesionales de BPM identifican de forma consistente las habilidades de modelado de procesos y el diseño de arquitectura como competencias esenciales para 2026, precisamente porque diseñar una arquitectura de procesos no es una actividad puntual. Requiere pensamiento metodológico continuo a medida que la organización cambia. BPMN sigue siendo la notación estándar para el modelado de procesos dentro de la arquitectura, pero los marcos siguientes se sitúan por encima de esa capa: tratan de estructura y clasificación antes de que siquiera dibuje un flujo.
El Marco de Clasificación de Procesos de APQC como taxonomía inicial
El Marco de Clasificación de Procesos (PCF) de APQC es una taxonomía intersectorial que organiza los procesos de negocio en 12 categorías de nivel empresarial, desde "Desarrollar visión y estrategia" hasta procesos operativos y "Gestionar recursos financieros". Las organizaciones lo utilizan como punto de referencia inicial al construir o validar su propia arquitectura de procesos, mapeando sus procesos existentes frente a las categorías del PCF para identificar brechas, redundancias o nomenclaturas inconsistentes.
El valor del PCF es comparativo. Dado que es intersectorial y neutral respecto a proveedores, proporciona a los procesos de su organización un marco de referencia común, lo que significa que puede comparar la estructura y el rendimiento de sus procesos con otras organizaciones de su sector que utilizan la misma clasificación. También evita el error taxonómico más común, que consiste en organizar los procesos alrededor del organigrama actual en lugar de alrededor de las actividades empresariales reales. Los organigramas cambian. Los procesos clave que realiza una empresa cambian mucho más lentamente.
Piense en el PCF de APQC como un mapa de partida, no como un destino. Su arquitectura se desviará de él según lo que su organización realmente haga. Eso es esperable. El marco es una comprobación de cordura, no una camisa de fuerza.
Diseño de arquitecturas de procesos según tipo de caso y función de negocio
El modelo de diseño bidimensional de Dijkman, documentado en la investigación sobre diseño de arquitectura de procesos de negocio, ofrece a los equipos una forma práctica de tomar decisiones estructurales: organizar los procesos según dos ejes, el tipo de caso (qué tipo de entidad o solicitud se procesa) y la función de negocio (qué capacidad organizativa realiza el trabajo).
En la práctica, esto significa formular dos preguntas sobre cualquier proceso: qué se está gestionando (un pedido de cliente, un ticket de soporte, una solicitud de incorporación de empleado, una devolución de pago) y qué función realiza la gestión (Finanzas, Operaciones, Éxito del Cliente). Donde esas dimensiones se cruzan, se encuentra el proceso. La cadena de valor se convierte en algo que puede leer como una matriz en vez de solamente como una secuencia lineal.
Esto importa para el diseño porque muchas organizaciones se organizan en exceso alrededor de la función de negocio (lo que da lugar a arquitecturas que reflejan el organigrama y se vuelven imposibles de mantener a medida que cambia la organización) o se organizan demasiado poco por tipo de caso (lo que da lugar a arquitecturas donde el mismo caso fluye a través de procesos multifuncionales de los que nadie puede responsabilizarse claramente). El modelo de Dijkman mantiene ambas dimensiones visibles, lo que hace que la arquitectura resultante sea más fácil de mantener y de utilizar como entrada para proyectos de automatización y mejora.
Niveles de la arquitectura de procesos de negocio: hasta dónde debe llegar la jerarquía
La definición de Eficio establece el mínimo de dos niveles —grupos de procesos y procesos de extremo a extremo—, pero la jerarquía puede extenderse más en ambas direcciones. Comprender ese rango es lo que evita los dos modos de fallo que veo con más frecuencia: arquitecturas tan generales que son inútiles para las decisiones operativas y arquitecturas tan granulares que se vuelven imposibles de mantener.
Aquí tiene un mapa práctico de niveles:
| Nivel | Etiqueta | Ejemplo |
|---|---|---|
| 1 | Categorías / grupos de procesos | Del lead al cobro, Servicio al cliente |
| 2 | Procesos de extremo a extremo | Incorporación de nuevos clientes |
| 3 | Subprocesos | Configuración de cuenta, Secuencia de bienvenida |
| 4 | Actividades de proceso | Enviar correo electrónico de bienvenida, Crear registro de CRM |
| 5 | Tareas / instrucciones de trabajo | Abrir CRM, navegar a contactos, crear nuevo registro |
Los niveles 1 y 2 son la arquitectura en sentido estricto. Los niveles 3 y 4 son modelos de procesos. El nivel 5 es documentación. La arquitectura cubre lo que necesita existir a nivel organizativo. Cuanto más profundice, más contenido de procedimientos operativos estará produciendo, no arquitectura.
La mayoría de los equipos con menos de 200 personas necesita mantener rigurosamente los niveles 1-3 y disponer de los niveles 4-5 en formato de documentación para procesos de alto riesgo o gran volumen. Llegar al nivel 5 para cada proceso en una empresa mediana es una batalla perdida. La carga de mantenimiento supera el valor. Elija deliberadamente la profundidad.
La pregunta de BPM que suele bloquear más conversaciones es: "¿qué nivel de detalle deben tener nuestras actividades de proceso a nivel arquitectónico?" La respuesta honesta es: el suficiente para dejar clara la responsabilidad y delimitar AutomationProjectX, pero no tanto como para crear material de formación paso a paso. Son documentos distintos para públicos distintos.
Dónde conecta la arquitectura empresarial con los niveles de proceso
La arquitectura empresarial (EA) es el sistema organizativo más amplio en el que se integra la arquitectura de procesos de negocio. EA cubre tecnología, datos, aplicaciones y estrategia: conecta la estrategia con la ejecución a escala organizativa completa. La BPA es una capa dentro de la EA, centrada específicamente en la dimensión de procesos.
En la práctica, esto significa que el nivel superior de su jerarquía de procesos (los grupos de procesos) debe alinearse con las capacidades y los flujos de valor que define la arquitectura empresarial. EA le indica qué capacidades necesita tener la organización. Su arquitectura de procesos organiza los procesos que ofrecen esas capacidades. Sin esa alineación, la arquitectura de procesos puede alejarse de las prioridades estratégicas: termina con una imagen bien organizada de lo que la organización hace en lugar de lo que necesita hacer.
La estructura organizativa también es relevante aquí: sus grupos de procesos deben definirse independientemente de la estructura organizativa actual, pero deben ser comprensibles para el equipo directivo responsable de esa estructura. Una arquitectura que solo tiene sentido para los arquitectos no está gobernando nada.
Tres conceptos erróneos que mantienen bloqueados los proyectos de arquitectura de procesos
Todos los proyectos de arquitectura de procesos bloqueados que he visto implican al menos uno de estos conceptos erróneos. Normalmente dos.
- La BPA es solo un diagrama de flujo
Este es el concepto erróneo que hace que los equipos declaren "ya tenemos esto" cuando alguien plantea la arquitectura de procesos como una necesidad. Un diagrama de flujo mapea un proceso. La arquitectura de procesos de negocio los organiza todos, en múltiples niveles, con gobernanza, responsables de proceso, métricas y gestión del cambio incorporados. La consecuencia crítica: los equipos que tratan su colección de diagramas como arquitectura omiten por completo las capas de responsabilidad y medición, lo que significa que la primera vez que cambia un proceso, no existe ningún mecanismo para actualizar la arquitectura. En 12 meses, los diagramas están obsoletos y nadie confía en ellos. La coherencia se derrumba, una excepción no documentada a la vez.
- La BPA solo es útil para grandes empresas
Las organizaciones más pequeñas necesitan una arquitectura proporcional, no una ausencia total de arquitectura. Este concepto erróneo lleva a los equipos medianos a omitir por completo la estructura y luego preguntarse por qué su proyecto de mejora de procesos generó ganancias locales pero causó retrabajo en otra parte. Una empresa SaaS de 60 personas con cinco departamentos y 12 integraciones de productos tiene suficiente complejidad de procesos como para que los traspasos no documentados generen errores de forma constante. La arquitectura no necesita ser un marco de 300 páginas. Debe ser lo bastante coherente para que alguien pueda responder: ¿quién es responsable de este proceso y cómo sabemos cuándo funciona bien?
- La BPA puede crearse una vez y dejarse sin cambios
La arquitectura de procesos no es un documento que se archiva. Es una disciplina operativa que evoluciona con su organización. Los equipos que la tratan como un artefacto puntual descubren que deja de reflejar la realidad en pocos meses: la estrategia cambia, los sistemas cambian, los equipos se reorganizan. Cuando la arquitectura diverge de las operaciones reales, las personas dejan de consultarla y la mejora continua se vuelve imposible porque nadie tiene una imagen precisa de lo que existe actualmente. Un proyecto de mejora de procesos basado en una arquitectura desactualizada es un proyecto de mejora de procesos dirigido al objetivo equivocado.
📊 En la práctica:
Según BPMInstitute, una arquitectura de procesos eficaz requiere gobernanza, gestión del cambio y medición, no solo un gráfico jerárquico. Las organizaciones que construyen la jerarquía sin esos elementos de apoyo normalmente abandonan la arquitectura dentro de 18 meses. El artefacto visual sobrevive. La disciplina operativa nunca se forma. La ejecución de procesos continúa desviándose del modelo documentado hasta que la brecha es demasiado grande para cerrarla sin empezar de nuevo.
Cuándo aplicar la arquitectura de procesos de negocio y cuándo es excesiva
La arquitectura de procesos de negocio no es la respuesta correcta para todas las situaciones. Una startup de 12 personas con un producto y cuatro procesos no necesita una arquitectura formal. Necesita una responsabilidad clara y buena documentación. Así puede distinguir la diferencia.
Probablemente necesita una arquitectura formal cuando: su organización está creciendo más allá de 50-75 personas y los traspasos entre departamentos generan errores o retrasos; está emprendiendo una iniciativa de transformación digital que afectará a varios sistemas y equipos; tiene requisitos de cumplimiento o auditoría que exigen responsabilidades de proceso rastreables e historial documentado de cambios; o ha ejecutado dos o más proyectos de mejora de procesos que resolvieron un problema local pero crearon uno nuevo en otra parte.
La señal más fiable, según lo que veo en soporte y lo que aparece en las conversaciones de la comunidad: proyectos de automatización que siguen fallando en los puntos de integración entre departamentos. Eso casi siempre es un síntoma de arquitectura. Cuando la automatización de Marketing funciona, la automatización de Ventas funciona, pero el traspaso entre ambas no, el problema no son las automatizaciones individuales. Es la ausencia de un modelo de procesos compartido sobre el que se construyeron ambas.
Cuándo es excesiva: una mejora de procesos de un único departamento, un proyecto de automatización de un equipo pequeño con un responsable claro o cualquier situación donde el alcance sea lo bastante reducido como para que una persona pueda tener la imagen completa en mente. La arquitectura formal tiene una carga de mantenimiento real. No la aplique donde un mapa de procesos bien mantenido con una responsabilidad clara logra el mismo resultado.
Específicamente sobre la automatización: construir una arquitectura de procesos antes de automatizar flujos multifuncionales es uno de los casos de uso más claros y de mayor impacto de esta práctica. Cuando las partes interesadas se han alineado sobre la arquitectura, la automatización puede diseñarse sobre un modelo de procesos estable en lugar de sobre el estado improvisado actual. Una responsable de operaciones de una empresa mediana con la que trabajé recientemente lo expresó claramente: una vez que tuvo esbozada la arquitectura de incorporación —solo los niveles 1 y 2, grupos de procesos claros, responsables claros— los objetivos de negocio del esfuerzo de automatización se hicieron evidentes. Podía ver exactamente qué pasos eran candidatos para la automatización y cuáles requerían criterio humano. Antes de la arquitectura, estaba haciendo conjeturas. Utilizó Latenode para conectar su CRM, sistema de facturación y herramienta de tickets en una vista en vivo de dónde se encontraban los clientes en el proceso, con un paso de enriquecimiento de IA que clasificaba señales de riesgo de los tickets de soporte. El precio por ejecución implicaba que su flujo de varios pasos contaba como una única ejecución en lugar de seis tareas separadas. Pero la tecnología solo era tan útil como el modelo de procesos que la sustentaba.
Pasos de proceso que señalan una brecha de arquitectura
Estos patrones aparecen en la cola de trabajo mucho antes de que alguien admita que falta la arquitectura:
Los mismos datos existen en dos sistemas con valores diferentes. Nadie está seguro de cuál es la fuente autorizada. Este es un problema de arquitectura disfrazado de problema de calidad de datos.
Un proyecto de automatización falla en el traspaso entre dos departamentos. El BPM está bien en cada lado. La interdependencia entre ambos nunca se definió en un modelo compartido.
Las métricas de dos equipos se contradicen sobre el mismo proceso. Ambas cifras son técnicamente correctas según la definición de cada equipo. La arquitectura nunca estuvo ahí para establecer una única definición.
Un nuevo miembro del equipo pregunta qué documento de proceso está vigente. La respuesta implica más de dos archivos y la frase "creo que".
Cualquier cuello de botella que se haya "identificado" en varias iniciativas de mejora independientes pero nunca se haya resuelto realmente. Esto significa que se encuentra en un límite entre áreas de responsabilidad de procesos, que es donde viven las brechas de arquitectura.
El resultado de cualquier paso de proceso no coincide con lo que el siguiente paso de proceso espera como entrada. Alguien está realizando una conciliación manual en una hoja de cálculo para alinear procesos y datos que ya deberían estar alineados. Esa es una brecha de arquitectura a tiempo completo disfrazada.
