Es viernes por la tarde y aunque solo son las tres, iniciamos la parada de los usuarios de los sistemas centrales para lanzar los procesos de copias de seguridad, antes del horario habitual, porque vamos a realizar la instalación de una nueva versión del sistema operativo. Está todo planificado y revisado así que hacia la media noche, deberíamos tener las copias de los datos y programas en los carretes de cinta e iniciar la carga del nuevo sistema operativo. Antes ha habido que añadir el salvado de la configuración del sistema, de los perfiles de usuarios, de sus privilegios de acceso y atributos, de las colas de entrada y salida, etc. Todo ello supone un tiempo extra de copias y de recuperación en caso de tener problemas, cosa que el fabricante del sistema nos garantiza que no va a ocurrir.

Habíamos decidido instalar la nueva versión porque habían bastantes problemas de velocidad en los procesos de backup, que se comían la noche, y para poder utilizar las nuevas unidades de cintas de 8mm era necesario saltar a la versión siguiente del sistema operativo. Esperábamos que a partir de ahí, los backups se acortasen y la disponibilidad del sistema para los usuarios mejorase notablemente, como así fue finalmente, sin necesidad de cambiar la CPU, tal como sugería el proveedor, lo requería la aprobación de un presupuesto mayor para la gestión de los sistemas, que la dirección no estaba dispuesta a aprobar. Dado el riesgo que conllevan estas operaciones, habíamos advertido –por escrito- a los usuarios, durante algunos días, de que mantuvieran el control de su información escrita, por si fuese necesario trabajar manualmente en algún momento.

Hacia las once y media de la noche del viernes lanzamos la primera cinta de carga de la nueva versión del sistema. Nos fuimos a comer el bocadillo porque sabíamos por experiencia que este primer paso era bastante largo. La consola iba dando mensajes y finalmente decía “Este proceso puede durar algunas horas o más” y se quedaba tan fresco. Es una muestra de la traducción del Inglés al Español, tan habitual en la época. Hacia las dos de la mañana, a petición del sistema, pusimos la segunda cinta. Todo iba bien hasta que un llamativo mensaje de error de lectura del soporte nos hizo temblar. Tras reintentar varias veces, el proceso continuó, pero la cinta iba y venía adelante y atrás cada vez que leía un trozo y eso era muy mal síntoma, era claro que el soporte recibido estaba dañado. El caso es que a medio día del sábado, decidimos abortar la instalación y dar marcha atrás ya que el proveedor no tenía otra copia del sistema en Valencia y esta no parecía estar en condiciones de continuar instalándose.

Iniciamos la recarga de la versión anterior y pasamos el resto del sábado y la madrugada del domingo en este proceso. Por la tarde recuperamos configuración, usuarios, etc. Ya parecía que todo iba a ir bien, así que antes de terminar, hicimos algunas pruebas para asegurarnos de que en la mañana del lunes, nuestros problemas serían transparentes a los usuarios. Probamos accesos y procesos con las limitaciones que teníamos y confiamos que el entorno de producción estaría en condiciones.

El lunes por la mañana, los usuarios no podían acceder al sistema. Las autorizaciones y los perfiles parecían no trabajar adecuadamente. Iniciamos contacto con el soporte del proveedor para verificar que habíamos hecho la recuperación correctamente y así parecía ser, sin embargo no dábamos con el problema. Para no aburrir, la conclusión fue que una vez iniciada la instalación de ciertos módulos de la versión nueva del sistema, el proveedor advertía de que no podía garantizar la vuelta atrás, es más, no lo recomendaba. Sin embargo nadie lo sabía, al menos en Valencia y claro ahora habría que instalar la nueva versión cuando dispusiéramos de una cinta en condiciones y eso no sería antes del lunes al medio día. El proceso se repitió entonces y el martes a mitad de mañana todo volvió a funcionar correctamente.

Hasta aquí un relato real, como muestra de que aún haciendo el plan perfecto, puede darse el caso de que los sistemas vitales para la gestión de la empresa, no estén disponibles. Y ¿qué hace el usuario en este caso? Yo solo hablaré de mi experiencia y puedo decir que el usuario no está preparado para que le caigan los sistemas de información y en caso de suceder esto, en un breve plazo se queda bloqueado.

¿Es que el usuario es un irresponsable o un incompetente? NO y rotundamente NO. Lo que ocurre es que conforme los sistemas de proceso de la información lo permiten, la complejidad de los mismos crece y se eliminan elementos esenciales para realizar el trabajo sin ellos, léase personal suficiente para gestionar el negocio a mano, para prevenir cada paso del mismo y documentarlo, para hacer pruebas y entrenar a la gente que procesa la información, para disponer de información alternativa en otros soportes que le permitan organizarse rápidamente y seguir atendiendo a sus clientes sin impacto importante en ellos, etc.

Cuando sucedió lo que he relatado, la dirección de la empresa me llamó para una reunión de crisis. Después de tratar de explicar en lenguaje llano los tecnicismos del problema, y probablemente sin que estuvieran convencidos de que estas cosas pasan hagas lo que hagas para evitarlas, mi pregunta fue: ¿Cuánto le cuesta a la compañía en ventas un día de parada de sistemas? La respuesta era que el impacto es poco sobre el cliente si son solo 24 horas, pero es importante a partir de ahí y crítico si llega a durar 72 horas o más. Entonces ¿debemos asegurar la disponibilidad de sistemas con un margen de parada de 24 horas? pregunté al comité de dirección. SI CLARO, eso es imprescindible, no podemos permitirnos trabajar sin sistemas más de un día entero. Recordarles mi propuesta de mejora de la seguridad y disponibilidad de los sistemas fue fácil porque la tenían hacía meses en un cajón y ahora tendrían que reconsiderarla. Se aceptó un nuevo presupuesto, se instaló un sistema redundante (MIMIX en aquella época) y se mantuvo una copia en línea de las bases de datos y librerías de programas. Desde entonces las crisis tecnológicas dejaron de tener impacto directo en la actividad de los negocios, pero el plan de recuperación de desastres empezó a figurar en la agenda de todos los departamentos ya que siempre pueden darse circunstancias en las que el usuario tendrá que tomar acciones para continuar trabajando, pues el fallo tecnológico es tan solo uno de los posibles problemas que se pueden presentar. Catástrofes naturales, incendio o inundación de locales, o hasta una enfermedad contagiada a la plantilla, son ejemplos de situaciones de riesgo en las que el día a día no permite pensar pero que pueden hacer caer las cifras de un negocio si no se ha previsto como actuar en los casos de crisis.

Los departamentos o personas responsables de la organización de las empresas deben diseñar e implementar los procedimientos necesarios para dar respuesta a las situaciones de crisis y para ello, hay metodologías cuyo uso es necesario y expertos en la materia, cuya participación es recomendable si se desea garantizar un cierto nivel de seguridad en la continuidad de los negocios. Implementar el plan de recuperación de desastres, auditarlo y probarlo periódicamente es la mejor manera de garantizarse la supervivencia ante las crisis no previstas.

Para finalizar los artículos sobre el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información (ver I, II, III y IV), debo comentar los puntos que siempre me han ayudado en el despliegue o implantación de los sistemas.

