Análisis funcional de requerimientos

El punto donde se define el éxito de un proyecto

Por Ariana Barrios — Consultor de análisis de negocio | Txoól

Contexto e introducción

De acuerdo con mi experiencia en varios proyectos de tecnología, algunas empresas suelen omitir una etapa clave: el análisis de la necesidad del cliente. En lugar de invertir tiempo en entender el problema, se prioriza el avanzar rápidamente hacia el desarrollo, lo que coloquialmente se conoce como “tirar código”, sin un entendimiento previo del problema.

En estos contextos, incluso llegan a existir roles como el de analista programador, donde una misma persona se encarga de levantar requerimientos y desarrollar la solución. Sin embargo, este levantamiento rara vez implica un análisis profundo. En muchos casos, la interacción se limita a conversaciones con niveles directivos, preguntando qué es lo que se desea desarrollar, sin involucrar a los usuarios finales quienes realmente operan los procesos.

Tuve la oportunidad de vivir esta situación en el sector bancario. Cuando me integré a un proyecto, el desarrollo ya estaba concluido. No obstante, al momento de pasar a validación con los usuarios finales, surgió un problema importante: la solución no reflejaba la realidad operativa. Los propios usuarios comentaban que nunca habían sido consultados sobre sus necesidades ni sobre las problemáticas que enfrentaban en su día a día.

Esto llevó a que el proyecto tuviera que replantearse prácticamente desde cero. Fue en ese momento cuando se hizo evidente la necesidad de incorporar un enfoque más estructurado, incluyendo el rol del analista de negocio. A partir de mi participación en esta nueva fase, la instrucción fue clara: involucrarme directamente con el negocio, entender la operación y traducir las necesidades reales del usuario hacia el equipo de desarrollo y el área de tecnología.

Fue ahí donde comprendí que el análisis de requerimientos no consiste únicamente en documentar lo que el cliente dice que quiere, sino en entender lo que realmente necesita. Muchas veces, la diferencia entre ambos es lo que determina el éxito o fracaso de un proyecto. Esta situación es muy similar a la conocida analogía del “columpio”, donde lo que el cliente imagina, lo que el equipo construye y lo que el usuario realmente necesita terminan siendo cosas completamente distintas.

Además, esta problemática no es aislada. De acuerdo con el Project Management Institute, una de las principales causas de fracaso en los proyectos está relacionada con una definición inadecuada de requerimientos, lo que genera retrabajos, desviaciones en alcance y soluciones que no cumplen con las expectativas del negocio.

Identificación del problema

Con base en lo observado, fue claro que el problema no estaba en la tecnología, sino en todo lo que ocurrió antes del desarrollo. No se involucró a las personas correctas, particularmente a quienes realmente operaban el proceso en el día a día. Aunque existían manuales, estos estaban definidos por áreas y no desde una visión integral del proceso, lo que generaba que cada equipo se enfocara únicamente en su parte, sin considerar el impacto hacia las siguientes etapas.

Esto ocasionaba pérdidas de información, duplicidad de datos y retrabajos constantes, ya que distintos documentos contenían conceptos similares, pero sin una estandarización clara. Además, al no entender a fondo la operación, no se identificaron necesidades más profundas que iban más allá de definir requerimientos, como la necesidad de homologar campos en bases de datos, estandarizar documentos, alinear el lenguaje entre áreas y considerar distintos escenarios operativos.

También se hizo evidente la falta de comunicación entre el área de negocio y la  de tecnología. No existía una figura que lograra traducir las necesidades del negocio a un lenguaje técnico ni que pudiera conectar conceptos como datos, estructuras, reportes o prototipos con la realidad operativa. En este contexto, el problema no era únicamente qué se debía construir, sino que la organización no estaba alineada para definirlo correctamente.

En línea con lo anterior, estudios de McKinsey & Company señalan que aproximadamente el 70 % de las iniciativas de transformación digital no alcanzan sus objetivos y que uno de los factores principales es la desconexión entre las necesidades del negocio y las soluciones tecnológicas implementadas.

Análisis funcional de requerimientos

