Las decisiones que se toman en T.I. pueden llevar a grandes problemas de sostenibilidad en las organizaciones.
Desafortunadamente, muchas de tales decisiones se toman a la ligera o, incluso, en función de intereses muy personales... he aquí un blog para señalar tales corrupciones y fracasos a fin de NO cometerlos.

Se debería usar software libre en las instituciones públicas siempre y cuando sea posible?

El Sistema Integrado Financiero Administrativo (SIFA), se estableció como el sistema encargado de centralizar en una sola plataforma tecnológica los datos sobre gastos de planilla, inversiones, créditos, cobros y proveeduría para el INS (Instituto Nacional de Seguros).
El mencionado sistema fue aprobado por la contraloría en el 2001, y arrancó en enero del 2002, con un plazo de 26 meses a un precio de ¢6.200 millones. El diario La Nación reveló que el sistema vigente no era compatible con el resto del sistema de cómputo, que administra la parte financiero-contable de la entidad.
Luego de tres años de intentos por enlazar el programa con el actual Sistema Integrado Financiero y Administrativo (SIFA), la compañía española Accenture le propuso al INS resolver el contrato.
Aunque fue el Instituto el incapaz de cumplir con las interfaces entre el programa actual y el SIFA, la compañía no cobró una indemnización por incumplimiento de contrato.
El plan para modernizar el sistema de cajas quedó disuelto en diciembre del 2005.
La consecuencia fue hacer de forma manual la facturación de proveedores del Instituto y eso origina trámites engorrosos y más lentos.
La Contraloría reprendió al INS por el tiempo que tarda en la renovación de las licencias de operación del SIFA. Sin esas licencias, el Instituto no tendría asistencia técnica en caso de que se presente un mal funcionamiento del programa o software.
Este sistema, aunque con problemas de actualización de la información, para el 2006 administraba las operaciones financieras y administrativas de 19 dispensarios, 228 consultorios médicos, 62 estaciones de Bomberos y 300 centros de costo en oficinas centrales y sucursales del INS.
Para concluir con la historia, el señor Guillermo Constenla (presidente del INS) argumentó que en la actualidad es imposible abrir procesos administrativos en contra de los funcionarios que compraron los programas y que se retrasaron en la renovación de licencias, porque muchos de ellos renunciaron a principios del 2006.

Es menos del 1% de la planilla, según Oficial Mayor
El Ministerio de Educación Pública (MEP) pagó en el 2004 ¢980 millones en salarios de más a funcionarios suyos.
Esta situación es provocada por la falta de automatización e integración de sus sistemas informáticos, la fuerte centralización administrativa, la falta de conexión informática con varias de sus oficinas regionales y errores en el software de pagos. Este último habría originado el 0,5% (¢5 millones) del monto total.
El MEP señaló que las cifras de salarios pagados de más representan menos del 1% de su planilla, los problemas indicados revelan las dificultades del desarrollo de los proyectos tecnológicos del Estado.
"No es solo un asunto informático. Implica romper mitos en las instituciones públicas", dijo Alberto Orozco, director de informática del MEP.

Inversión
Para reducir el problema de los pagos de más, el MEP deberá resolver varias asignaciones pendientes en tecnología.
En primer término, necesita un software de nómina que integre los sistemas que se implementaron a finales del 2002 para dejar atrás procedimientos manuales y automatizar la operación.
En segundo lugar, requiere contar con todas sus oficinas regionales conectadas. En este momento, la falta de líneas dedicadas u otros sistemas de conexión impiden integrar nueve despachos.
Pero también la entidad debe terminar de resolver los problemas del sistema de pagos. De acuerdo con Orozco, de informática del MEP, la situación del 2003 -cuando el software generó ¢2.500 millones de pagos de más- se revirtió con la solución de varios de los errores técnicos de ese programa.
El funcionario explica que desde ese año el MEP ha tenido que invertir en la solución de los errores técnicos, sistemas de contingencia y equipos. Con la adquisición del programa de nóminas que integre los módulos (acciones, expedientes y control, entre otros), toda esta inversión sumaría unos ¢300 millones.
Aunque el MEP y la Contraloría investigan responsabilidades administrativas y legales en este caso, las firmas que estuvieron involucradas en el diseño de este sistema -GBM de Costa Rica S.A. y Soluciones Integrales S.A.- dijeron que entregaron ocho módulos que les correspondía "a satisfacción" de la institución.


Empecemos por nuestra casa... Proyecto Innovare

by Carlos Juan Martín Pérez | 17:08 in | comentarios (0)

Pues sí, creemos honrado comenzar por señalar las equivocaciones que se cometen empezando por las atrocidades propias (y cuando decimos propias nos referimos a nuestra universidad anfitriona).

A lo largo de varios cursos realizados durante la Maestría en Administración en Tecnologías de la Información hemos señalado lo que, a nuestro humilde parecer, es un error mayúsculo desde el punto de vista de inversión en desarrollo tecnológico: el proyecto Innovare.

Antetodo, un poco de historia al respecto de dicho proyecto. Pueden consultar ustedes mismos/as tales antecedentes en http://www.una.ac.cr/innovare y, concretamente, en el documento http://www.una.ac.cr/innovare/DDP2.pdf, (aunque noten que, en dicho documento, "extrañamente" falta el anexo donde se detalla el presupuesto).

