> ## Content Index > Fetch the complete content index at: https://www.consultoriaprocesos.com/llms.txt > Use this file to discover other available public pages before exploring further. # 馃殾 Qu茅 tiene que ser cierto antes de empezar - URL: https://www.consultoriaprocesos.com/la-frontera-de-aceptacion/ - Published: 2026-10-31T12:50:08.000Z - Updated: 2026-10-31T12:50:08.000Z - Description: Condiciones de aceptaci贸n, puertas de calidad e inspecci贸n en la fuente: c贸mo definir qu茅 debe ser cierto para que el trabajo avance, sin construir una burocracia nueva. - Author: Johan - Tags: Consultor铆a, Calidad, Poka-yoke, Mejora Continua La mayor铆a de los sistemas de calidad empiezan por el final. Se revisa el resultado, se detecta lo que est谩 mal y se devuelve para corregir. Funciona, hasta cierto punto, y tiene un coste que casi nunca aparece en ning煤n indicador: todo lo que se hizo entre el momento en que el error se pod铆a haber evitado y el momento en que alguien lo vio. Un ejemplo que en oficinas pasa todas las semanas. Alguien recibe un encargo que dice, literalmente, "explora este tema y prepara algo 煤til". La persona se pone a trabajar. No hay entregable acordado, ni alcance, ni criterio de terminaci贸n. Tres d铆as despu茅s, quien lo pidi贸 dice que no es lo que esperaba. El defecto se ha descubierto aguas abajo, y la reacci贸n habitual es a帽adir una revisi贸n final o pedirle a la persona que "comunique mejor". La pregunta de la inspecci贸n en la fuente es otra: **驴qu茅 condiciones tendr铆an que haberse comprobado antes de permitir que ese trabajo empezara?** La calidad no consiste solo en detectar resultados defectuosos. Consiste en definir y sostener las condiciones necesarias para producir resultados aceptables. ## **1\. El vocabulario importa: seis tipos de criterios que no son lo mismo** En fabricaci贸n, estas condiciones suelen ser f铆sicas y medibles: la dimensi贸n correcta, la orientaci贸n correcta, el n煤mero correcto de componentes. En el trabajo de oficina son informativas, l贸gicas o procedimentales: informaci贸n suficiente, autorizaci贸n v谩lida, versi贸n correcta del documento, alcance claro, evidencia aceptable. El principio es id茅ntico, pero el vocabulario se mezcla con facilidad y conviene separarlo. | T茅rmino | Qu茅 significa | Ejemplo | | ----------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------- | | **Criterios de aceptaci贸n** | Condiciones que un resultado debe cumplir para considerarse aceptable | El informe incluye todos los an谩lisis requeridos | | **Criterios de entrada** | Condiciones que deben cumplirse antes de poder empezar el trabajo | La solicitud tiene alcance definido y responsable | | **Criterios de salida** | Condiciones necesarias para que el trabajo abandone un paso | El documento ha sido revisado y aprobado | | **Criterios de elegibilidad** | Condiciones que determinan si un caso corresponde a este proceso o servicio | La petici贸n entra dentro del mandato del departamento | | **Criterios de rechazo** | Condiciones que hacen inaceptable una entrada o un resultado | La solicitud contiene informaci贸n contradictoria | | **Criterios de liberaci贸n** | Condiciones que autorizan el paso a la siguiente etapa | Todas las comprobaciones obligatorias est谩n cumplidas | Para un taller de Poka-yoke conviene un concepto que los englobe: condiciones de aceptaci贸n del proceso, aplicadas mediante puertas de calidad. Una puerta de calidad es simplemente un punto de decisi贸n que determina si el trabajo puede seguir, en funci贸n de unas condiciones especificadas. Con un matiz que se pasa por alto a menudo: **una puerta de calidad no es autom谩ticamente inspecci贸n en la fuente ni Poka-yoke.** Lo que determina eso es su momento y su mecanismo, no su existencia. ## **2\. Cada paso tiene una frontera de aceptaci贸n** La forma m谩s 煤til de mirarlo es imaginar que cada paso del proceso tiene una frontera. Algo llega, se eval煤a contra unas condiciones y solo entonces se decide si entra, si espera o si se devuelve. La frontera de aceptaci贸n La entrada se eval煤a antes de que el trabajo avance Trabajo entrante Solicitud, documento, transacci贸n, caso Comprobar las condiciones de aceptaci贸n Integridad 路 Validez 路 Elegibilidad 路 Preparaci贸n AceptarSigue adelante RetenerAclarar o corregir RechazarNo procede o no es v谩lido La decisi贸n de dise帽o importante no es si comprobar algo. Es qu茅 condiciones tienen que ser ciertas, c贸mo se verifican y qu茅 ocurre cuando no se cumplen. Esa tercera parte es la que m谩s se olvida: muchas organizaciones definen criterios y no definen qu茅 pasa con lo que no los cumple, as铆 que en la pr谩ctica todo acaba entrando igual. ## **3\. C贸mo conectan las condiciones de aceptaci贸n con la inspecci贸n en la fuente** Volvamos al encargo ambiguo del principio. Las condiciones que faltaban son perfectamente nombrables: - El problema u objetivo est谩 definido. - El resultado esperado est谩 identificado. - El alcance y las exclusiones se entienden. - Est谩 identificada la persona autorizada para aceptar el resultado. - Hay un criterio de terminaci贸n acordado. Eso son criterios de entrada del paso de an谩lisis. Un sistema puede exigir que se cumplan antes de que la solicitud pase a estado activo, y eso es exactamente inspecci贸n en la fuente: comprobar las condiciones que permiten el error antes de la operaci贸n en la que ese error har铆a da帽o. Es la misma l贸gica que est谩 detr谩s de [las nueve preguntas para dise帽ar un Poka-yoke](https://www.consultoriaprocesos.com/nueve-preguntas-poka-yoke/). Ahora bien, rellenar campos no garantiza claridad. Una solicitud puede tener texto en todas las casillas y seguir siendo ambigua. **Algunos criterios de calidad requieren juicio humano, y pretender automatizarlos del todo es una forma elegante de enga帽arse.** ## **4\. Tener criterios no es lo mismo que hacerlos a prueba de errores** Entre no tener nada y tener un mecanismo que impide avanzar hay cuatro niveles bastante distintos, aunque los cuatro se describan en las reuniones como "tenemos un criterio". | Nivel | Ejemplo | Fuerza preventiva | | -------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------- | | **1\. Sin criterios expl铆citos** | "Aseg煤rate de que la solicitud est茅 clara" | Depende por completo de la interpretaci贸n de cada persona | | **2\. Criterios documentados** | Un procedimiento lista la informaci贸n requerida | M谩s consistente, pero sigue dependiendo del cumplimiento | | **3\. Validaci贸n inmediata** | El formulario avisa al enviar de lo que falta o no es v谩lido | Retroalimentaci贸n autom谩tica, menos dependencia de la memoria | | **4\. Aceptaci贸n condicionada** | La solicitud no entra en cola activa hasta que se cumplen las condiciones esenciales | Impide de verdad que avance lo inv谩lido | Los niveles 3 y 4 son donde caben los mecanismos Poka-yoke. Pero su fuerza depende de si la validaci贸n comprueba de verdad la condici贸n que importa. Un campo obligatorio llamado "Alcance" es d茅bil si quien solicita puede escribir "por determinar". Uno m谩s fuerte obligar铆a a elegir una categor铆a de servicio definida, un tipo de entregable y, para lo genuinamente incierto, una opci贸n expl铆cita de exploraci贸n acotada. **Un campo obligatorio no es necesariamente una puerta de calidad.** Es, muchas veces, solo un obst谩culo que la gente aprende a sortear en tres segundos. ## **5\. Cinco tipos de condiciones de aceptaci贸n 煤tiles en el trabajo de oficina** A la hora de ense帽ar esto, funciona bien dar cinco categor铆as para buscar. No son exhaustivas, pero cubren casi todo lo que aparece en procesos administrativos y de servicio. | Condici贸n | La pregunta | Ejemplo | Mecanismo posible | | ---------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **Integridad** | 驴Est谩 presente todo lo necesario? | Una solicitud de contrataci贸n incluye puesto, presupuesto, responsable y competencias | Entradas estructuradas obligatorias que se帽alan qu茅 falta en concreto | | **Validez** | 驴La informaci贸n es correcta y coherente consigo misma? | El identificador de proveedor de una factura coincide con un proveedor aprobado | Validaci贸n autom谩tica contra los datos maestros | | **Elegibilidad** | 驴Este caso corresponde aqu铆? | Una compra entra dentro de una categor铆a y un presupuesto aprobados | Reglas que derivan lo no elegible a la v铆a adecuada | | **Preparaci贸n** | 驴Est谩n cumplidos los prerrequisitos de la siguiente operaci贸n? | Un documento no se libera antes de las aprobaciones t茅cnicas y de calidad | Enclavamientos de flujo y secuencia obligatoria | | **Idoneidad** | 驴El resultado va a servir para lo que hace falta? | Un informe responde a la decisi贸n que lo motiv贸 | Pregunta de decisi贸n acordada y prueba de aceptaci贸n, con revisi贸n estructurada | La quinta es la importante y la que peor se deja automatizar. Se puede verificar autom谩ticamente que un informe contiene una conclusi贸n. **No se puede verificar autom谩ticamente que la conclusi贸n sea s贸lida.** El trabajo de conocimiento no se reduce del todo a reglas binarias, y conviene decirlo en el taller antes de que alguien intente convertir el criterio de idoneidad en una casilla. ## **6\. Ejercicio: dise帽a una puerta de calidad** Imagina que tu organizaci贸n recibe solicitudes de mejora de procesos y que algunas llegan sin informaci贸n suficiente para empezar a trabajar en serio. El objetivo es impedir que lo ambiguo entre en la cola activa. 驴Qu茅 condiciones har铆as obligatorias? - Un problema u objetivo claro: s铆. Quien solicita dice qu茅 quiere cambiar o entender. - Un entregable esperado, o una exploraci贸n acotada: s铆. Incluso lo exploratorio puede tener un resultado identificable. - Un responsable que pueda aclarar y aceptar: s铆. Sin alguien que acepte, no hay criterio de terminaci贸n posible. - Un alcance definido, o al menos un l铆mite inicial expl铆cito: s铆. Evita el encargo sin fondo. - Una soluci贸n completamente especificada: no. Limitar铆a la resoluci贸n del problema antes de entenderlo. - Una fecha exacta de entrega: no para aceptar. Es 煤til para planificar, pero no es una condici贸n de entrada. Las dos 煤ltimas son las interesantes del ejercicio, porque parecen rigor y en realidad son ruido. Exigir la soluci贸n convierte la mejora en ejecuci贸n de una idea ya tomada, y exigir fecha antes de entender el trabajo produce fechas inventadas, que es peor que no tener ninguna. ## **7\. Los tres m茅todos de Shingo, traducidos a condiciones** Esta tabla funciona muy bien como ejercicio de taller, porque obliga a pensar qu茅 se comprueba y no solo qu茅 se exige. | M茅todo | Condici贸n que comprueba | Ejemplo en oficina | | -------------- | ----------------------------------------------- | ------------------------------------------------------------------------------ | | **Contacto** | 驴El elemento tiene la caracter铆stica requerida? | El identificador y el estado del documento coinciden con la versi贸n autorizada | | **Valor fijo** | 驴Se ha hecho el n煤mero requerido de cosas? | Est谩n los tres adjuntos obligatorios | | **Secuencia** | 驴Se han hecho los pasos en el orden necesario? | La revisi贸n t茅cnica precede a la aprobaci贸n final y a la liberaci贸n | Son an谩logos digitales bastante fieles de los m茅todos de Shingo, aunque menos inequ铆vocos que sus equivalentes f铆sicos. La lecci贸n de fondo no es clasificar bien cada ejemplo, sino dise帽ar un mecanismo que compruebe la condici贸n concreta que importa. ## **8\. La paradoja: prevenir tambi茅n puede convertirse en burocracia** Se introduce una puerta de calidad para evitar un defecto. Luego otra. Luego otra m谩s. Al cabo de dos a帽os la organizaci贸n tiene decenas de campos obligatorios, aprobaciones, validaciones y puntos de control. El trabajo se ralentiza, la gente encuentra atajos y las solicitudes empiezan a llegar rellenas con informaci贸n de relleno. El sistema se ha vuelto excelente haciendo cumplir sus propias reglas, **y no necesariamente produciendo calidad.** Es la misma din谩mica que describ铆 en [cuando la estructura que creaste se convierte en el problema](https://www.consultoriaprocesos.com/cuando-la-estructura-se-convierte-en-el-problema/): un mecanismo creado para resolver algo que termina generando el problema que ven铆a a evitar. Por eso una buena puerta de calidad deber铆a pasar tres pruebas antes de existir. - Necesidad: 驴el criterio responde a un riesgo o a un requisito real, o a un susto de hace tres a帽os? - Eficacia: 驴comprobarlo evita de verdad el error, o solo documenta que alguien mir贸? - Proporcionalidad: 驴el beneficio preventivo compensa el esfuerzo, la demora y la complejidad que a帽ade? Y un principio de dise帽o que vale para casi cualquier proceso administrativo: **aplica el control m铆nimo necesario en el punto m谩s temprano en que sea eficaz.** No el m谩ximo n煤mero posible de controles en todos los puntos disponibles. ## **9\. Un marco de siete pasos para el taller** Para trabajarlo en grupo, esta secuencia da buen resultado porque obliga a pasar del "deber铆amos tener m谩s cuidado" a un mecanismo concreto. 1. **Define el defecto.** 驴Qu茅 resultado inaceptable queremos evitar? 2. **Localiza el punto de error.** 驴En qu茅 operaci贸n puede producirse la acci贸n incorrecta? 3. **Define la condici贸n de aceptaci贸n.** 驴Qu茅 tiene que ser cierto para que esa operaci贸n transcurra bien? 4. **Determina c贸mo verificarla.** 驴Se puede medir, comparar, contar o comprobar en secuencia? 5. **Dise帽a el mecanismo.** 驴Podemos impedir la acci贸n inv谩lida, o al menos se帽alarla al instante? 6. **Define la respuesta.** 驴Aceptar, retener para corregir, rechazar o escalar? 7. **Prueba y mejora.** 驴Evita el defecto sin introducir un desperdicio nuevo desproporcionado? El paso seis es el que m谩s se salta la gente, y es el que convierte un criterio en una puerta. Sin respuesta definida, lo que no cumple la condici贸n entra igual, con una nota. ## **La distinci贸n que lo ordena todo** **Los criterios de aceptaci贸n definen qu茅 es aceptable. La inspecci贸n en la fuente decide cu谩ndo y d贸nde se comprueban esas condiciones. El Poka-yoke aporta el mecanismo que hace la comprobaci贸n fiable y, cuando se puede, impide que lo inaceptable avance.** Las tres cosas juntas permiten pasar de un proceso que depende de que alguien se d茅 cuenta y corrija, a uno dise帽ado para que el problema no surja o no se propague. Y en trabajo de oficina, donde casi nada se puede medir con un calibre, la pregunta m谩s 煤til acaba siendo siempre la misma: > 驴Qu茅 tiene que ser cierto antes de que este trabajo pase al siguiente paso? Dise帽ar estas condiciones con los equipos que hacen el trabajo, y sobre todo decidir cu谩les no merecen existir, es parte de lo que hago en [consultor铆a de procesos](https://www.consultoriaprocesos.com/servicios/). Desde Barcelona, para toda Espa帽a, presencial o en remoto seg煤n lo que tenga m谩s sentido.