Una vez completadas las pruebas y validadas por el usuario experto, es necesario obtener el visto bueno del cliente para su despliegue en su entorno real. Para ello, será necesario exponerle los trabajos realizados, las funciones desarrolladas en el sistema y validadas por su usuario experto, así como el plan de implementación o despliegue del sistema en su entorno de trabajo real, que deberá incluir el entrenamiento específico y necesario para los usuarios del sistema, la documentación que se les va a entregar (manual del usuario, gestión de incidencias, etc.), así como la planificación para la conversión y migración de datos, la verificación de los mismos, los procesos en paralelo (si se acuerda llevarlos a cabo) y finalmente la fecha límite de cierre del proceso de despliegue, a partir de la cual, lo que comienza es el servicio de soporte (si así se ha acordado).

Frecuentemente, se comprimen los tiempos y planes de trabajo en la implementación de los sistemas, dando por sentado que todo saldrá bien y cada cual asumirá su rol sin problemas, pero la realidad demuestra ser tozuda y contraria a esta visión.

Bajo mi experiencia, la disponibilidad y dedicación de los usuarios del sistema para el proceso de puesta en marcha es crucial y requiere una cuidadosa planificación que debe incluir acciones estratégicas tales como:

Es por tanto necesario tener en cuenta todos estos factores y planificar adecuadamente las sesiones de entrenamiento, que además incluirá el uso del sistema en real sobre las bases de datos de pruebas.

La gestión de conflictos que puedan darse durante el proceso de implantación de un sistema es un asunto crítico para llegar a buen fin. Mi experiencia me aconseja que:

Finalmente solo decir que en estos artículos he tratado de transmitir recomendaciones muy generales basadas en las experiencias habidas durante mi vida profesional en entornos de todo tipo con múltiples actividades en el área de diseño programación e implantación de sistemas, así como en la explotación y en el soporte, y también como consultor de compañías multinacionales en proyectos globales. Hoy, cerca de mi jubilación, he considerado que estas experiencias pueden ser interesantes para quienes están en el camino de su carrera profesional, ya que además, no suelen ir incluidas en los planes de estudio ni suele haber tiempo en las empresas para compartirlas.

Durante algún tiempo me he estado preguntando si dentro de este foro de seguridad cabía un tema como el que voy a exponer ya que aunque está relacionado con la gestión de la información (más bien del conocimiento), está también relacionado con el modo en que la información y los métodos de seguridad y control de la misma son aplicados o ignorados en la pequeñas y medianas empresas, sobre todo, cuando son empresas familiares.

Hablo concretamente de la manera en que información crítica para un negocio es considerada tabú a la hora de documentarla y más aún de transmitirla a otros individuos que forman parte de la toma de decisiones y gestión de aquél, ignorando el riesgo que supone conservarla para uno mismo, en lugar de transmitirla o dejar constancia de ella para garantizar su continuidad. Esto vale tanto para los dueños o gerentes de las empresas, como para los empleados “genios” de las mismas, muchas veces considerados imprescindibles, hasta que desaparecen y no ocurre nada. Tengo ejemplos que he vivido durante mi servicio a diversas empresas.

Una fábrica de muebles con la que trabajé tenía un director con el conocimiento de ciertos asuntos tales como las mezclas de barnices y pinturas a través de las que obtenía calidades muy diferenciadas de su competencia, o las mezclas que hacía juntando láminas de diversas maderas traídas desde muy lejos pero que daban un resultado tal que el mundo árabe (su principal cliente) no cesaba en pedidos. Pues bien, cuando este director falleció repentinamente, la diferencia de calidad de esa producción desapareció y los clientes dejaron de hacer pedidos. La fábrica cerró y posteriormente la gran tienda de muebles también.

Otros ejemplos que podría contar los viví en el área del textil, en la de la alimentación y en la fabricación de sistemas electrónicos de seguridad. En todos ellos, la falta de transmisión del conocimiento fue evidente y el final se produjo de la misma manera que he relatado antes: cuando desapareció el experto, se acabó el negocio. Y aquí podría nombrar aquello que circula a nivel global ¿Qué sucederá con Apple tras la desaparición de su genio?

¿Por qué sucede esto? Unas veces porque quien debe transmitir el conocimiento no lo hace a tiempo o simplemente no lo hace. Otras porque tras algunos años en la universidad, quién debe aprender del experto, considera que sabe más que este y emprende un camino ignorando lo que se le pretende enseñar. “El abuelo está fuera de su tiempo” suele decirse, ignorando que el abuelo empezó en la calle sin nada y montó un negocio que prosperó en épocas tan duras o más que las actuales y que probablemente conserva aquellos conocimientos e ideas iniciales a las que añade la experiencia de largos años gestionándolo y que por lo tanto, si a ello se unieran las nuevas enseñanzas adquiridas en la universidad por el sucesor, podrían marcar distancia con su competencia. Lo he vivido demasiadas veces.

También el empleado experto, que solo él conoce una gestión determinada y fundamental para el buen funcionamiento de la empresa y que es considerado persona imprescindible por su superior, es un riesgo evidente, ya que no comparte con nadie ese conocimiento y en caso de no estar disponible, puede ser un serio problema para el funcionamiento de la empresa.

Llegados aquí, creo que de algún modo, debe asegurarse la transmisión del conocimiento de gestión de los negocios y funciones, sin que ello deba representar un riesgo para quienes lo poseen o para la compañía. Puede parecer absurdo, pero no lo es. Hoy en día existen medios suficientemente seguros para proteger cualquier patente, documento o fórmula que expresen la clave de un producto, de una idea de mercado o de un modo de gestionar los puntos críticos de un negocio, y guardarlos a buen recaudo de curiosos y competidores. Por lo tanto la cuestión es más bien de actitud personal y de confianza en el nuevo depositario de este conocimiento.

¿Cómo debería hacerse? No soy un experto en ello, pero el modo en que otras empresas lo han hecho y continúan en el mercado me demuestra que lo primero que debe hacerse es clasificar la información y hacer un inventario de ella, para poner en claro qué información, proceso o producto es el que diferencia o simplemente mantiene viva a la empresa, léase la fórmula de unas magdalenas, la de la Coca Cola o la base química de fabricación de un plástico para pantallas, de unas baterías que duran más que las de la competencia, de un cristal para objetivos de instrumentos ópticos que ni se raya ni se empaña, etc. Todos ellos son ejemplos de productos que actualmente están en el mercado.

De este modo, la información identificada como importante y no pública, que deba ser resguardada de algún modo, será “Confidencial”. Aquella que resulte crítica para el negocio será información “Secreta”, la que responda a ciertas calificaciones, tales como “de carácter personal” (LOPD y RDLOPD) se identificarán como “Personal o Privada”, etc. Documentar y proteger esta información con las medidas de seguridad adecuadas es esencial, pero también no olvidar transmitir el conocimiento práctico de la fabricación y comercialización de ciertos productos o servicios que cuya descripción en papel es cuanto menos compleja o imposible. Esta información habrá que transmitirla a pie de cañón, viviendo una temporada en la misma fábrica o viendo cada paso estratégico en la organización, cada detalle que el “abuelo” o el “genio” controlan y conocen y aprendiendo de ellos.

