La gestión de requerimientos en la modernización de aplicaciones

En términos generales, el éxito de una organización depende de tres variables fundamentales: el personal que la constituye, el nivel de definición y ejecución de los procesos que sigue y las herramientas que apoyan a sus procesos. Suponiendo entonces que se cuenta con gente calificada y comprometida con los intereses de la organización así como con un proceso razonablemente bien definido tanto en el ámbito operativo como el administrativo, quedan entonces las herramientas como el factor para instrumentar un proceso de forma eficiente.

Muchas organizaciones dependen de las herramientas que hayan elegido para apoyar su operación y más aún si se habla específicamente de los Sistemas de Información o aplicaciones que sustentan su actividad principal, por ejemplo, sería francamente impensable que alguna institución bancaria, de seguros o retail no dependan 100% de sus Sistemas de Información. Y en un mundo globalizado y cada vez más competido, las aplicaciones pueden ser vitales para diferenciarse de la competencia. Por ende, la actualización de estas aplicaciones es un camino que tarde o temprano deberá recorrerse debido a circunstancias diversas tales como el crecimiento del negocio, adecuaciones regulatorias, cambios de infraestructura, etc.

Por otro lado, hay empresas que probablemente cuentan con aplicaciones que tienen una edad equiparable a la vida de la empresa misma, que almacenan y procesan no solamente información sustancial de su operación, sino también conservan toda las reglas de negocio que constituyen el proceso operativo mediante un mantenimiento que es correctivo o evolutivo, pero que no está orientado hacia la mejora (o actualización) de su infraestructura.

La vigencia de estos sistemas dependerá de muchos factores entre lo que destaca la facilidad para adaptarse a los requerimientos que demanden las distintas instancias implicadas en su funcionamiento; si esta facilidad disminuye paulatinamente para un sistema, a la postre la aplicación se convertirá en un Sistema Legacy.

Evaluando la modernización

Si la aplicación es un producto adquirido que contempla el cambio de versión del software como es el caso de un ERP, la actualización por esta vía puede ser a primera vista una opción atractiva. Sin embargo, se debe evaluar la versión a la que se desea actualizar considerando la infraestructura que será requerida (y por supuesto, el tiempo de vida estimado de la misma) para instalar la nueva versión así como la funcionalidad extendida que se ha construido alrededor del producto base que también deberá actualizarse; en ocasiones el esfuerzo y tiempo requerido para rescatar estas personalizaciones son equiparables a un desarrollo nuevo y podrían hacer inviable la actualización.

Como otra opción de modernización para este tipo aplicaciones, existen estrategias como la implementación de SOA, lo que al final permite prolongar su vida útil; sin embargo, obviando por un momento el enorme esfuerzo que implicará un proyecto de esta naturaleza, invariablemente llegará el momento en que su modernización implicará la sustitución ¿Por qué? Porque su infraestructura (hardware y software) está sujeta al mantenimiento contratado con los fabricantes de la misma, lo que aplica también para aquellas aplicaciones que  fueron desarrolladas (ya sea como parte de un producto comercial o un desarrollo propietario) con una tecnología cuyo framework, IDE, etc.  también están sujetos a una actualización constante, y por ende, indudablemente su fabricante dejará de invertir en actualizaciones y correcciones.

Por supuesto, siempre se puede correr el riesgo de continuar operando con la infraestructura actual dejando de lado los beneficios  que incluye mantenimiento del fabricante, pero este riesgo se incrementa con el tiempo y seguramente bastarán un par de incidentes referentes al servicio no disponible para que se reconsidere esta estrategia.

Considerando estos escenarios, es factible que se determine como estrategia de la organización la sustitución del Sistema Legacy, lo cual representa un proyecto de grandes dimensiones en el que será primordial involucrar al área directiva como Sponsor y al resto de las áreas como interesados. Es decir, es importante aclarar desde el principio que no es un proyecto sólo de TI, pues aun cuando ésta sea el área ejecutora, el cambio tendrá impacto en la organización entera.

Gestión y desarrollo de requerimientos

Entre los muchos aspectos que se deben cuidar en un proyecto de este tipo para que sea exitoso, destacan la gestión y desarrollo de requerimientos dado que el establecer y acotar el alcance incide en diversas etapas y participantes del proyecto: la estimación del esfuerzo, la planeación, la definición de los criterios de aceptación, las pruebas, etc.  Por ende, los requerimientos deben documentarse de manera que tengan rastreabilidad a lo largo de todas las etapas del proyecto.

