Hay una secuencia habitual en la mayoría de los proyectos de herramientas internas que no funcionan: el responsable de área describe el problema, alguien propone una solución tecnológica, se desarrolla o configura la herramienta, y tres meses después nadie la usa o solo la usa para una fracción de lo que se suponía que iba a resolver.
El diagnóstico retrospectivo siempre llega al mismo punto: se construyó algo antes de entender completamente qué se necesitaba construir.
La fase de discovery existe exactamente para evitar ese patrón. No es un trámite previo al proyecto real: es el paso que determina si el proyecto real va a resolver el problema correcto.
Nielsen Norman Group define el discovery como «la fase preliminar que implica investigar el espacio del problema, enmarcar los problemas a resolver y reunir evidencia suficiente antes de avanzar». [1]
Muchos equipos se lo saltan. Es también el factor más correlacionado con el fracaso. [2]
Porqué el jefe de área no es suficiente fuente de información
La primera reunión de un proyecto de herramienta interna suele tener la misma estructura: el responsable del área que encarga el proyecto explica lo que necesita en términos de funcionalidades («quiero un formulario que envíe notificaciones», «quiero un dashboard con estas métricas», «quiero automatizar este proceso»).
Esa descripción es genuina y útil, pero no es suficiente.
El responsable del área describe el proceso como debería funcionar, no como funciona realmente. Las excepciones, los workarounds, los casos que ocurren el 15 % del tiempo pero representan el 80 % de los problemas no suelen aparecer en esa primera conversación. [5]
Aparecen cuando se observa al equipo real trabajar, cuando se hacen las preguntas incómodas («¿y qué haces cuando eso no funciona?», «¿quién decide eso cuando la persona habitual está de vacaciones?») y cuando se revisan los Excel paralelos que el equipo usa porque el sistema oficial no cubre ese caso.
El 61 % de los profesionales que trabajan en proyectos de discovery reportan dificultades para conseguir buy-in interno. [2]
La resistencia habitual es: «ya sabemos lo que necesitamos, no hay que investigar más». El problema es que esa certeza precede sistemáticamente a los proyectos con más scope creep y más retrabajos.
Qué incluye un buen proceso de discovery en proyectos de herramientas internas
Observación del proceso real, no del proceso descrito
El primer paso es entender cómo funciona el proceso hoy, con todas sus imperfecciones. Eso requiere observar cómo trabaja el equipo real (no el flujo ideal del diagrama), revisar las herramientas que usan en paralelo al sistema oficial y mapear qué pasa cuando algo se sale del flujo habitual.
Los workarounds que un equipo ha desarrollado son el mapa más preciso de los gaps del sistema actual. [5]
Identificación de las excepciones antes de diseñar el flujo principal
Gartner identifica la falta de gestión de excepciones en el diseño inicial como uno de los tres patrones recurrentes de fracaso en proyectos de automatización. [6]
Un proceso que funciona bien en el 85 % de los casos y falla en el 15 % restante no está resuelto: está parcialmente resuelto, lo cual puede ser peor que no tenerlo.
El discovery mapea los casos extremos antes de que el equipo de desarrollo empiece a construir.
Definición de quién va a ser el propietario del proceso automatizado
Una herramienta interna en producción es software en producción. Cuando algo falla, alguien tiene que saber que es responsable de arreglarlo. [6]
Si ese alguien no está identificado antes del go-live, la herramienta es una deuda técnica con fecha de vencimiento.
El discovery incluye esta pregunta de forma explícita: no como detalle organizativo, sino como requisito del proyecto.
La diferencia entre una consultora que ejecuta y una consultora que entiende no está en la calidad del código.
Está en qué preguntas se hacen antes de escribir la primera línea.
El 62 % de la brecha entre el potencial de automatización y la automatización real se explica por deficiencias en el diseño del proceso, no en la tecnología. [7]
El discovery es donde se evita ese 62 %.
Referencias
1. NielsenNorman Group. (2024). Discovery: Definition.https://www.nngroup.com/articles/discovery-phase/ — La fase dediscovery es una fase preliminar en el proceso de diseño UX queimplica investigar el espacio del problema, enmarcar los problemas aresolver y reunir evidencia suficiente y dirección inicial sobre quéhacer a continuación. Muchos equipos se saltan este paso importantepero es crucial para construir lo correcto.
2. NielsenNorman Group. (2024). How Well Discovery Phases Are Performed in UXProjects.https://www.nngroup.com/articles/discoveries-in-industry-revealed/ —En una encuesta a 436 profesionales UX, el 75% reporta que suorganización realiza fase de discovery, pero muchas son demasiadocortas, carecen de investigación con usuarios reales y no involucrana las personas correctas. El 61% de los comentarios sobre barrerasmencionan falta de buy-in: los stakeholders no ven el valor deldiscovery y presionan para ir directamente a la solución.
3. Netguru.(2025). Design Process for Pros — Discovery.https://www.netguru.com/resources/design-process/discovery — Unerror frecuente en el proceso de diseño es saltarse o abreviar lafase de discovery, con empresas que van directamente a generarsoluciones basadas en suposiciones. Ese salto puede llevar asoluciones que no abordan los problemas reales, o peor, que abordanproblemas que casi no existen.
4. PanoramaConsulting Group. (2024). 2024 ERP Report. Panorama Consulting.https://www.panorama-consulting.com/resource-center/erp-report/ —El factor más citado en el fracaso de proyectos ERP es laindefinición del alcance durante las fases de diseño (scope creep).Las implementaciones exitosas tienen en común que definen conprecisión qué procesos quedan fuera del sistema y cómo se van aresolver de otra manera. Sin ese diagnóstico previo, cualquierproyecto de herramienta interna replica el mismo patrón.
5. ProCodersTech. (2025). UX Discovery Process from Experts: Pitfalls andBottlenecks.https://procoders.tech/blog/ux-discovery-process-pitfalls-and-bottlenecks/— El discovery implica observar a los usuarios reales en sucontexto real, no solo hablar con el jefe de área que hace elencargo. Las excepciones al proceso habitual, los workarounds que losequipos han desarrollado y los casos extremos que ocurren el 15% deltiempo son exactamente lo que no aparece en la primera reunión peroque rompe cualquier herramienta que no los contemple.
6. Gartner.(2024). How to Build a Business Case for Process Automation. GartnerResearch. Los tres patrones recurrentes de fracaso en proyectos deautomatización identificados por Gartner son: automatizar el síntomaen lugar del proceso raíz, ausencia de ownership claro del procesoautomatizado, y falta de gestión de excepciones en el diseñoinicial. Los tres son detectables con un discovery bien ejecutadoantes de comenzar el desarrollo.
7. Deloitte.(2023). Automation with Intelligence: 2022 Global Automation Survey.Deloitte Insights.https://www.deloitte.com/us/en/insights/topics/talent/intelligent-automation-2022-survey-results.html— Deloitte identifica que el 62% de la brecha entre el potencial deautomatización y la automatización real se explica por deficienciasen el diseño del proceso, no en la tecnología. Las organizacionesque realizan un mapeo de proceso previo a la implementación logranen torno a un 23% más de adopción.
Heading
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Artículos destacados
Explora nuestros últimos artículos y tendencias.