Aquí aparece el segundo problema más frecuente: ceder el conocimiento y más tarde el asiento, y aceptar permanecer detrás vigilante, por si acaso, es otro paso difícil pero necesario. Ahí es donde “el abuelo” puede fallar y el “genio” puede considerar que peligra su estatus. Si el abuelo piensa que el secreto mejor guardado es el que no se cuenta, estamos mal y si el genio se niega a transmitir su experiencia también. Al primero, será necesario hacerle ver el problema de su posible indisposición, jubilación, o como queramos llamarlo, pero el hecho es que tendrá que pensar en que pasaría o qué pasará cuando el no pueda seguir con la dirección o la gestión que realiza. Al genio, probablemente se le pueda convencer con la posibilidad de una promoción o una compensación de otro tipo, pero tampoco estará exento de problemas. Lo mejor es no crear estos genios en las empresas y mantener un nivel de conocimiento adecuado y compartido en cada función de la misma, de modo que en todos los puestos haya una persona de respaldo.

Me recuerda aquello que decían los profesores en los cursos de seguridad “el ordenador más seguro es el que no está conectado a ninguna red y si está apagado mejor”, lo cual no comparto en absoluto ya que la información debe fluir, eso sí, por cauces definidos, controlados y seguros. La información que no fluye está muerta, no produce beneficio, no se actualiza y tarde o temprano será olvidada.

La conclusión de este planteamiento es que quién decide dar pasos adelante para que el negocio le sobreviva debe identificar a las personas a las que tendrá que transmitir el conocimiento, asegurando su capacidad y fidelidad, pero también debe proveerse de medios de almacenamiento, control y seguridad de todo lo que considere esencial en sus negocios y para ello, no bastará su criterio sino que deberá confiar en su equipo y a la vez, en los expertos externos que pueda necesitar, cuidando bien los términos de los contratos de confidencialidad que pudieran firmarse y limitando así la diseminación de ese conocimiento estratégico.

Herramientas, tecnología y personal preparado hay en el mercado, solo falta la claridad en el planteamiento “sucesorio” y la correcta elección del equipo que continuará sus pasos.

Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez tenemos desarrollados los programas que habrán sido probados por los programadores, y las corrientes de trabajos, montadas igualmente por los programadores o por los encargados de la planificación y explotación de sistemas, será necesario ejecutar ciclos de pruebas del producto obtenido, antes de proponer su aceptación por parte del cliente. Para ello, es muy conveniente disponer de un conjunto de datos de prueba, lo más completo posible, que abarque el máximo de transacciones diferentes y de los casos descritos en la primera etapa del proyecto “Toma de Requerimientos” para verificar que los resultados son los deseados, especialmente en aquellas transacciones más complejas y conflictivas que pudieran darse.

Para preparar las pruebas, y conseguir un buen set de datos de prueba (en mis tiempos les llamábamos un “juego de ensayos”), es muy conveniente tener la colaboración del usuario más experto posible, es decir de quién de verdad trabaja sobre el sistema y pelea diariamente con la información. Ello puede ser problemático si el usuario se siente amenazado por la implantación del sistema (hay que ser psicólogo en este asunto), o si tal vez está tan ocupado que es difícil conseguir su participación en esta etapa. Lo mejor es tenerlo previsto y planteado en los primeros pasos del proyecto como una necesidad que el cliente debe atender y tal vez no solo en las pruebas, sino también en la previa definición detallada de los procesos.

Si el sistema va a trabajar contra una base de datos que ya existía y para las pruebas se decide obtener una copia de aquella, es muy importante tener la autorización por escrito del responsable de esa base de datos para poder copiarla, máxime en el caso de contener datos de carácter personal (LOPD) y además será necesario dotar a esta copia de las medidas de seguridad exigidas por la citada ley y su Reglamento y destruirla tan pronto como no se justifique su existencia.

Si el sistema va a trabajar sobre una base de datos nueva, un proceso de migración de datos será necesario, a no ser que se parta del punto de crearla desde cero, cosa poco frecuente. Para realizar dicha migración, se tendrán que preparar programas específicos que cumplan las condiciones equivalentes a las definidas para la entrada de datos al sistema, quiero decir que probablemente se requieran parámetros y valores de control nuevos que no existen en el diseño antiguo a sustituir, y que tanto como sea posible, deben ser introducidos de forma automatizada en la nueva base de datos, y si esto no es posible, tendrán que ser posteriormente introducidos a mano en un proceso de validación manual de la misma.

Siempre se deberá tener en cuenta el balance de coste y dedicación contra el beneficio de obtener una base de datos depurada contra el hecho de que se depure después en el tiempo. Obviamente es preferible obtener datos ya limpios y completos, pero como esto no siempre es posible, en algunos casos, conviene prevenir un “estado” de los registros de la base de datos que indique su situación de “Validado” o “Pendiente de validar”, aparte de otros tal vez más comunes como “Bloqueado para proceso” o “Cancelado”. Probablemente habrá otros estados de datos que dependerán de las características de la información y del proceso a realizar, pero los dos primeros indicarán el estado natural de una nueva información, “Validado” es un registro con información contrastada y depurada, mientras que “Pendiente de validar” serían las entradas de datos que no han podido validarse por completo y por lo tanto, los diferenciaremos para poder revisarlos y ajustar sus contenidos posteriormente. Idealmente, programas específicos para localizar estas entradas deberían estar disponibles, con el fin de completar su revisión o validación en el menor plazo de tiempo posible, pero esto conlleva un coste adicional que no es fácilmente asumible, aunque mantener datos erróneos o incompletos, a la larga suele tener mayor coste.

Para el propósito de realizar las pruebas más completas del sistema, es conveniente elegir un set de datos completamente validado, e incluir en dichas pruebas los programas de migración de datos. Analizar la base de datos de pruebas obtenida, antes de empezarlas, nos evitará después quebraderos de cabeza al comprobar los resultados de las mismas.

Normalmente, si los programas se desarrollaron con un buen conocimiento del proceso (análisis técnico o detallado) y una documentación adecuada, y también han sido probados individualmente con conjuntos de datos validados, lo normal es que las pruebas den resultados satisfactorios desde el primer momento, habiendo siempre cosas que corregir y ajustar, pero de poca envergadura y no surgirán errores de interpretación sobre la naturaleza y detalle del proceso y sobre todo errores de la funcionalidad del mismo, que con bastante frecuencia pueden dar al traste con el proyecto y tener que revisarlo por completo.

Por tanto “casques” de procesos y resultados imprevistos no deberían aparecer una vez depurados los programas y cadenas de trabajos individualmente, y solo errores de codificación y ajuste del sistema deberían ser objeto del trabajo en esta etapa.

Una vez el usuario experto da por buenos los resultados, es hora de presentarlo a los responsables del proyecto para requerir su aceptación, y de planificar la etapa siguiente con la implantación o despliegue del sistema en el entorno de producción del cliente.

Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información (véase Diseñando Sistemas II: El diseño del sistema y Diseñando Sistemas I: La toma de requerimientos), una vez definido el diseño del sistema, entramos en la fase de análisis detallado del mismo. En esta etapa, si es necesario, se puede plantear un documento de análisis detallado de las funciones o directamente un análisis técnico de las mismas. Bajo mi experiencia, el primero solo reflejaría el flujo de información y las decisiones y ramificaciones posibles del mismo, así como los puntos de entrada de la información y los diferentes casos de conjuntos de datos que pueden darse para su proceso. Igualmente indicaría las transacciones válidas y el modo de controlarlas, y las prohibidas —si las hubiera— y el modo de actuar sobre ellas.

El análisis técnico debe reflejar con suficiente detalle los controles y acciones a ejecutar con cada modelo posible de datos, así como los conceptos que componen su proceso y como llevarlo a cabo. Es decir, debe definir con detalle las transacciones y sus condiciones de proceso, así como los resultados que se pretende obtener, reflejando su contenido, formatos y también cualquier control o acción requeridos con antelación o posteriormente.

