Sistemas de información.

Es una costumbre muy celtíbera (aunque creo que en otros sitios) opinar con la información de un titular (a ver quien no lo ha hecho) algunas veces, algunos, también buscamos algo más de información (sin pasarse, ¡eh!) para ver de qué estamos opinando, las menos, nos metemos en los temas más en profundidad y las que menos, sabemos más o menos de qué hablamos de primera mano, basados en la experiencia. En general, de todo lo que hablo en este humilde blog se queda en el segundo punto, pero hoy voy a irme al extremo: conozco de qué hablo.

Está muy en boga echarle la culpa de todo a los ordenadores. Que si se ha caído el sistema, que si un error informático, que si los sistemas no están conectados, .... etc. Siempre sale algún periodista y/u opinador echándose las manos a la cabeza diciendo "¿cómo es posible que no estén cruzados los datos de la Policía y la Guardia Civil (por poner un ejemplo)" o cómo los juzgados no están interconectados, que si dejadez, que si falta de interés, que si patatín, que si patatán ... etc. Pues da la casualidad de que yo llevo 16 años trabajando para una gran empresa española en la parte de sistemas de la información (obviamente no se llama así el departamento) y creo que sé un poco de que hablo y sé que eso que se que se pide ni es tan fácil ni es tan trivial y voy a intentar explicar el por qué. Y no es por desidia, falta de capacidad de los gestores y técnicos y a veces, ni siquiera por falta de presupuesto. Los problemas son mucho más complejos.

La informatización de la empresa, banca y el estado en España no es cosa de ahora. Lleva muchos años haciéndose. Si pasas por este enlace verás como hace 30-40 años ya los informáticos de por aquel entonces lidiaban como podían con los problemas de las empresas con los recursos de aquel entonces. Ordenadores con 64 Kb de RAM, discos de 10 Mb y cintas era con lo que tenía que trabajar por aquel entonces. Además, eran caros, muy caros y sólo grandes empresas y determinados departamentos podían acceder. Eso creó una cosa conocida como aplicaciones nicho: una serie de aplicaciones especializadas en resolver los problemas de un departamento concreto: provisión, contabilidad, facturación, averías, .... Esas aplicaciones se realizaban conl los medios disponibles en cada época por lo que es fácil encontrar aplicaciones COBOL de IBM que los ficheros son secuenciales, indexados, con BD, etc ... dependiendo de lo que hubiera en cada época. Cada aplicación era un mundo y surgió el problema ¿cómo pasar por ejemplo los datos de consumo a facturación para que cobre? Fácil: con un bote.

Bote: Símbolo de fichero.

El bote, en jerga de un antiguo conocido de Indra no era ni más ni menos que un fichero secuencial representado en la simbología de los ordinogramas.Según la época, ese fichero podría ser descargado a una cinta magnética (yo las he usado, aunque muy poco) que habría que llevar físicamente a mano a otro ordenador (hoy en día esto se sigue usando aunque el fichero se copia de un disco a otro vía red)

Cinta magnética. Fuente: Wikipedia

Por supuesto, esos sistemas nunca se terminan ya que el usuario va incorporando poco a poco nueva funcionalidad (que nadie piense se que se define todo al principio, es sencillamente imposible, especialmente a la hora de evaluar el coste) Con el tiempo, los recursos se van abaratando y más departamentos van haciendo sus sistemas nicho, todos independientes, cada cual con una tecnología de su padre y de su madre (Java, C, Cobol, RPG, ...) y con sus SO (MVS, VM, Solaris, HP-UX, Linux, MS-DOS, ...) e incluso los de los departamentos hacen sus pinitos y montan sus tamagotchis, pequeñas aplicaciones departamentales que acceden a los datos de los sistemas principales. Hay otro problema adicional. Los datos de cada sistema no sólo pueden ser incompatibles a nivel de ficheros sino que incluso, pueden ser incompatibles a nivel de formato y de contenido. A nivel de formato puede ser algo tan sencillo como que uno sistema guarde la fecha en 6 dígitos (típico de los sistemas COBOL de antes del año 2000) y otro en 10 (dd/mm/yyyy, incluyendo los slash) o en formato Excel (que también se las trae) o que en una empresa, la parte de nóminas utilice la referencia del trabajador por Número de la Seguridad Social, los partes de trabajo lo hagan por número de empleados y el fichero de RRHH lo haga por DNI. Aunque parezca demencial, puede ocurrir y para más INRI, aunque seguramente todos tengan el campo nombre, Murphy dicta que no será clave de búsqueda en ninguno, en una aplicación vendrá el nombre y los apellidos en un sólo campo, en otra vendrá en campos separados, en otra vendrá en un sólo campo lo apellidos antecediendo al nombre ... y ya no cuento con los apellidos compuestos y con "de" lo que puede ser. Supongo que ahora se puede hacer uno la idea de lo complicado que es buscar los datos de una persona en la empresa.

