Recientemente se dio a conocer que la consultora Deloitte fue inhabilitada por 5 años para participar en contratos públicos en México, derivado de las irregularidades y problemas en la operación del Sistema Juicio en Línea (SJL).
Es raro que en México sucedan este tipo de cosas. Y no porque no haya proyectos fracasados, sino porque rara vez esto llega a consecuencias legales y se da a conocer públicamente.
Así que aprovechando que esto ya está a la luz, en SG consideramos que vale la pena analizar el caso para entender lo que sucedió, no con el fin de echar tierra sino con el afán de como industria y profesionistas podamos aprender de este caso.
El contexto y sistema en cuestión
Como su nombre lo indica, el Sistema de Juicio en Línea (SJL) es un sistema de información cuya principal función es gestionar digitalmente el flujo de trabajo de los casos atendidos por el Tribunal Federal de Justicia Fiscal y Administrativa (TFJFA). En promedio, un juicio dura 1,372 días (cerca de 4 años) así que el principal beneficio esperado del SJL era agilizar la gestión de casos para reducir la duración de los juicios [1].
El sistema fue contratado en abril del 2010 (después de una licitación desierta) y desarrollado durante 2010 y 2011. El cliente argumenta que desde su puesta en marcha inicial en agosto de 2011, el sistema presentaba fallas de estabilidad y desempeño y como resultado los usuarios se resistieron a usarlo. Durante dos años el proveedor estuvo realizando mantenimiento y ajustes con el objetivo de corregir las fallas, pero en 2014 el sistema seguía sin cumplir las expectativas y como consecuencia es poco usado (menos del 2% de los casos del TFJFA en 2014 fueron manejados en el SJL) [2]. Tenemos entendido que el sistema sigue en operación (el sitio web del TFJFA lo menciona en su sitio web) pero desconocemos qué tanto se use actualmente.
Antipatrones detectados
En base a la información que tenemos hasta el momento, detectamos la presencia de varios antipatrones que desgraciadamente son comunes en este tipo de proyectos. Los describimos a continuación.
La ilusión del megasistema todopoderoso
Aunque no disponemos de la lista de requerimientos en base a los que fue diseñado el sistema, la descripción que hemos visto sobre el proyecto nos hace pensar que fue ideado como un megasistema, derivado de un rediseño integral de los procesos operativos de la institución.
Muchos en la industria nos hemos encontrado con este tipo de proyectos, que buscan automatizar toda la operación por medio de un megasistema, y muchos sabemos que dichos proyectos rara vez son exitosos.
Claro que es válido tener una visión ambiciosa sobre una operación integral automatizada de toda una organización, pero el problema está en pretender lograr todo mediante un solo sistema.
Al parecer, en el caso de este sistema se pretendió mitigar esto por medio de una arquitectura orientada a servicios, pero bien sabemos que esto no es una varita mágica.
Poca atención a los requerimientos no funcionales
De acuerdo con el informe de cuenta Pública 2013 de la Auditoría Superior de la Federación [3], “durante los 39 meses que este Sistema ha estado en funcionamiento, no se ha logrado la estabilidad y operación eficiente, lo que no satisface los requerimientos solicitados por el Tribunal desde la convocatoria que dio origen al contrato TFJFA-DGRMSG-048/2010, en donde los proveedores ofrecieron el 99.999% de disponibilidad y 10 segundos de tiempo de respuesta por transacción” … “de manera generalizada ... el Sistema de Justicia en Línea presenta interrupciones y con ello detiene el flujo del expediente, o bien, se vuelve lento (1 a 3 minutos en responder), en lugar de los 10 segundos por transacción comprometida en el contrato”.
Este es el principal problema del SJL. Una cosa es corregir aspectos de funcionalidad o interfaz de usuario, lo cual se puede ir haciendo poco a poco como parte del mantenimiento de una aplicación, pero otra cosa completamente distinta es corregir un problema de este tamaño. Eso requiere rehacer el sistema completo, con una arquitectura distinta.
El antipatrón aquí es ignorar los requerimientos no funcionales, o no darles la prioridad adecuada, desde el inicio del proyecto. La máxima del desarrollo iterativo es que en las primeras etapas del proyecto se atacan y resuelven los principales riesgos del proyecto, y en la mayoría de los casos esos riesgos son no funcionales. Desgraciadamente, es común que, ya sea por ignorancia o negligencia, esto se deje al final y se pretenda resolver “metiéndole más galleta al servidor”.
Elegir un stack tecnológico por razones comerciales
Al preguntar a uno de los desarrolladores involucrados en este proyecto cual consideraba que había sido el principal problema, su respuesta fue: “haber elegido un stack tecnológico en base a intereses comerciales”. Específicamente, se refiere a que se eligió todo el stack de cierta marca, simplemente porque el proveedor es partner y se lleva una comisión al incluir dichos productos en sus soluciones.
Es cierto que las herramientas no tienen la culpa por sí solas; es posible crear malos sistemas con cualquier herramienta si no sabes lo que haces. Pero elegir herramientas por intereses comerciales y no de solución, hace las cosas todavía peor.
Acerca de la investigación
Nuestra intención es realizar una investigación técnica y operativa sobre cómo se realizó el proyecto. Hasta el momento solo hemos logrado obtener información de una persona que participó en el proyecto, quien nos pidió anonimato. Hemos pedido hablar con más personas involucradas, de ambas partes, y en cuanto obtengamos mayor información generaremos notas adicionales.
Referencias
- "Sistema de Justicia en Línea ha sido un desastre". Diario.mx. Nota original de Reforma. http://swgu.ru/sd
- “Sistema de Juicio en Línea”. Deloitte. http://swgu.ru/sc
- “Auditoría Financiera y de Cumplimiento: 13-0-32100-02-0047. Aprovechamiento de Recursos, Infraestructura y Servicios de TIC“. Tribunal Federal de Justicia Fiscal y Administrativa. http://swgu.ru/sb
- Log in to post comments