Son conceptos básicos pero que frecuentemente se olvidan —aunque les parezca mentira hoy aún se olvidan—. Por ejemplo hacer la captura de datos en línea, incluyendo la validación de éstos en el momento de su captura y no en procesos posteriores, ya que la información errónea no debería entrar en el sistema ni formar parte de su base de datos. Esto evitará procesos inútiles y revisiones posteriores de los datos. Si quien la genera sabe que en el caso de no ser correcta, la información será rechazada, procurará depurarla por sí mismo.

Obviamente, para poder hacer lo anterior, es necesario tener cuidadosamente definidos los controles a realizar y estos son los que deben describirse en el análisis detallado, indicando contra qué otra información o combinación de informaciones se va a validar cada uno. Para ello ya propuse en el artículo sobre el diseño detallado, la definición de parámetros y datos de control que el administrador del sistema o el usuario experto responsable deberá introducir previamente en las tablas de control.

Una vez dada por buena la información introducida, lo lógico es que sea válida para alguna de las posibles transacciones que el sistema “sabe” ejecutar y por tanto no haya problemas de error de datos o cancelación de programas si estos han sido desarrollados de acuerdo a las especificaciones detalladas del análisis técnico y éste ha previsto las diferentes posibilidades. Para conseguir esto, dicho análisis debe reflejar cómo ejecutar cada paso del proceso o transacción, con información suficiente para que el programador pueda comprenderlo y aplicarlo en su código, e igualmente pueda plantear las pruebas y validar los resultados.

Creo que es de suma importancia llegar a este punto con la mejor definición de los procesos que sea posible y que esta quede bien documentada, evitando que sea transmitida en reuniones de viva voz (muy frecuente) confiando en el buen hacer de los programadores que tomarán sus notas interpretando por si mismos lo que el analista o jefe de proyecto les cuenta, y que a su vez, es una interpretación de lo que el cliente les ha pedido. Un buen análisis funcional (o diseño del sistema) es la base para un buen análisis técnico (o especificaciones de programa) y estos dos son la base para desarrollar un sistema fiable y rentable.

Bajo mi experiencia, transmitirle al programador el fundamento de los procesos es esencial, no solo para obtener un buen resultado técnico sino para que facilite igualmente su gestión posterior por parte de los usuarios, así como su explotación. La fase de programación y pruebas de un sistema ha sido considerado tradicionalmente la de mayor duración en el desarrollo de un proyecto, pero generalmente esto se debe a la falta de definición de las necesidades del cliente y de los detalles del proceso requerido, en definitiva a un análisis incompleto o poco documentado. La experiencia me ha enseñado que la inversión de tiempo en estas dos etapas anteriores al desarrollo es muy rentable si este último puede hacerse con claridad y rapidez, y las pruebas plantearse con criterios de conocimiento adquirido de lo que se pretende obtener.

Considerar que el programador no necesita conocer el fundamento o el porqué de muchas de las decisiones que el programa va a ejecutar es un tremendo error, ya que limita de manera importante su creatividad y la aplicación de su propio conocimiento y experiencia en el desarrollo, incluso impide que el programador que conoce bien las herramientas que al final van a procesar la información, pueda sugerir algunas mejoras en la propuesta técnica, aportando cierto valor añadido a la misma. Lo más probable es que esto conduzca a tener ciclos de error – revisión – prueba – y nuevo error, hasta perder mucho tiempo (y aumentar el coste) y lo que es peor, comenzar a estresar al equipo porque las fechas de entrega se acercan o sobrepasan y el coste se dispara, lo que genera casi siempre nuevos errores y acaba con la entrega de un producto de calidad inferior a la deseada y prometida al cliente, que va a requerir soporte continuo hasta quedar depurado. Frecuentemente suele disimularse o camuflarse el coste indeseado de esta última fase, dentro de las actividades de un nuevo proyecto, lo que además de injusto, vuelve a ser un error.

Así pues, el responsable del proyecto deberá controlar cada etapa del mismo y validar la documentación y el medio mediante el cual se transmite la información y el conocimiento adquirido sobre los procesos a ejecutar, para que cada componente del equipo pueda realizar correctamente su trabajo.

Siguiendo con la tecnología punta, que comencé con aquellas placas de la Nixdorf 820/15 en mi artículo anterior, y como parece que resultó interesante, hoy quiero mostrar otro proyecto que pone en evidencia la evolución de la electrónica en un lapso de tiempo no muy largo, pero que ha posibilitado los avances y la miniaturización de los equipos hasta extremos que solo las películas de James Bond podían imaginar.

La situación era la siguiente: 1984, en una compañía que fabrica ropa, principalmente la ropa tejana, con un mercado muy competitivo en el que aparecen nuevas marcas continuamente y en el que los costes de producción deben limitarse al máximo para sobrevivir en el mercado, nos encontramos con que los muestrarios de prendas para la temporada del año siguiente se han de fabricar con 12 meses de antelación. Ello supone comprar o fabricar el tejido necesario que, muchas veces viene de sitios como la India, Paquistán, etc (años 80 ojo) y ello conlleva adquirir compromisos de consumo y fabricación de dichos tejidos, que al final han de gustar o no gustar a los clientes de las tiendas de moda que van a marcar lo que “se lleva” en la temporada.

Pues bueno, en esta situación, el fabricante prepara el muestrario de prendas, lo distribuye a sus vendedores que viajan a lo largo del país y van recogiendo pedidos sobre blocs de papel diseñados para ello. En el fin de semana, los vendedores -o estudiantes contratados por ellos- , codifican los pedidos con las series, modelos, tejido, color y conjunto de tallas que el cliente ha pedido. El objetivo es tenerlo listo para enviarlo por correo (no hay mensajeros) a la oficina más cercana (la de Valencia en este caso) y allí se introducirán en el sistema (IBM/38) de la época y una vez depurados los errores de codificación y de catálogo (no todas las combinaciones de serie-modelo-tejido-color y talla eran aceptables), se obtiene la información necesaria para ver qué es lo que “se lleva” o “no se lleva” en la temporada siguiente, o sea, que tejido y en qué cantidades habrá que pedir para atender los pedidos. Este proceso tomaba entre dos y tres semanas y era crítico para la buena planificación de recepción de materias primas, planes de fabricación, gestión de almacenes y distribución del producto a los clientes antes de comenzar la temporada dichosa.

En esta situación, el equipo de Informática de la empresa, se puso a indagar en la tecnología disponible para acortar en lo posible la gestión de esos pedidos que marcaban la temporada y el coste de la misma. En estos años, trabajábamos con los “nuevos” PCs de IBM, con pantalla verde, dos unidades de diskette de 5-1/4 pulgadas y los más afortunados tenían un disco duro de 16 o 32 MB, menos fiable que una cafetera, pero que daba su servicio con la primera hoja de cálculo “Lotus 123” y algún “Writer” como editor de texto.

Buscando en el mercado, el director del departamento encontró el EPSON PX-8, un ordenador “portátil” de la época en el que había una pantalla líquida con 8 líneas de 80 caracteres y una unidad de micro-casete que podía almacenar datos. El problema era como meter y mantener el catálogo de productos dentro de este equipo con apenas 128K de memoria y sin disco duro y como gestionar pedidos de productos con hasta 17 tallas posibles en cada línea. Aún así, el director de la compañía, con gran visión de negocio, dio el visto bueno para el proyecto y los técnicos nos atrevimos con él, teniendo yo la satisfacción personal de ser el responsable del proyecto desde el lado móvil, y compartiendo con el equipo de programación de sistemas el desarrollo de los procesos.