Desde esta perspectiva, antes de desarrollar cualquier solución, es necesario contar con un análisis estructurado que permita comprender la necesidad real del negocio. Este análisis no se limita a levantar requerimientos, sino que implica entender cómo funciona actualmente la operación, quiénes participan en ella y cuáles son los puntos críticos que afectan su desempeño.

Para lograrlo, es necesario apoyarse en metodologías que permitan analizar el proceso de forma integral, como Six Sigma, a través del ciclo DMAIC (Definir, Medir, Analizar, Mejorar y Controlar). Este enfoque permite estructurar el análisis desde la identificación clara del problema, el entendimiento del proceso actual (as-is), la medición de su desempeño, el análisis de causas raíz y la definición de mejoras alineadas a la necesidad del negocio.

Este tipo de enfoques permite pasar de un levantamiento tradicional de requerimientos a un análisis estructurado basado en evidencia, donde las decisiones no se toman únicamente por percepción, sino a partir de datos, validaciones con usuarios y entendimiento integral del proceso. Esto es especialmente relevante en contextos de transformación digital, donde no solo se busca automatizar, sino rediseñar la forma en la que opera el negocio.

En la práctica, el análisis funcional no se basa únicamente en entrevistas, sino en una combinación de técnicas que incluyen el levantamiento de procesos, la identificación de los involucrados, el análisis de cuellos de botella, retrabajos y oportunidades de mejora, ya sea a partir de la observación directa de la operación o del análisis de datos cuando estos están disponibles.

En muchos casos, especialmente en organizaciones con baja madurez digital, este entendimiento requiere involucrarse directamente con el usuario, mapear tiempos reales de ejecución, volúmenes de trabajo y validar cómo se realizan las actividades en la práctica, más allá de lo documentado.

Una vez entendido el proceso actual, el siguiente paso es diseñar un proceso objetivo (to-be), el cual debe ser validado de forma conjunta con los usuarios, así como con áreas de control interno o legales, cuando aplique. Este diseño suele construirse a través de talleres colaborativos, donde se alinean expectativas y se define una forma de trabajo más eficiente y estandarizada.

A partir de este punto, el análisis funcional comienza a traducirse en entregables más concretos, como prototipos, diccionarios de datos, estandarización de documentos, definición de reglas de negocio y especificaciones de requerimientos de software. Estos insumos permiten al equipo de tecnología desarrollar soluciones alineadas a la necesidad real del negocio.

Finalmente, el análisis no termina con el desarrollo, sino que continúa durante las pruebas, la validación con usuarios, la capacitación y el acompañamiento en la salida a producción, asegurando que la solución implementada realmente funcione en la operación.

Rol del analista de negocio

En este contexto, el rol del analista de negocio no es únicamente el de un analista de procesos, sino el de un perfil integral dentro de los proyectos. Su valor radica en la capacidad de ponerse en el lugar del usuario, comprender cómo opera en su día a día y entender los conceptos que utiliza para, posteriormente, traducirlos a un lenguaje que el equipo de tecnología pueda interpretar y desarrollar.

De acuerdo con el International Institute of Business Analysis, el analista de negocio es responsable de habilitar el cambio dentro de una organización, definiendo necesidades y recomendando soluciones que generen valor para los stakeholders. Esta definición refuerza que el rol no se limita a documentar, sino a generar entendimiento y facilitar la toma de decisiones.

El analista de negocio actúa como un puente entre dos mundos: el del negocio y el de la tecnología. Por un lado, requiere un entendimiento profundo de los procesos, las necesidades y las problemáticas reales del usuario. Por otro, necesita contar con conocimientos básicos de tecnología que le permitan comprender cómo se construyen las soluciones, cómo se estructuran los datos y cuáles son las limitaciones o posibilidades técnicas.

En mi experiencia, esto implicó capacitarme tanto en los procesos del sector bancario como en las herramientas y tecnologías que el equipo de desarrollo utilizaría. Esto permitió generar una comunicación más fluida entre todos los involucrados y asegurar que cada requerimiento tuviera un entendimiento común.

El valor del analista de negocio se refleja en su capacidad de alinear a todos los actores del proyecto, evitando interpretaciones erróneas y asegurando que lo que se construya responda a la necesidad real del negocio. Cuando este rol no existe o no se ejecuta correctamente, es común que los proyectos enfrenten retrabajos, desviaciones o soluciones que no cumplen con las expectativas.