Cada departamento tenía unas necesidades que tenía que resolver en su momento y no podía esperar a que los sistemas de información hicieran un sistema global lo que generó este girigay de sistemas distintos (y ojo, estoy hablando de la misma empresa/corporación) Voy a poner otro ejemplo real. Hace unos años estuve en un encuentro de informática aplicada a la medicina, relacionado con el historial médico. Aunque parezca mentira, cada comunidad había abordado el problema de una forma distinta. No podían esperar a que otros les resolvieran el tema de las historias médicas y tuvieron que buscar una solución con el presupuesto que tenían. Por ejemplo, mientras Andalucía y Galicia disponían de grandes sistemas para almacenar la información correctamente indexada otra comunidad (que no voy a decir, pero me defraudó) utilizaban un campo de comentarios para almacenar las historias. A la hora de hacer cualquier análisis estadístico (epidemias, incidencias de enfermedades, factores de riesgo) estos últimos disponían de una capacidad de análisis casi nula.

En este punto el avispado tertuliano podría pensar en hacer un sistema que lo englobe todo. Pues nada más lejos de la realidad. Incluir toda la funcionalidad de todos los sistemas es prácticamente imposible y cuenta con un factor añadido más: el dueño del sistema no es un informático, sino el responsable de que algo se haga (por ejemplo, las nóminas, controles de almacén, ...) y lo primero que pregunta es ese nuevo sistema ¿me garantizas que va a funcionar como el viejo? si algún lector está contestando que sí, o es un irresponsable o es que nunca ha hecho un sistema a partir de otro. La complejidad de sustituir un sistema por otro no viene tanto de lo que haga el sistema en sí sino de las interacciones que tenga con otros (y el mapa puede ser muy complejo)

Ya hemos visto que las aplicaciones nicho son complejas pero hay otro factor que las ha complicado más. Antes las comunicaciones eran batch y estaban más o menos controladas, pero con el devenir de las redes, la gente a pensado ¿y por qué no optimizamos el sistema accediendo directamente al origen de los datos? La idea no es mala. De hecho es muy buena (por ejemplo permite ver la facturación online de las líneas de teléfono) pero siempre hay problemas:

- Lo primero hay que definir un canal de comunicación. Por ejemplo, no es evidente el acceder desde un sistema UNIX a un mainframe de IBM, pero es posible, al revés es muy complicado hacer un interfaz síncrono y hay que tender a colas de mensajes asíncronas como MQseries.

- A veces los sistemas son aplicaciones comerciales adaptadas (ERPs, SAP, ARS, ...) y los interfaces son muy limitados.

- Los datos pueden estar en varios sistemas y hay que andar saltando de un sistema a otro (cada nuevo interfaz, es una complicación más a realizar)

- Salvo que se realicen interfaces SOA o similares, un interfaz suele servir para una sola cosa, con lo que puede ser preciso hacer varios entre diversos sistemas.

- Un sistema puede tirar a otro (de hecho a mi, me han tirado varios por entrar en mi sistema a hacer una serie de operaciones no previstas y por supuesto, nadie me dijo nada hasta que se cayó)

- Ha veces un sistema hace de mensajero de un tercero.

- Otras veces, el sistema hace algo para lo que estaba previsto (ejemplo, el sistema de averías de Telefónica se usaba también para desconectar a los usuarios morosos)

Al final, entre las aplicaciones se teje una maraña de interfaces (no siempre documentados) que hace muy completa su sustitución. Cierto gerente tenía un sistema muy efectivo para ver si podía eliminar una aplicación que iba a sustituir por otra. Sencillamente la apagaba, sin eliminar datos, ni liberar ordenadores y se quedaba a la espera de quien se quejaba. Si no lo hacía nadie en un tiempo prudencial (por ejemplo, dos meses) se podía eliminar. Si se quejaba alguien, dependía de lo arriba que viniera la protesta, se apagaba o no. Como caso anecdótico, tuvimos una aplicación que llevaba dos años sin actualizar (con lo que los datos que devolvía estaban muchas veces erróneos) que se apagó varias veces y varias veces alguien la volvió a arrancar sin saber quien ni por qué  (debía andar por ahí el fantasma del CPD)

Casi todo lo que he comentado es relativo a una gran empresa, con lo que en la administración (por lo poco que conozco) debe ser similar o peor. En el caso de los juzgados estoy seguro que durante mucho tiempo, lo que llamaban informatizar debía ser pasar los escritos a Word. Intenta ahora indexar algo ahí o buscar algo en concreto.

Hay un punto que he olvidado mencionar: los datos previos a la informatización. La sanidad en Castilla y León está informatizada hasta cierto punto, pero existen almacenes con historias médicas previas en papel que no se pasan a soporte digital por el coste que conlleva y el tiempo necesario. Así que si alguien tiene algún antecedente médico (y se acuerda) se envía al ujier en la furgoneta al almacén a buscar las historias. Lo mismo pasa en los juzgados y en otras partes de la administración.

Para terminar, si alguien sugiere la informatización total debe saber que es un tema muy, pero muy complejo. Con el tiempo se conseguirá, pero hay que tener paciencia. El sustituir todo por un solo sistema es prácticamente imposible y muy caro y tiene otro problema: es costoso en el tiempo. No se hace de la noche a la mañana y mientras, los sistemas nichos van evolucionando (conozco un sistema que entró en plazo para sustituir a otro pero cuando llegó, el otro había evolucionado y el nuevo ya no servía) porque deben seguir prestando servicio y es imposible parar esto.

Al final, cuando alguien pida "todo esto debe estar conectado" espero que el lector tenga un pensamiento comprensivo para los pobres informáticos que hacemos lo que podemos.