Los programas iban en una EP-ROM de 32 K y el catálogo se actualizaba en la transmisión de cada noche, sobre memoria. Los pedidos se recogían en el casete. La idea era dotar al EPSON PX-8 de un catálogo que el programa gestionase mostrando las combinaciones de serie-modelo, etc. válidas y depurando así el pedido en el momento de su captura. El vendedor debía usar el PX-8 en lugar del block de papel. Esto fue duro, muy duro, y el soporte recayó en mi persona, con lo que el manual de usuario (en papel claro está), las sesiones de entrenamiento, la puesta a punto del software, etc. fueron un proyecto muy interesante y una gran experiencia para mí.

Los pedidos se recogían en el PX-8, se imprimían en una impresora EPSON de papel térmico y se le entregaba una copia al cliente, que recibiría el pedido en el formato “oficial” después por correo, tal como lo generaba el sistema central.

Durante la noche, los pedidos recogidos en la jornada de trabajo, eran transmitidos por teléfono analógico, conectando un acoplador acústico al teléfono del hotel (lo llamábamos “zapatófono” y si miráis las fotos veréis porqué), en el que se encontrase el vendedor ese día y donde muchas veces, la centralita del mismo introducía ruidos y provocaba errores en la transmisión, por lo que les tuvimos que dotar de un amplificador de sonido que sustituía al micrófono del teléfono, abriéndolo y cambiando su micro por el nuestro. El problema vino cuando muchas veces, después de un largo día de trabajo, el vendedor olvidaba recuperar el amplificador y se llevaba en su lugar el micro del teléfono del hotel. El nuevo inquilino de la habitación notaría una buena mejora en la comunicación, pero el vendedor se había quedado sin su ayuda.

Otro problema tedioso que se repetía cada día, sobre todo en determinados vendedores, era el saber enchufar los dispositivos entre sí, no doblando las patillas de los micro-conectores al equivocar la entrada elegida o la posición correcta para conectar, y presionar la clavija intentando que entrase. El intercambio de cables con clavijas “espatarradas” era continuo. En vista de ello, se me ocurrió una solución, busqué un maletín grande y ligero en el que diseñé una espuma interior con los conductos requeridos para mantener los cables y dispositivos conectados. El alimentador del EPSON, la impresora y el cable de comunicación con el zapatófono, quedaban fijos dentro de la maleta y así se solucionó, solo que, las protestas de los vendedores por llevar la maleta con ellos y custodiarla, arreciaron, pero al final, el éxito del proceso calmó los ánimos.

Para la transmisión, se conectaba el PX-8, vía acoplador acústico y se enviaban los pedidos al sistema central de la red Mark III de General Electric, donde se recogían y a primera hora del día siguiente (7 de la mañana) se transmitían al sistema 38 de nuestro centro. Allí se hacía el proceso estadístico y se presentaba a la dirección los resultados de la campaña de ventas, decidiendo entonces que productos iban a venderse y que otros debían desecharse del catálogo. Pasamos de tres semanas de latencia de los pedidos, a tres días, eso sí con un gran esfuerzo y un “Smart Computer” de los años 80. El impacto en los vendedores de la competencia (se conocían todos y se encontraban en los mismos hoteles) fue genial, mostrando su asombro por la osadía de nuestros vendedores haciendo trabajar aquella cosa de EPSON. Tengamos en cuenta que la informática casera de la época era el Sinclair ZX y algún Amstrad asequible, los Pcs de IBM y los Apple eran carísimos.

Os adjunto unas fotos del sistema, el zapatófono y el “Smart Maletín”. Ah por cierto, luego se instaló en las oficinas de Francia, Inglaterra y Alemania, todo un éxito para la época.

Como ya indicaba en el anterior artículo de este ciclo, quiero recordar que estoy escribiéndolos basándome en mi propia (y dilatada) experiencia y reflejan tan solo ideas generales y prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado.

Así pues, continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez consideramos que la toma de requerimientos ha sido hecha y documentada adecuadamente y el cliente ha dado su visto bueno, comenzaremos con el diseño del sistema de tratamiento de la información. En esta etapa debemos asegurarnos de plasmar en el diseño todos aquellos requerimientos que hayamos sido capaces de conocer, aun cuando se dé el caso frecuente de que no va a ser posible implementar todas las funciones posibles ya que el cliente ha limitado el ámbito de actuación, solicitado un sistema más sencillo y de bajo coste y en este caso hay que recortar el desarrollo hasta donde sensatamente se pueda y limitarlo a la visión del cliente.

Es aquí donde la habilidad del responsable del proyecto debe mostrarse, definiendo las funciones esenciales, las que son convenientes —pero no son esenciales— y otras funciones posibles y deseables que, en una primera versión del sistema, tal vez no podrán implementarse, pero que muy posiblemente serán objeto de posteriores peticiones del cliente para ampliar la funcionalidad del sistema y si hemos sido capaces de prevenir estas circunstancias, será más sencillo satisfacerlas. De este modo, y tal como ya dije en mi artículo anterior, el clásico “esto no me lo habías contado y no está previsto”, quedará sustituido en la mayoría de las veces por “es posible integrar lo que me pides” y la inversión para implementar estas nuevas funcionalidades será menor y más rentable para el proveedor que lo tenía previsto que para aquel que necesita replantearse el diseño del sistema. Para ello, conviene dotar al diseño inicial de ciertos elementos de ajuste y flexibilización en la forma de procesar la información, que más adelante nos van a permitir implementar funciones y controles adicionales sin gran esfuerzo, rentabilizando así la inversión inicial.

¿Cómo se puede llegar a esto? Adquiriendo conocimientos extra durante el diálogo con el cliente, intuyendo lo que no ha dicho y previniendo que suceda. Por ejemplo, identificando los elementos clave que pueden definir el modo de procesar la información y añadiéndolos al sistema como entidades gestionables individualmente. Cuando el interlocutor te dice, tenemos clientes y proveedores —por ejemplo— pero no ha definido clases dentro de ambos, debemos averiguar si hay clientes que requieren procesos específicos o funciones dedicadas a su situación o necesidad y en tal caso prevenir ya que van a haber categorías de clientes y seguramente también de proveedores, así como que clientes o proveedores tendrán ramificaciones en el interior de los procesos. Si nos dice que compran o prestan tal o cual servicio, averiguar cuantas particularidades corresponden a cada uno y cómo se aplican a los clientes y proveedores (tal vez se está haciendo manualmente y bajo la “cultura” de algún empleado experto) y así sucesivamente. Probablemente de pronto el sistema tenga definido un fichero de tipos de cliente, otro de tipos de proveedor, otro de tipos de servicio (distribución), otro de condiciones de facturación, etc., de tal modo que si surgen nuevas combinaciones no hay que tocar programas, solo combinar nuevas entradas en los ficheros. Será importante también establecer relaciones válidas entre los diferentes conceptos, que al final definan las transacciones posibles que el sistema va a ejecutar, de manera que sólo sea posible procesar aquellas combinaciones previamente definidas en tablas de control.

