Una tabla de decisión convierte un conjunto de reglas de negocio en combinaciones de condiciones y resultados. Coloca las condiciones en columnas, dedica una fila a cada regla e indica qué debe ocurrir cuando esa fila se cumple. La prueba más útil es sencilla: toma una entrada plausible y comprueba si la tabla devuelve exactamente el resultado previsto.
Por ejemplo, un equipo de soporte puede derivar un reporte a distintos destinos según si afecta al entorno de producción, si bloquea el flujo habitual de trabajo y si existe una alternativa temporal. La tabla permite comparar esas combinaciones. Después, un diagrama de flujo muestra dónde encaja esa decisión dentro del proceso completo.
Cuándo una tabla de decisión resulta más clara que un diagrama de flujo
Usa una tabla de decisión cuando varias entradas determinan conjuntamente un resultado y necesitas comparar las reglas. Usa un diagrama de flujo cuando la pregunta principal sea qué ocurre primero, qué viene después y a dónde vuelve el trabajo tras una excepción. Ambos pueden describir el mismo proceso a diferentes niveles: dibuja el flujo de trabajo completo en Boardmix y coloca sus reglas de derivación junto a la decisión correspondiente.
Imagina un diagrama que pregunta «¿Afecta a producción?» y luego repite «¿Existe una alternativa?» en varias ramas. Es difícil detectar que dos ramas conducen a destinos contradictorios. En una tabla, la pregunta repetida ocupa una sola columna. Puedes comparar las filas sin seguir flechas que se cruzan.
Una tabla de decisión no es una matriz de decisión. Una matriz puntúa alternativas según criterios como el coste o la facilidad de uso. Una tabla evalúa condiciones, como si un flujo en producción está bloqueado, y devuelve un resultado definido. Este ejemplo tampoco utiliza probabilidades ni calcula un valor monetario esperado.
Define las entradas antes de redactar las reglas
El siguiente caso representa un proceso de soporte hipotético, no la política de soporte de Boardmix. Su función es elegir un destino para la clasificación inicial, no prometer un tiempo de respuesta ni diagnosticar el incidente.
- Afecta a producción: el problema se produce en el entorno real utilizado para el trabajo habitual. Si solo ocurre en un entorno de pruebas, la respuesta es «No».
- Flujo habitual bloqueado: la persona afectada no puede completar la tarea por la vía normal. Un defecto meramente visual recibe un «No».
- Alternativa disponible: existe una vía temporal conocida que permite terminar la tarea. Una posible solución aún sin comprobar no cuenta como alternativa.
«Bloqueado» y «alternativa disponible» no son opuestos. La vía habitual puede estar bloqueada y, aun así, existir una ruta manual o alternativa que funcione. Anota esta distinción junto a la tabla; de lo contrario, dos personas podrían asignar entradas diferentes al mismo reporte.
En este ejemplo didáctico, las tres entradas deben conocerse antes de evaluar la tabla. Si el reporte no aclara si afecta a producción, primero se solicita información. Un valor desconocido no se convierte silenciosamente en «No».
Ejemplo completo de tabla de decisión
Cada fila representa una regla. «Cualquiera» significa que el valor no influye en el resultado de esa regla; no significa que falte información. El diseño exige una coincidencia única: una entrada completa debe coincidir con una fila, nunca con dos.
| Regla | ¿Afecta a producción? | ¿Flujo habitual bloqueado? | ¿Hay alternativa? | Destino |
|---|---|---|---|---|
| R1 | No | Cualquiera | Cualquiera | Cola del entorno de pruebas |
| R2 | Sí | No | Cualquiera | Soporte estándar |
| R3 | Sí | Sí | Sí | Soporte prioritario |
| R4 | Sí | Sí | No | Evaluación de incidentes |
Lee R3 como una frase: si el problema afecta a producción, bloquea el flujo habitual y existe una alternativa, deriva el reporte a soporte prioritario. El resultado es un destino. No significa que el problema esté resuelto.
Considera este reporte: «El botón de exportación falla en producción, pero la descarga de registros individuales funciona». Tras confirmar que esa descarga permite completar la tarea, las entradas son Sí / Sí / Sí. R1 no coincide porque producción está afectada. R2 no coincide porque el flujo habitual está bloqueado. R3 coincide. R4 no coincide porque sí existe una alternativa.
Cambia ahora solo el entorno: el mismo fallo ocurre en un espacio de pruebas. R1 coincide independientemente de los otros dos valores. Eso no convierte el defecto en algo irrelevante; simplemente aplica la política explícita del ejemplo. Si el equipo tiene otra política, debe cambiar la regla, no esconder una excepción en una nota.
Detecta reglas solapadas y entradas sin cubrir
Tres entradas booleanas generan ocho combinaciones posibles. R1 cubre cuatro, R2 cubre dos y R3 y R4 cubren una cada una. Estos grupos no se solapan, por lo que la tabla abarca todas las combinaciones booleanas.
Cobertura y corrección no son lo mismo. Una tabla puede cubrir todas las combinaciones y aplicar una política equivocada. Pide a la persona responsable de la derivación que revise los resultados, especialmente qué significan «prioritario» e «incidente» en su organización.
Estos dos errores habituales muestran la diferencia:
- Solapamiento: cambia la condición de bloqueo de R2 de «No» a «Cualquiera». Un flujo de producción bloqueado con una alternativa coincide ahora con R2 y R3. Un solo reporte tiene dos destinos.
- Hueco: elimina R3. Un flujo de producción bloqueado con una alternativa deja de coincidir con cualquier fila. Elegir la fila que más se parezca sería inventar una regla.
Las herramientas formales de modelado de decisiones denominan a este comportamiento política de coincidencia o hit policy. Según la explicación de Camunda sobre estas políticas, Unique no permite que coincidan varias reglas, mientras que First elige la primera regla coincidente. La diferencia importa: cambiar el orden de una tabla First puede modificar el resultado. No dependas del orden visual salvo que forme parte deliberada de la política.
La tabla de este artículo es un documento de planificación, no un modelo DMN ejecutable. Si el equipo de desarrollo la implementa en una aplicación o motor de reglas, deberá configurar allí los tipos de entrada, el comportamiento de coincidencia y el tratamiento de errores.
Prueba la tabla con casos concretos
Mantén los ejemplos junto a las reglas para que las consecuencias de cualquier cambio resulten visibles. Este conjunto breve recorre todos los destinos y la vía independiente para solicitar información:
| Caso | Entradas: producción / bloqueo / alternativa | Resultado esperado |
|---|---|---|
| Fallo de acceso solo en pruebas | No / Sí / No | R1: cola del entorno de pruebas |
| Una etiqueta se muestra mal en producción, pero la tarea funciona | Sí / No / No | R2: soporte estándar |
| Falla la exportación en producción; funciona otra descarga | Sí / Sí / Sí | R3: soporte prioritario |
| Falla la exportación en producción; ninguna alternativa permite terminar | Sí / Sí / No | R4: evaluación de incidentes |
| El reporte no identifica el entorno | Desconocido / Sí / No | Solicitar información; todavía no evaluar R1–R4 |
Si las reglas incluyen cifras o fechas, añade casos inmediatamente por debajo, en el límite y por encima de cada umbral. Si una regla dice «importe superior a 100», prueba 99,99, 100 y 100,01 con la moneda y precisión correspondientes. Decide si el límite está incluido antes de dibujar el diagrama. Una expresión como «solicitud grande» no puede probarse de forma consistente hasta que la organización la defina.
Prueba también un valor fuera del conjunto permitido. Si la entrada solo acepta Sí y No, un campo vacío, una errata o «probablemente» necesitan una vía de tratamiento explícita. Un destino por defecto debe ser una decisión consciente, no una forma de ocultar entradas inválidas.
Un formato reutilizable para tus propias reglas
Empieza con esta especificación breve y después añade las filas. Así, la tabla conservará su contexto cuando alguien la copie en un documento del proyecto.
- Decisión: ¿Qué única pregunta responde la tabla?
- Entradas: nombre, definición y valores permitidos de cada condición.
- Resultados: destinos, clasificaciones o acciones exactos que puede devolver.
- Coincidencia: una sola regla, la primera coincidencia u otra política intencional.
- Entradas desconocidas: ¿Qué ocurre antes de la evaluación cuando falta un dato necesario?
- Ejemplos: un caso habitual para cada resultado y casos límite para los intervalos.
En un lienzo de Boardmix, coloca las definiciones de entrada a la izquierda, la tabla en el centro y los reportes de ejemplo a la derecha. Usa los mismos identificadores de regla en la tabla y en las pruebas. Así, una persona puede señalar R3 en lugar de decir «lo tercero del centro». Mantén las preguntas de política aún sin resolver fuera de las filas aprobadas.
Una vez acordados los destinos, conecta la decisión con el flujo general: recibir el reporte, reunir los datos necesarios, evaluar las reglas y derivar el reporte. Abre Boardmix para documentar tu tabla de decisión y su flujo de trabajo.
