Ir al contenido

Lo que el cliente pide vs. lo que EmasT entrega

4 de septiembre de 2026 por
Lo que el cliente pide vs. lo que EmasT entrega
Juanita Gomez

Casi todo proyecto de tecnología empieza con una solicitud concreta: ”necesitamos automatizar la conciliación", "necesitamos un módulo de reportes”, "necesitamos integrar el CRM con la facturación". Y casi ningún proyecto termina siendo exactamente eso. En EmasT, la distancia entre lo que un cliente pide en la primera reunión y lo que finalmente se construye no es la excepción, es una tendencia, y tiene una causa identificable: el discovery no es un trámite antes del proyecto, es la primera entrega del proyecto.


Por qué el pedido inicial rara vez describe el problema completo

El pedido inicial casi siempre describe el síntoma más visible, no la causa. Un gerente de TI que pide un dashboard de inventario está señalando lo que ve todos los días, no necesariamente el proceso que produce el dato poco confiable que alimenta ese dashboard. Esto no es una falla de diagnóstico de quien pide: es la razón por la que existe el discovery. Una mirada externa, sin el sesgo de convivir a diario con el proceso, encuentra causas que desde adentro son difíciles de ver.


Qué cambia entre el pedido y la entrega

En la mayoría de los proyectos donde hemos hecho discovery en EmasT, el alcance final termina tocando al menos un proceso adicional al que se solicitó inicialmente, casi siempre uno que el cliente no identificaba como parte del problema. Un reporte que se pidió resulta ser síntoma de un proceso de captura de datos sin control. Una automatización de facturación termina incluyendo el flujo de aprobación previo, que era el verdadero cuello de botella. Una integración de sistemas revela que el problema no es la falta de conexión entre plataformas, sino que ambas guardan versiones distintas de la misma información. El pedido apunta al efecto, el discovery encuentra la causa.


El discovery como consultoría transversal, no como levantamiento de requerimientos

En la mayoría de las metodologías de proyecto, el discovery se entiende como un paso de levantamiento: documentar lo que el cliente necesita para después construirlo. En EmasT lo tratamos como algo más amplio. Durante el discovery no solo se analizan requerimientos, se identifican oportunidades de mejora que el cliente no había puesto sobre la mesa, y se contrastan sus procesos actuales con mejores prácticas del sector. Esta mirada adicional es, en la práctica, la forma concreta en que EmasT anticipa como un método de trabajo que se aplica desde la primera semana de cualquier proyecto.


Anticipar para dar claridad, y para definir qué significa "terminado"

Anticipar en el discovery no solo sirve para darle claridad al cliente sobre lo que realmente necesita. También sirve para algo que muchos proyectos de tecnología no dejan claro desde el principio: los criterios de aceptación. El resultado de un buen discovery es el conjunto de criterios que el cliente podrá usar al final del proyecto para evaluar, de forma objetiva, si la solución entregada cumple con la necesidad que se definió al comienzo. Sin esos criterios, la conversación de cierre de un proyecto se vuelve subjetiva, depende de qué tan bien recuerde cada parte lo que se acordó en la primera reunión. Con ellos, se vuelve una verificación, no una negociación.


Qué significa esto para quien lidera TI

Esto no es una ampliación de alcance no controlada, es diagnóstico funcionando como debería, con las reglas claras desde el inicio. La diferencia entre un ajuste de alcance bien manejado y uno que se sale de control no está en si el alcance cambia (casi siempre cambia), sino en si existía, desde el discovery, un criterio objetivo para evaluar ese cambio. Por eso vale la pena estructurar la conversación con cualquier proveedor de tecnología asumiendo desde el inicio que el discovery no es un paso previo al proyecto, es donde se define qué significa que el proyecto esté terminado.

Si tu equipo está por iniciar un proyecto de automatización, ERP o desarrollo a la medida, vale la pena empezar por ahí: no por el pedido, sino por el diagnóstico, y por los criterios que ese diagnóstico deja definidos para saber, al final, si el proyecto cumplió.

Conversemos sobre el discovery de tu próximo proyecto.

Lo que el cliente pide vs. lo que EmasT entrega
Juanita Gomez 4 de septiembre de 2026
Compartir
Etiquetas
Archivo