Por citar un ejemplo de lo que propongo, un cliente del sistema de salud no puede recibir un medicamento registrado si no es una farmacia. Por tanto un hospital ha de comprar estos medicamentos a través de su farmacia o de una farmacia externa, pero nosotros no podemos servir ni facturar estos medicamentos a un cliente que no es una farmacia. Las entradas de nuestras tablas reflejarán las relaciones válidas entre tipos de clientes (hospital, clínica, farmacia, etc.) y tipos de productos (producto hospitalario, medicamento no registrado, medicamento registrado, etc.) y de este modo el sistema dará un aviso e impedirá —si se desea— que se asigne inventario de un producto a un pedido de un cliente que legalmente no puede comprar ese producto, evitando errores en la transacción final, y lo que es más importante, riesgos legales. Crear un programa que sirva y facture cualquier producto a cualquier cliente es fácil, pero no hablamos de eso, sino de control, seguridad y valor añadido.

Del mismo modo, podremos actuar en la definición de funciones, habrá que esforzarse en que unas no dependan de otras y las puedan condicionar, sino que las condiciones estén gestionadas a través de elementos externos, de nuevo, en una tabla o veinte tablas de la base de parámetros de ajuste del sistema.

El análisis de los procesos reflejará con claridad las funciones a ejecutar y sus relaciones con las entradas de las tablas o ficheros citados, para que los técnicos puedan aplicar estos criterios y crear programas que gestionen transacciones basadas en los parámetros incluidos en las tablas de control citadas y también en los registros de datos, ya que en este último caso, por ejemplo, habrán sido añadidos al crear un cliente, definiendo su clase y validándola en la tabla de clases de clientes, el tipo de servicio que requiere, sus particularidades para facturarle, etc., tal como haya sido predefinido anteriormente por el usuario experto o el administrador del sistema.

Tal vez parezca que todo esto es obvio, pero pueden creerme si les digo que el mundo está lleno de sistemas y procesos que no entienden nada de esto y que requieren intervención —a veces intencionada— de soporte cada vez que algo nuevo afecta al proceso de la información, por no hablar aquí de las condiciones de explotación del sistema (ya lo hice en otro artículo “La Explotación de Sistemas Informáticos”). Definir nuevas transacciones de negocio debe convertirse en un problema de administración y ajuste del sistema, en lugar de una revisión y reprogramación del mismo. Como ya he indicado, habrá un usuario, o varios, expertos en la administración del sistema y en la definición y ajuste de los parámetros que componen las transacciones que ejecuta, y aunque esta tarea puede ser subcontratada externamente como parte de un servicio, es muy conveniente que quede dentro de la empresa usuaria.

Tal vez el cliente pueda sorprenderse de que se requiere hacer una definición inicial de todos los parámetros y se pierda en el concepto, pero verá sus resultados con cierta rapidez, en cuanto pueda definir sus propias funciones dentro de lo previsto y cambiar el modo en que se procesa la información en ciertas circunstancias (un cliente que inicia una nueva actividad o negocio, por ejemplo).

Antes que nada, quiero decir que este artículo como los que le seguirán en esta serie, estarán basados en la experiencia que he acumulado desde 1971, año en el que comencé a estudiar y trabajar en los sistemas de tratamiento de la información, antes de que tuviera la posibilidad de obtener una titulación oficial que entonces no existía. Reflejaré tan solo ideas generales, sin entrar en metodologías concretas, (he tenido que aprender y utilizar distintas metodologías, según la empresa para la que trabajé), sino tan solo en las prácticas que me han dado buenos resultados independientemente del negocio, ambiente o método utilizado, la base ha sido siempre muy similar.

Una de las labores más gratificantes o frustrantes que el profesional de la informática puede llevar a cabo es el diseño de un sistema de proceso de información, tanto si es autónomo (el sistema) o forma parte de otra aplicación de mayor ámbito con la cual deberá integrarse.

Captar las necesidades del proceso, decidir cómo realizarlo y plasmar estas ideas en un diseño, tiene bastante de creativo y personal, aún cuando haya que aplicar metodologías y normas, e incluso haya que integrar otras herramientas en él. Personalmente, a lo largo de mi carrera como informático, me he sentido feliz cada vez que un sistema salido de mis manos daba el resultado esperado y permanecía activo largo tiempo sin requerir un soporte significativo o dar problemas. Debo añadir que también he tenido experiencias frustrantes (afortunadamente pocas veces), generalmente por no haber dedicado el tiempo necesario a analizar un problema y resolverlo correctamente, atendiéndolo con urgencia —y coste mínimo por supuesto—, lo que normalmente acaba volviéndose en nuestra contra, generando un problema aún mayor.

Llevo bastante tiempo sin realizar esta labor por lo que intuyo y digo “intuyo”, que las herramientas de desarrollo actuales, con bases de datos pre-definidas, lenguajes de alto nivel, etc., facilitan mucho el trabajo de desarrollo, pero estoy seguro de que sigue existiendo la posibilidad de ser creativo en la etapa de diseño, durante el proceso de análisis y definición de las necesidades del usuario final, entendiendo lo que se necesita hacer y sugiriendo soluciones, aunque sea a nivel funcional, para que orienten al equipo que después va a desarrollar estas ideas durante la programación.

Mi primera recomendación antes de diseñar un sistema es procurar comprender el proceso, pero no como algo aislado que hay que resolver sino como parte de una entidad mayor, ya sea un sistema informático más complejo o tal vez una actividad de negocio. Esto que parece obvio, no siempre se hace, porque entender el proceso es entender de qué forma parte, donde se integra, de dónde le llega la información, qué hace con ella, qué se espera obtener como resultado y dónde va a ser utilizado éste y para qué. Es decir, entender el antes y después del proceso, antes de entrar en los detalles del mismo.

Esto sin duda requerirá más tiempo dedicado tanto a la recogida de información como al análisis de la misma, añadiendo coste al proyecto, pero nos permitirá comprender ciertas particularidades del proceso exigidas no sólo por nuestro cliente, sino por las características de su negocio, por la legislación vigente o por prácticas del mercado o el entorno en el que se mueve. Con ello, además de obtener una motivación y una experiencia extra, nos convertimos en un interlocutor más efectivo frente al usuario que nos va a describir sus necesidades, en su lenguaje propio y con unos límites de visión que tal vez no nos convengan. También estaremos en condiciones de hacer preguntas de mayor calado y detectar puntos de posible riesgo o conflicto en el tratamiento de la información. Si somos capaces de hacer esto, en mi opinión, no solo podremos hacer un diseño más ajustado a las necesidades del cliente, sino que estaremos en condiciones de prevenir otras necesidades no descritas inicialmente, que se van a dar una vez puesto en marcha nuestro sistema.

El clásico “esto no me lo habías contado y no está previsto” debería quedar minimizado o anulado y por lo contrario, responder con “es fácil integrar lo que me pides” da confianza y satisfacción al cliente y crea un vínculo más sólido con su proveedor, ya que piensa que no sólo se le entiende sino que empezamos a tener una buena experiencia en su negocio y le vamos a servir de apoyo.
Con bastante frecuencia, los requerimientos de un sistema no reflejan solamente las necesidades de los procesos de la compañía donde va a ser instalado, sino que también incluye ciertas exigencias de sus clientes, principalmente de aquellos que deben seguir normativas y protocolos establecidos (clientes de la gestión y administración de la salud o de la alimentación, por ejemplo) que pueden requerir formatos de documentación específicos, con otros adjuntos y firmados que no forman parte del proceso en sí, pero que el sistema debe controlar su existencia y seguir unos ciclos específicos de aprobación, etc., y que complican bastante la forma de gestionar algo que en la empresa de al lado es bastante estándar y sencillo.