Retos en proyectos de TI y transformación digital

A lo largo de distintos proyectos, uno de los principales retos, cuando no se realiza un análisis funcional adecuado o no existe un rol de analista de negocio, es la falta de entendimiento real de la operación. Es común que, durante la ejecución, los usuarios mencionen que ciertos aspectos no fueron considerados desde el inicio, con frases como “eso no se contempló” o “se me olvidó comentarlo”, lo que evidencia que el levantamiento inicial no fue lo suficientemente profundo.

Otro reto importante es la ausencia de documentación estructurada. No se trata únicamente de documentar por cumplir, sino de generar un sustento claro que permita que el conocimiento del proceso no dependa de las personas. Cuando esto no existe, los procesos se vuelven vulnerables, inconsistentes y difíciles de escalar o mejorar.

También es frecuente que se desarrollen soluciones que no responden a lo que el usuario realmente necesita. Esto puede deberse a interpretaciones incorrectas, falta de comunicación o, simplemente, a que no se validaron adecuadamente los requerimientos. Como resultado, se generan retrabajos, ajustes constantes y una percepción negativa del proyecto.

Adicionalmente, la falta de definición de indicadores, niveles de servicio (SLA) y métricas de desempeño limita la capacidad de evaluar si el proceso o la solución realmente están funcionando. Sin estos elementos, es difícil medir mejoras, identificar desviaciones o tomar decisiones informadas.

Finalmente, uno de los retos más relevantes es la falta de estandarización y comunicación entre áreas. Cuando cada equipo trabaja bajo sus propios criterios, sin un lenguaje común ni procesos alineados, se generan fricciones, duplicidad de esfuerzos y pérdida de eficiencia. En este sentido, muchos de estos problemas no se originan en la ejecución, sino en etapas tempranas, donde no se invierte el tiempo suficiente en entender el contexto, alinear a los involucrados y definir claramente los requerimientos.

Esto confirma que los problemas en los proyectos no suelen originarse en la ejecución, sino en la falta de entendimiento inicial.

Conclusiones

En entornos actuales, donde las organizaciones buscan ser más ágiles, digitales y orientadas a datos, el análisis funcional se convierte en un habilitador clave para lograrlo. No se trata únicamente de implementar tecnología, sino de asegurar que dicha tecnología responda a necesidades reales, esté alineada a procesos eficientes y sea adoptada correctamente por los usuarios.

A partir de lo vivido, uno de los principales aprendizajes es que el rol del analista de negocio suele ser subestimado dentro de los proyectos, cuando en realidad, es un elemento clave para que una iniciativa de tecnología o transformación digital pueda cumplir su objetivo.

Más allá de ser un rol aislado, funciona como un punto de conexión entre todas las áreas involucradas, permitiendo que las necesidades del usuario se traduzcan correctamente hacia las áreas responsables de diseñar e implementar soluciones. Su valor no radica únicamente en documentar requerimientos, sino en generar entendimiento, alinear expectativas y asegurar que todos trabajen bajo un mismo objetivo.

También es importante reconocer que la transformación no depende de un solo rol, sino de la colaboración entre negocio, tecnología y otras áreas de soporte. Sin embargo, este rol  juega un papel fundamental para que esta colaboración sea efectiva, facilitando la comunicación, estructurando la información y manteniendo el enfoque en la necesidad real del usuario.

Finalmente, la experiencia demuestra que el éxito de un proyecto no está únicamente en la solución tecnológica que se implementa, sino en el nivel de entendimiento que se logra desde el inicio. En este sentido, el análisis funcional se convierte en la base sobre la cual se construye cualquier iniciativa y el analista de negocio en el facilitador que permite que dicha base sea sólida, clara y alineada a la realidad del negocio.

Por ello, invertir en un buen análisis funcional no es un costo, sino un factor crítico de éxito.

Referencias

Project Management Institute. (2021). Pulse of the Profession. https://www.pmi.org/learning/thought-leadership/pulse

McKinsey & Company. (2018). Unlocking success in digital transformations. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/unlocking-success-in-digital-transformations

International Institute of Business Analysis. (2015). BABOK Guide v3. https://www.iiba.org/standards-and-resources/babok/