Un sistema de información es integral : Caso del MEP

Cuando escucho "error de sistema" en una plataforma de servicio me hierve la sangre porque existe como muletilla para decir "no le podemos atender".

Ahora con el problema del MEP se presta para que tengamos un caso de negocio propio y criollo. Para los críticos, que se aparecerán,  no soy parte de ese sistema, pero hay un conjunto de premisas que deben conocerse a la hora de desarrollar un sistema que lo hacen a uno participe del mismo aunque sea una empresa externa.




Un sistema de información no es solo el software, las computadoras, las redes y los servidores ( y cuanto artefacto que se llame hardware), esa es la parte que la mayoría llama sistema, pero no es así.
Un sistema esta compuesto por la tecnología, la gente y la administración de la organización. Cuando escucho que "el sistema esta caído" imagino a las computadoras en fuego, a los usuarios enfermos y a los gerentes con la cabeza dando vueltas de la borrachera del día anterior (exagero, lo sé, pero esa es mi imagen mental).

¿Por qué creo que cuando una empresa hace el software, siendo externos son los responsables? Porque se asume que sumarán su experiencia en el desarrollo de sistemas, no solamente de programación y configuración de artefactos: deben coordinar con los usuarios y administración la correcta implementación y documentar los problemas. Hay empresas que piensan es programar y hacer botellas.

Si realmente la empresa externa de desarrollo hizo bien su trabajo debieron detectar los problemas relacionados al ingreso de datos y errores de administración que podrían poner en riesgo un sistema y advertir en papel a la administración de sus actos y la de sus usuarios: su valor es ver el fujo de la información no del teclado para adentro.

En experiencia que he tenido con las empresas que cotizan para el gobierno he tenido la lamentable experiencia de encontrar muchos males:

Proveedor:

• Entregan productos con interfaces complejas que confunden al usuario y no son fáciles de usar. Muchas veces la contraparte ignora la usabilidad o al usuario y acepta esos "hulk" mal hechos.
• Intentan minimizar sus errores de desarrollo atribuyéndolos a requerimientos "extraños".
  Esa es la tarea del ingeniero.
• No se hacen responsables por la "gestión del cambio" ni colaboran con ella. Se les paga por el conocimiento general pero piensan se les paga por programar.
• No se ajustan a las necesidades de la redes, en general son lentos. "Somos desarrolladores no conecta cables, eso tendrán que verlo ustedes" - frase real de una empresa.
• Se tuercen a las necesidades de la administración y no de la realidad de los usuarios.
  Muchas veces son de hacer y no preguntar, hacen lo que dice el gerente sin un levantamiento de requerimientos. 
• No hay plan B, la contingencia y los riesgos no existen.
• Cuando el usuario esta en el campo nunca aparecen, salen con la frase de "solo les pasa a ustedes".

Cito problemas de la administración:

• Imponen sistemas como solución per se. Soluciones mágicas y de punta.
• Los usuarios seleccionados (para delinear los requerimientos) no son los más apropiados.
• No exigen pruebas de rendimiento y de fuego a los sistemas. Muchas veces porque se ignora como.
• Creen en el nuevo software pero no invierten en redes, seguridad o capacitación...
• Se casan con una idea sin estudiarla.Hay un síndrome de no querer botar lo viejo que no sirve por la inversión y meterle dinero aunque sea caso perdido.
• Se asume el sistema es perfecto. No hay plan B, la contingencia y los riesgos no existen. Aún hoy la solución manual puede ser necesaria.
• No piensan en el manejo del cambio. La gente debe de usar el sistema y punto.
• Hacen el cambio en el peor momento.
• Muchas veces ni el departamento de TI (Sistemas) está involucrado en el proyecto. He visto proyectos que se hacen porque los de TI somos los malos y decimos que no a proyectos sin pies ni cabeza o hechos a medias.

Problemas de la gente (organización)

• No quieren usar el sistema porque los afecta (les cuesta mas, les pagan menos, etc)
• No entienden el cambio: esto por un error de administración.
• Crean caos para no pasarse al nuevo sistema. Crean correo negro e incluso engatusan a la administración echándole la culpa a la programación.

Lamentablemente es parte que exista un gerente de proyecto o TI que sepa balancear y detectar estos problemas, y es quién debe ser el árbitro de este partido, como dije muchas veces se le entrega el poder al proveedor y se espera sea bueno y entregue una panacea pero es una caja de Pandora.