Si además, toda esa “cultura” está en la cabeza de dos o tres empleados “expertos” que la gestionan manualmente, por lo que no forma parte del flujo de información y conocimiento de la empresa, eso supone un alto riesgo para esta última, y una buena solución es diseñar un sistema automatizado y bien documentado que aporte dicha gestión de un modo ágil y claro, que pueda ser ejecutada con personal menos “culto” o bien que esa culturilla pueda divulgarse en todo el equipo de trabajo.

Plasmar los requerimientos en un documento ordenado y claro es muy importante, para presentarlo al cliente y que dé su aprobación antes de seguir adelante con el análisis funcional del sistema. Para ello, es conveniente adoptar una metodología de trabajo adecuada entre las existentes, o como mínimo adoptar un formato de documentación en el que indiquemos el nombre del proyecto, el cliente, la fecha, autor, el tema o sujeto del documento, etc. y apliquemos un código dentro de nuestra librería de documentos, para facilitar su localización, consulta y actualización. Una buena organización de la documentación es esencial para facilitar el desarrollo de cualquier proyecto.

En cuanto al mencionado incremento de coste, si no ha sido adecuadamente previsto en los presupuestos del proyecto, debería ser considerado —dentro de unos límites claro está— como una inversión de la empresa proveedora en beneficio de futuras colaboraciones con este cliente o en competiciones con otros clientes del mismo ámbito de actividad. Tener un “equipo experto” en el tema a solucionar dará un gran valor añadido a la propuesta de servicios que se presente ante cualquier otro cliente posible, además de fidelizar a los ya existentes.

En la cadena de gestión de la información hay una serie de eslabones de cuya eficiencia y toma de decisiones van a depender los que le siguen. Desde el momento en el que un usuario de la información define la necesidad de procesarla hasta que dicho proceso se produce, se siguen una serie de etapas de cuya ejecución y toma de decisiones dependerá la calidad del resultado final presentado al cliente por el área de explotación de sistemas. Igualmente, el trabajo de este departamento será más o menos complejo dependiendo de cómo se ha diseñado y pensado la operación en el entorno de producción, los controles automatizados o manuales, la necesidad de introducir algunos parámetros de proceso, etc.

Con cierta frecuencia se ponen en producción herramientas de proceso en las que no siempre se tiene en cuenta que la explotación de éstas puede ser el origen de conflictos y errores que al final, van a repercutir en la calidad del servicio que se pretende dar al cliente y muchas veces. Incluso en la calidad de la información que se le proporciona. Pues bien, aquí conviene decir que “cuando la puerta está abierta siempre entra aire y si se deja abierta permanentemente, antes o después, habrá un vendaval”.

Llevo desde 1972 trabajando en la implantación y explotación de sistemas (sí, sí, bastante mayorcito) y mi larga experiencia me demuestra que el problema que no se previene durante el diseño y desarrollo de un sistema aparece en el momento de la explotación, porque es ahí donde el sistema está vivo y es ahí donde hace su trabajo. Explotación, junto con el de atención al usuario (Service Desk o Help desk) son los dos paganos de toda la problemática generada anteriormente, que llega tan solo en diferido y sin la intensidad del cabreo del usuario, a sus autores.

Recordemos por ejemplo, cuántos sistemas actualmente en producción conocemos en los que el operador debe introducir una fecha o un parámetro a mano, o debe decidir bajo cierta norma establecida pero siempre subjetiva, si el proceso se para o continúa. En estos casos, cuando cometa una equivocación, el mensaje claro será “Ha habido un error de operador”, en lugar de “Ha habido un error de diseño y una falta de control en la validación del sistema”. Cuando hay que introducir datos manualmente, antes o después, habrá un error humano. En el caso anterior y sólo como ejemplo, crear un calendario en el sistema, mantenido por un usuario experto y validado por el cliente, es mucho más eficiente, evita errores que afectan a la totalidad del proceso y sobre todo brinda mejor servicio al usuario y asegura la calidad de la información que obtiene (al menos en ese aspecto). Claro que esto requiere pararse a pensar y dedicar tiempo y recursos al diseño y desarrollo de los procesos, pero revierte un gran beneficio en el momento de procesar la información y asegurar la calidad del resultado.

Aquí es donde se presenta el primer problema claro del análisis de riesgos-coste-beneficio. Se puede desarrollar o seleccionar un sistema que ejecute las operaciones necesarias para obtener los resultados deseados, pero habrá una gran diferencia en dedicación de recursos entre un sistema de seguridad básico, medianamente completo o lo más completo posible. Cuando hablo de un sistema de seguridad, no me refiero solo a la seguridad de la información en sí misma (por ejemplo acceso lógico y físico a los sistemas), que es esencial, sino también a la seguridad de su tratamiento. Esto incluye minimizar las intervenciones manuales de operador, la identificación previa y prevención de fallos y errores de proceso, la recuperación de datos cuyo ciclo de proceso no se haya completado, el control de calidad de los datos obtenidos, etc. En esta etapa, los costes pueden dispararse y si al cliente se le ha prometido una solución económica (¡quién no la quiere!), y además vamos mal de tiempo en la fecha de entrega o pasados de horas en el desarrollo del sistema podemos encontrarnos frente a una decisión crucial: hasta dónde y cómo se dedican recursos y tiempo a implementar las herramientas de control y recuperación/re-arranque de los procesos a ejecutar.

Por tanto, el sistema se podrá entregar al cliente para su explotación, tras unas pruebas en las que este verá unos resultados acordes a lo que necesita (es lo mínimo que se le puede pedir a un sistema), pero seguramente no podrá analizar (casi siempre porque no sabe cómo hacerlo) la seguridad del sistema que se le va a entregar, ni el riesgo de incidencias que pudieran afectar al proceso de su información y por tanto a la calidad de la misma y el impacto en sus negocios.

Estamos en una época que me parece la vuelta al pasado. Mi primer trabajo fue como programador en un “Centro de Cálculo”, como lo llamaban por los años 70, ya que se hacía el análisis, la programación y posteriormente el proceso de los datos del cliente y se le entregaba la información procesada. Como la empresa era responsable de todo el ciclo, se preocupaba bastante de su efectividad y rentabilidad, por lo que la calidad de los programas se vigilaba de cerca. Recuerdo que cuando probé mi primer programa en aquel Honeywell Bull “Gamma-10”, había un tribunal detrás de mí, compuesto por compañeros del departamento (yo era el novato), el analista y el jefe de explotación, que abrieron la panza del sistema (un armario enorme) para ver la circulación de las tarjetas de datos por la banda central de la CPU. Si iban todas seguidas, sin huecos entre ellas, es que el programa estaba bien diseñado y no perdía ciclos de procesador, si no, había que volver con él a la mesa y revisarlo. ¿Por qué se hacía esto? Porque el precio por minuto de uso de este sistema era alto y había que rentabilizarlo haciendo el máximo de procesos diario.

Después vinieron las computadoras para PYMEs y luego el tener cada uno su propio CPD, pero los costes de esta última solución solo fueron rentables un corto tiempo y hoy estamos de nuevo en la época de externalización de servicios provistos por terceras empresas. El gran problema que se presenta en estos casos es la diversificación de proveedores, ya que frecuentemente cuando quien diseña un sistema no va a explotarlo y pretende abaratar su coste y posterior mantenimiento, lo simplifica a tal punto que la operación del mismo asume riesgos que no debería. Cuando se producen incidencias o errores, el cliente suele apuntar al proveedor que explota el sistema y no al que lo ha diseñado.

