¿Debes cambiar el sistema o mejorar la ejecución?
Cuando la curva se tuerce, el movimiento reflejo es “ajustar algo”. Se retocan reglas, se encoge el tamaño o se añade un filtro sin saber si el problema vive realmente en el sistema o en la forma de aplicarlo. Diagnosticar esa diferencia no es un lujo; es la única forma de evitar parches costosos.
1. Por qué esta disyuntiva suele resolverse mal
1.1 Culpar al sistema antes de tiempo
Cambiar reglas es tentador porque es visible. Pero en cuanto tocas una pieza relevante, toda la evidencia anterior deja de describir lo mismo. Si las pérdidas vienen de omisiones, entradas fuera de criterio o salidas impulsivas, el sistema no está roto: la ejecución sí. Esa brecha sólo se detecta con un diario que muestre qué pedía la regla y qué hiciste de verdad.
1.2 Defender un sistema que ya no se sostiene
En el extremo contrario, el método necesita cada vez más “excepciones” para sobrevivir. Si la lógica depende de interpretaciones constantes, el problema es estructural y apunta a validación, no a disciplina.
1.3 Mezclar estructura y aplicación
Cuando modificas el sistema para tapar fallos de ejecución —o ejecutas mal un sistema sólido— pierdes comparabilidad y la discusión se vuelve circular. Si vas a tocar reglas, protégelas con el protocolo de cambios; si vas a revisar aplicación, hazlo antes de rediseñar.
2. Señales de que el problema es la ejecución
- Reglas claras, aplicación irregular. Omisiones, entradas “casi” válidas o salidas reactivas.
- Desviaciones repetidas. Los mismos fallos aparecen sesión tras sesión y el diario los recoge.
- Diferencia persistente entre plan y operativa. Lo ejecutado rara vez coincide con lo previsto.
Si las operaciones que respetan la regla muestran un comportamiento razonable, no toques el sistema: refuerza rutina y seguimiento.
3. Señales de que el problema es el sistema
- Reglas que exigen interpretación continua. Dos casos parecidos producen decisiones distintas.
- Evidencia débil. El método sólo “funciona” en el mismo tramo donde se diseñó.
- Fragilidad ante cambios mínimos. Variar ligeramente el contexto hunde los resultados.
Si esto sucede incluso con ejecución limpia, el foco es la calidad del diseño y la solidez de la evidencia, no la disciplina.
4. Proceso de discriminación en tres pasos
- Recolecta rastro fiable. Diario uniformado: previsto / ejecutado / resultado / desviación.
- Separa ejecución limpia de operaciones con brecha. Compara comportamientos.
- Corrige una sola palanca. Si la brecha se reduce, era ejecución; si no, revisa sistema o validación.
Corregir varias cosas a la vez destruye la atribución y te devuelve al punto de partida.
5. Errores que arruinan la decisión
- Modificar reglas para tapar mala aplicación.
- Operar igual esperando que “la racha cambie”.
- Cambiar varias variables simultáneamente.
- Basarse en resultados aislados.
6. Si todavía no está claro …
Cuando falte evidencia, pausa la urgencia de corregir y construye auditoría:
- Refuerza registro (diario).
- Respeta el sistema sin parches durante un bloque definido.
- Aplica documentación y checklists para cerrar ambigüedades.
- Revisa con la rutina de la revisión semanal si ya está publicada.
Sólo entonces vuelve a decidir: sistema o ejecución.
FAQ
¿Cómo saber si el problema es del sistema o de la ejecución?
Si el deterioro se concentra en operaciones con desviación, apunta a ejecución. Si aparece también cuando la aplicación es limpia, apunta a sistema / validación.
¿Cuándo conviene cambiar el sistema?
Cuando falta lógica reproducible, la evidencia es débil o la fragilidad se hace evidente incluso con buena ejecución.
¿Por qué no cambiar varias cosas a la vez?
Porque mezclar variables impide atribuir mejoras o empeoramientos a una causa concreta.
En TNT Bolsa trabajamos para que no cambies un sistema válido por culpa de una ejecución pobre, ni intentes salvar con disciplina un método que todavía no está bien sostenido.