Aparte de tales déficits de información, podemos resumir que La Universidad Nacional de Costa Rica comenzó en el año 2004 el proyecto denominado “Innovare”, consistente en la introducción del sistema informático SCT Banner (página de la empresa) con el fin de agilizar y fiabilizar la gestión universitaria. A tal fin se adquirieron las licencias de los módulos de gestión académico-administrativa, finanzas y recursos humanos por un monto de 1,5 millones US Dólares.

Sin lugar a dudas, la antedicha iniciativa constituyó el mayor proyecto de transformación institucional emprendido en la UNA desde su creación, y para su plausible fructificación se creó una Oficina específica para su desarrollo, la cual estaría posicionada al más alto nivel de la estructura organizacional: no se escatimaron gastos ni esfuerzos.

Ya desde el comienzo se elevaron voces disonantes en contra del proyecto, tanto por su enorme costo como por las reservas en cuanto a la adaptación real de una infraestructura informática desarrollada para instituciones educativas estadounidenses a los procesos ya establecidos en la UNA, sumándole a tal dificultad la característica de ser una herramienta propietaria, lo que implicaba que su esencia no podría ser alterada de ninguna forma. Curiosamente, quienes entonces se quejaron ostensiblemente en contra del proyecto pasaron a gobernar la UNA y ¡los roles se invirtieron! ahora las personas que otrora estaban en el poder y participaron en la decisión de involucrar a la Universidad en tal gasto, son quienes argumentan en contra de los resultados (aunque ciertamente lo hacen con prudencia, pues un poco de investigación en las actas de las sesiones del Consejo Universitario podría sonrojar a más de alguna persona). Tales cambios de opinión no son de nuestro interés, a nosotros/as nos preocupan las motivaciones e implicaciones tecnológicas del asunto, pero quizá especialistas de historia universitaria puedan ampliar este tema en el futuro.

En la toma de la decisión de la adquisición de tal plataforma, se debe destacar que no participaron las personas que administraban los sistemas informáticos existentes (entonces Centro de Cómputo, ahora CGI-DTICs), y mucho menos la opinión de la Escuela de Informática, que al ser relegada por completo recibió una nada propicia señal de desconsideración hacia su nivel de aporte y capacidades de apoyo a la propia institución.

El proyecto inició y pronto se escenificaron los primeros inconvenientes: lo que a priori se promocionó como una herramienta que se adaptaría al modus operandi existente para hacerlo más eficaz y eficiente, se convirtió en una transformación de procedimientos prácticamente total para adaptarlos al nuevo sistema. Ello tuvo por consiguiente la reacción de las personas usuarias quienes, sin embargo, no tuvieron otro remedio que acatar las órdenes.

Muy desafortunadamente, la participación de las unidades objetivo del proyecto prácticamente se ha limitado a capacitaciones de usuario, produciendo una insatisfacción creciente en el uso del sistema por la adaptación forzada. De igual modo, la rigidez del sistema ante los cambios solicitados están haciendo aumentar altamente el riesgo de rechazo y, por ende, la pérdida total de la inversión. De igual forma, es constatable que los procesos donde las personas operarias antes interactuaban con la información precisa, ahora deben amoldarse a formularios genéricos bajo una herramienta mucho menos amigable, lo que en la práctica ha supuesto la duplicación de tiempo consumido por acción procesada, o a veces más.

No obstante lo antedicho, la Universidad no ha tenido problemas irresolubles en cuanto a un colapso administrativo hasta el momento, aunque sí graves problemas de incorrecciones debidas a una inadecuada adaptación. En cualquier caso, se conoce informalmente del gran descontento en la Unidad de Registro, Proveeduría y la Unidad de Recursos Humanos y en las unidades académicas, malestar que no conocemos formalmente y en efecto, debemos sondear la opinión actual que tienen las personas usuarias del sistema así como la de quienes lo administran. En tal sentido, la próxima semana estaremos iniciando tal investigación, a fin de sustentar las consideraciones que hacíamos al principio sobre el éxito (o fracaso) en la implantación de Innovare. ¡Estén pendientes de un nuevo post con los resultados!.

La situación, más allá de las opiniones y lejos de irse solucionando, cada vez se torna más confusa sobre todo visualizando las posibilidades reales de adaptación del sistema a decisiones institucionales futuras de transformación de procesos, así como el costo anual de licencias de la infraestructura necesaria (plataforma ORACLE ®).

Al respecto de tales cuestiones de costos presentes y futuros, lo que hemos podido saber (gracias a la información pública que consta de presupuestos de DTICs), el costo anual de la plataforma Oracle ® está valorada en US$180,000, y el mantenimiento anual de SCT Banner en US$61,000. Con ese platal, más lo que se gasta en sistemas operativos/herramientas de oficina y antivirus de escritorio el año pasado hicimos el estudio de viabilidad financiera de un proyecto que revirtiera esta decisión y ¡oh sorpresa! en 3 años y 11 meses se recuperaría lo invertido y para colmo de virtudes, a un 19% de interés, el Valor Actual Neto sería de US$230741 (5 años) y la Tasa Interna de Retorno de un 41%. Por acá les dejamos un link al mencionado proyecto, por si quieren echarle un ojo: descargar

Justificada la viabilidad financiera de un proyecto de reversión (que como observan hemos denominado RENOVE, por aquello de ser secuela reformadora de INNOVARE), la verdad es que apenas faltaría tener bien fundamentada la opinión de usuarios/as y administradores/as para poder informar adecuadamente a las autoridades del estropicio informático cometido... más vale arreglar las cosas tarde que nunca.