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.
La respuesta tiene 4 letras: ITIL