Al inicio, desde un punto de vista general, los requerimientos se clasificarán en dos grandes grupos: funcionales, que normalmente determinan el “qué”, y los técnicos, que resuelven el “cómo”. Comúnmente los requerimientos funcionales se identifican primero dado que la necesidad de negocio ya existe, mientras que los técnicos complementan otros aspectos como la integración con otros sistemas en términos de interfaces, procesos, datos, etc.

Sin embargo, en una transición tecnológica, el levantamiento de requerimientos funcionales se complicará por el hecho de que ya existe un marco de referencia: la funcionalidad del Sistema Legacy.  Es decir, para definir los requerimientos funcionales que deberá atender la nueva solución, será necesario revisar el proceso actual con el propósito de abstraer la funcionalidad que requiere el negocio para operar adecuadamente  y separarla de aquella que podía proporcionar el sistema por sus propias limitantes o porque así había sido definida en un principio.

Ciertamente será una labor complicada, pues conlleva el esfuerzo adicional de cuestionar procedimientos arraigados con la operación y replantear paradigmas, además de retomar todas aquellas solicitudes de mejora al sistema actual que no prosperaron por sus mismas limitantes. Por ende, un factor crítico de éxito será el involucrar al área operativa dejándole ver que lo esencial del proceso es el conocimiento que posee, mismo que debe capitalizarse para la definición del alcance del nuevo sistema.  

La evaluación

A partir de requerimientos, se completará la estrategia de actualización tecnológica, evaluando opciones que incluyen esencialmente un desarrollo nuevo o la adquisición e implantación de una aplicación comercial.  En este punto, se definirán no sólo los requerimientos técnicos sino además el peso que tendrán vs. los requerimientos funcionales. Es decir, al empezar a evaluar las posibles soluciones que eventualmente sustituirán al sistema actual ¿Se apostará a una renovación completa del marco tecnológico de referencia de la institución si las opciones así lo requieren? ¿O la factibilidad de utilizar la infraestructura actual será un factor de decisión entre las opciones evaluadas? Ambas opciones cuentan con pros y contras y a lo largo de este proceso, se determinará cuál será la postura que tomará la institución.

Si bien es cierto que para entonces ya existe una línea base del alcance esperado  del sistema determinada por los requerimientos iniciales, lo cierto es que en esta etapa los requerimientos funcionales y técnicos estarán cambiando, dejando de lado algunos o identificando otros nuevos, mismos que se seguirán revisando, ajustando y priorizando para constituir una solución final propuesta con una estimación preliminar de recursos, tiempo, esfuerzo y por supuesto, costos.

La ejecución

Durante la ejecución, la gestión de requerimientos seguirá vigente dado que con cada etapa del proyecto se conocerá con más detalle la implementación del proceso, con lo que cual se revelarán más incógnitas tales como será necesaria la migración de datos y qué información es susceptible de ser migrada o si es factible que la integración con otros sistemas, requiriendo para ellos pruebas de concepto o servicios de consultoría especializada. Incluso se pueden desprender nuevos desarrollos cuyos requerimientos deberán vincularse a los del proyecto inicial.

Aunado a esto,  existe un obligado empalme entre el proyecto de implantación de la nueva solución y la operación del sistema actual, lo que implica que si éste recibe mejoras que no pueden ser pospuestas al inicio de operación del nuevo sistema (y que pueden deberse al negocio o que son de índole regulatoria y por ende, obligatorias), dichas mejoras tendrán que administrarse como nuevos requerimientos cuya incorporación tendrá un impacto en tiempo, esfuerzo y costo.

En la recta final del proyecto, la adecuada gestión de requerimientos habrá sentado las bases de conocimiento suficientes para  generar matrices de pruebas funcionales y técnicas que sustenten los criterios de aceptación.

Conclusión

La modernización y/o sustitución de una aplicación puede ser un proyecto cuya dimensión dependerá de diversos factores que una organización identificará y ponderará para decidir y ejecutar su estrategia tecnológica. Sin embargo, la gestión de requerimientos será la piedra angular que dará visibilidad sobre diversos aspectos del proyecto, siendo así un factor crítico de éxito del mismo.