Es por tanto vital establecer procedimientos y protocolos de validación y compromiso en la implantación y gestión de los sistemas cuya responsabilidad está repartida entre varias empresas. En estos casos, los intereses de los proveedores pueden ser incluso contrarios, lo que repercute en perjuicio del cliente, que debe asumir la nada fácil tarea de control y coordinación de los mismos. Para ello es conveniente una buena experiencia en ambas áreas: la de diseño y desarrollo y la de explotación de sistemas.

Hace bastantes años (1971) que me dio por aprender informática, materia entonces apenas conocida por el gran público. Me encantaba pararme a mirar cómo giraban los carretes de cinta magnética en sus unidades encristaladas o cómo se leía una caja de tarjetas perforadas en un instante, aquel tremendo bicho que se veía en las oficinas de IBM en la plaza de la Porta al Mar (Valencia), con un centro de proceso de datos que tenía una fachada de cristal que daba a la acera de la plaza. Desde allí, veía un IBM 360 con su lector de tarjetas y cinta perforada, sus unidades de disco más grandes que una lavadora sus unidades de cinta magnética, tremendos carretes de cinta de 9 milímetros de ancho y también una impresora enorme, que se comía las cajas de papel continuo a una velocidad endiablada. Todo aquello, atendido por dos operadores que vestían su bata blanca y gestionaban el sistema a través del teclado y el papel impreso de una máquina de escribir IBM eléctrica, de bola. Todos los caracteres estaban moldeados en una bola de plástico que giraba sobre dos ejes para poner el carácter solicitado frente a la cinta entintada y ¡zas! le arreaba al papel y allí quedaba impreso.

El caso es que me inscribí en un curso de programador de aplicaciones para el sistema IBM citado que daban en una escuela privada, en lenguaje ensamblador, de la que conservo el diploma correspondiente. La casualidad hizo que mi primer y único programa hecho durante ese curso lo fuese a compilar y probar en el citado ordenador que tanto tiempo había admirado. Cuando me senté junto al operador de bata blanca y la gente me veía desde la calle, me sentí privilegiado por manejar aquella nueva cosa: la informática, consiguiendo crear un programa para aquella enorme máquina siguiese y ejecutase mis instrucciones. Ahí terminó inicialmente mi relación con el IBM que tanto admiraba.

Después de hacer otros tres cursos de programador, cada uno en su propio ensamblador, otra casualidad me llevó a trabajar justo en la oficina de al lado de donde estaba IBM, en el primer piso del mismo edificio. Allí estaba Nixdorf Computer, una empresa creada por el señor Heinz Nixdorf en Alemania con sucursales en España y que fabricaba y comercializaba sus propios computadores. En realidad el que yo comencé a gestionar era más bien una gran facturadora, pero tenía su sistema operativo, su lenguaje ensamblador propio y sus dispositivos de entrada y salida de información. La consola de la Nixdorf 820/15 era una máquina de escribir IBM idéntica a la del sistema 360 y esto lo aprovechaban los comerciales de la casa para convencer al cliente de que aunque compraban un computador de su marca, en realidad era un IBM más económico (cosas de aquellos tiempos). La verdad es que se lo merecían porque cuando entraban por la puerta o llamaban por teléfono, decían que querían información para comprar “una IBM”. La palabra ordenador o computadora no era fácil para ellos, era más sencillo hablar de una IBM.

Ha pasado mucho tiempo desde aquello y ahora, en la sala Idea de las oficinas de S2 Grupo en Valencia, junto a los viejos equipos que allí se exponen, hay dos cajas metálicas de tamaño folio y unos cinco centímetros de grosor que contienen el sistema operativo de la Nixdorf 820/15 en una y la definición de la base de datos del cliente en la otra. Esta última lleva dos bandejas con orificios alrededor de los cuales se hacía pasar un hilo, bien por arriba o por abajo, para que una vez situadas las bandejas en la placa, los núcleos de ferrita que pasaban por los orificios hicieran su trabajo al generar un cero o un uno binario según el pulso de corriente que pasaba alrededor.

Así funcionaba este sistema y a esta “memoria cableada” la llamaban “memoria fija” y su capacidad máxima era de 1024 bits (no bytes) ya que además las instrucciones en lenguaje máquina que el sistema gestionaba tenían un formato como este:

|_,_,_|_,_,_,_|_|_,_,_|_,_,_,_|_,_,_,_|

|Comando...|I| Dirección de memoria|

Es decir, 3 + 4 bits para el comando (0.0 a 7.F), 1 bit de índice (0 o 1), y 3 bits + 4 bits + 4 bits para la dirección de memoria (0.0.0 a 7.F.F)

Los programas se escribían en un ensamblador propio, se perforaban en tarjetas de cartulina de 80 columnas, se compilaban y depuraban los errores y finalmente se pasaban a fichas de banda magnética (tamaño A4 con perforaciones para el arrastre en ambos lados y una banda magnética impresa en su derecha), donde se almacenaban programas y datos de clientes, productos, etc. Es decir, la base de datos estaba en registros y cada registro en una ficha física. La seguridad de los ficheros (se llaman así porque se componían de “fichas”) dependía de quién custodiaba la llave del archivador de fichas.

La base de datos se definía manualmente: se perforaba en tarjeta de 80 columnas, se compilaba y una vez correcta, se perforaba en una cinta perforada, que era un carrete de cinta de papel donde se perforaban las imágenes de los cableados de las placas que he citado. Se ponía la cinta en un proyector con luz interior, se ponía la placa encima y donde pasaba la luz, se cableaba un uno, donde no había luz, se cableaba un cero, pasando el hilo de cobre por encima o por debajo del orificio correspondiente. Es difícil de concebir para alguien que no haya tenido relación directa con ello.

Lo bueno del sistema es que la estructura de los ficheros (iba a decir la base de datos, pero no, no lo era), quedaba cableada para siempre o hasta la siguiente modificación, así que había que afinar mucho en su definición. Lo malo era que si fallaba un cable había que parar la máquina hasta volver a soldarlo.

El acceso a los registros de los ficheros era directo: el operador buscaba la ficha en cuestión y la introducía en el lector a mano. Se leía, se imprimía el movimiento correspondiente sobre ella y se actualizaba la banda magnética, luego se devolvía a su sitio. Otro acceso era el secuencial, para obtener un balance o un listado de clientes, productos, etc. En este caso se iban introduciendo en secuencia una a una.

Bendito invento fueron los cassettes de cinta magnética, donde cabían un montón de fichas, peeeeeero… no había posibilidad de acceso directo, solo secuencial. Al final aparecieron los discos magnéticos, pero esa fue otra historia.

A continuación hay algunas de las fotos de las placas que mantenemos en la sala Idea como parte de la historia de la informática que hoy es otra cosa; un smartphone tiene 100 veces más capacidad de proceso y memoria que el módulo de alunizaje del Apolo 11. Todo el mundo pretende saber mucha informática, pero normalmente no han visto una tarjeta perforada ni las han leído mirando las perforaciones contra la luz de la ventana, ni tampoco han depurado programas leyendo vuelcos de memoria en papel, en hexadecimal binario, ni tampoco van con bata blanca. Pues eso, que es otra cosa.