Responsabilidad invisible

Leo hoy un artículo de Méneme que ha llegado a la portada: La culpa es de nadie (no en mi turno). Y como tiene más razón que un santo, aprovecho su entrada para extenderme más sobre el asunto. Eso si, llevando el ascua a la sardina tecnológica.

España es uno de los países a la cabeza de escurrir el bulto. Los españoles somo grandes expertos en no responsabilizarnos. No somos los únicos, la plaga de no querer ser responsables de nada es algo que se extiende por muchos más países. Otro día diferenciaremos desde el punto de vista del derecho la diferencia entre responsabilidad y culpa. Ya de entrada he usado la palabra responsabilidad y no culpa, como hacen en el artículo que me ha servido de detonante, justamente por eso. Aquí hablaré de la responsabilidad, como la actitud de responder de los propios actos. Es decir, que, si uno hace algo negativo, no se esconda y lo reconozca cuanto antes para tratar de resolverlo. Y al contrario también, si uno hace algo positivo que se le recompense. Y para otro día otra gran tragedia nacional: darle premios al que no es responsable del éxito.

Como de costumbre ya me he desviado de mi tema. Como muchos sabéis una parte de mi carrera profesional la he realizado en Departamentos de Procesos y de Informática de grandes empresas financieras. Así que voy a centrar la responsabilidad en las tareas informática en grandes empresas (aquí podemos incluir también a Administraciones Públicas). Cuando yo entré a trabajar, una gran mayoría del software que se empleaba en mi empresa era creado por empleado de la propia empresa. Y todos los procesos de negocios eran diseñados, validados y probados por empleados de la empresa. Esto ahora sería una rareza… pero os juro que así era. Además, los responsables de cada área estaban claros y muy bien delimitados. Así si debíamos hacer un nuevo programa para responder a la necesidad de un nuevo proceso de negocio, todo el mundo sabía quien era responsable de las especificaciones funcionales, quien, de las especificaciones técnicas, quien de los cambios en bases de datos, quien del programa en host, quien del programa en el terminal, quien de los listados, quien de la parte contable, quien de probar la aplicación… De esta manera cuando había retraso uno siempre sabía donde llamar. Si algo no funcionaba bien, también era fácil encontrar la solución, puesto que era sencillo acudir al responsable de esa parte, que como no podía esconderse, pues enseguida se ponía a la tarea de resolver el problema.

Pero el tiempo pasó y los Departamentos de IT empezaron a llenarse de:

1. Jefes miedosos
2. Consultores
3. Empresas subcontratadas
4. Reguladores externos que daban más valor a un sello de alguien con nombre anglosajón… que al responsable con nombre de aquí que lo hacía antes.

No tengo claro que fue antes, si el jefe miedoso, el regulador que gustaba de anglosajones o los consultores. Pero si tango muy claro que la relación parasitaria fue un éxito para todos ellos y un fracaso para estas empresas, sus clientes, sus empleados y sus accionistas. Y lo sigue siendo.

El sistema funcionaba así. Llegaba un jefe que no quería responsabilizarse de nada (a pesar de que cobraba mucho, justamente por ser el Responsable). Había que hacer un nuevo proceso. Así que contrataba a un consultor (que muchas veces venía avalado por el regulador externo). El consultor le firmaba un contrato donde se responsabilizaba de todo (pero con una sección de letra pequeña… que al final lo convertía todo en agua de borrajas) y además subcontrataba el desarrollo de las aplicaciones en otras empresas (que podían volver a subcontratar, eso sí, siempre con un contrato de responsabilidad). De esta manera, si algo salía mal, el jefe siempre podía decir: “Yo contraté a los mejores, venían recomendados por un inspector del… y además tenemos un contrato lleno de SLAs, si los han incumplido nos pagarán la indemnización correspondiente”. Y pasaban algunas cosas como las que os voy a contar:

1. Pagando una fortuna por lo que he han hecho antes dentro de la empresa.
   Esto es un clásico en el mundo de la consultoría y el desarrollo de software. Recuerdo yo hace dos décadas que me llaman de la planta noble de mi en aquella época empresa de por las mañanas. Teníamos que preparar una modificación para el software que gestionaba los Préstamos Sindicados que concedíamos o en los que formábamos parte del sindicato. El aplicativo estaba afectado por el efecto del año 2.000 y por el cambio de la peseta al Euros y debíamos crear un nuevo aplicativo. Yo sabía de préstamos, pero poco o nada de sindicados. Así que me fui al Departamento que los gestionaba. Allí el jefe de la unidad estuvo casi un mes enseñándome todo lo que sabía sobre la parte de gestión y contabilización de este tipo de préstamos. Con ello realicé un análisis funcional que parecía el Quijote. Pase casi 4 meses más con el mismo jefe de unidad repasándolo todo, para que no se me escapase nada. Nos validaron el análisis y se envió a Informática para que lo programasen. Salió una primera versión del programa con varios fallos y nos pusimos a resolverlo… pero llegó una reorganización interna. A mi me enviaron a otro Departamento, los programadores uno fue ascendido a analista y otro también sufrió un cambio de unidad… y el jefe de préstamos sindicado sufrió un accidente y causo baja en la empresa…
   Pasado un año y medio, veo en la Intranet que hay un nuevo aplicativo de préstamos sindicados en la Entidad. Y me pica la curiosidad. Así que cuando tuve ocasión hable con uno de los compañeros que trabajaban allí cuando yo había hecho el análisis. Y cuando le pregunté, empezó a reírse y me contó: “Vinieron de Friends y Co Consulting. Estuvieron por aquí dando vueltas y más vueltas, presentaron varias propuestas, pero ninguna servía. Al final se fueron a hablar con el antiguo jefe a su casa. Este les dio una copia de tu análisis… y albricias, cambiaron el tipo de letra, y lo presentaron. Y claro ésta, se aprobó. Solo nos costó más de lo que tú y yo cobraremos en toda nuestra vida laboral…”
2. Reparación que no llega al afectado
   Muchas veces cuando el trabajo de desarrollo y diseño es externo hay problemas. En estos casos hay que revisar el contrato para ver si el consultor es responsable de algo y si es así, pues debe hacer frente al pago de una indemnización. Esto es un mecanismo perfecto para que el jefe irresponsable duerma tranquilo. Si alguien le pregunta, le basta con enseñar el contrato. Y si pasa algo, pues a reclamar a ver si hay suerte. Lo malo con esto es que se producen fallos, que, aunque conllevan una indemnización pecunaria, no compensa el daño real creado y sobre todo no llega al afecto final. Como siempre un ejemplo. Hace más de una década en mi empresa de por las mañanas introdujeron un nuevo aplicativo completo para toda la empresa. Los jefes que ya habían adoptado el nuevo paradigma lo habían subcontratado todo fuera (y los de fuera que eran como mis jefes… pues también habían ido subcontratando). Un día una parte muy grande del aplicativo, deja de funcionar en todas las Oficinas (por aquel entonces más de 1.500). Y todos los empleado y clientes que tratan de interactuar con esa parte del aplicativo se encuentran con muchos errores. Además generamos cargos y abonos no reales en las cuentas de los clientes. Y cuando estos reclaman no sabemos qué decir. Conforme van llegando llamadas de Oficinas al CAU (Centro de Atención al Usuario) van tomando nota. Al final alguien se da cuenta que todas las incidencias de las dos últimas horas se parecen (no hace falta que diga que el CAU también se había subcontratado fuera en una empresa externa) y avisan a los expertos de la consultora. Estos empiezan a buscar y no encuentran el problema… entonces nos llaman a los viejos del lugar. Nosotros de momento podemos certificar que no va casi nada de esa parte del aplicativo. Y de momento un compañero de la mesa de al lado mía recuerda algo. Va a su agenda y comprueba que es noche había programado hacer un cambio en esos módulos, provocado por un cambio de legislación contable. Mira quien es su contacto en la empresa que tiene que hacer la subida la host de los programas. Lo llama y pregunta si están listos. Este contacto le deriva a otro y ésta a un último… que está en otro país que tiene una diferencia horaria de 10 horas con España. Llamamos allí y despertamos a alguien, que somnoliento nos dice que no nos preocupemos, que las 10 horas de la noche como estaba previsto había subido a real los cambio… claro a las 10 horas en su país, las 8 de la mañana en España. El pobre se había confundido de hora y de día (no me extraña, pues trabajaba con nuestro horario el pobre). Para resumirlo, hubo que hacer una parada en producción y pedir que nos cargaran otra ves los programas anteriores. Este error que si lo hubiésemos hecho nosotros unos años atrás se habría resuelto en una hora… pues nos llevó el resto del día. Al final nuestros jefes estaban contentos. La culpa había sido de la filial sudamericana de un subcontratado y nos habían pagado 80.000 Euros de indemnización. Pero los más 100.000 clientes afectados solo sabían que no éramos de fíar. Los 4.000 empleados que se día tuvieron que salir tarde del trabajo dando explicaciones… tampoco vieron un Euro.
3. La culpa fue de los astros, los astrólogos, los mayas, los incas… pero no nuestra
   Esto paso hace menos años. Fue cuando estaba de moda la idea de que el fin del mundo estaba cerca por mor de una leyenda de una civilización precolombina de América. Por esas fechas mi empresa de por la mañanas subcontrató el seguimiento del batch. El batch es como se llama en la Informática Bancaria a los procesos que se hacen con las Oficinas cerradas, como cargar y abonar recibos, calcular cuotas de préstamos y cargarlos, apuntes contables… Son programas que corren normalmente por la noche, porque el ordenador central no tiene la carga del trabajo de las Oficinas. Y para comprobar que todo vaya bien, pues siempre hay una guardia física en las propias instalaciones y otros compañeros que están en su casa, pero deben estar disponibles para acudir si algo no va bien. Esto no es barato, porque son horas nocturnas que se pagan más que las diurnas. Bueno, a lo que iba. A las pocas semanas de subcontratar esa tarea, llegamos a las ocho de la mañana y vemos un aviso en la Intranet diciendo que estamos funcionando a medio gas y que muchos de los procesos nocturnos no se han podido realizar.
   Unos días después, la empresa que tenía la contrata de esa tarea, hizo una presentación PowerPoint con el título: “La conjunción de los astros que hizo invetable el fallo”. En realidad, el error vino por un error de orden a la hora de corres los programas del Batch. Así que ejecutaron antes uno que esperaba tener unos saldos en unas cuentas que calculaba un programa anterior que no se ejecutó. El error apareció un módulo. Avisaron al encargado de ese módulo y éste lo paró. Pero se les escapó la ejecución del siguiente proceso, que volvió a fallar por lo mismo… al final pararon el batch… y aquello fue un pandemónium. Pero la culpa no fue tal, seguón el Power Point, fue invitable, porque Marte se había puesto en conjunción con Venus, la Tierra y con Jupiter…

Y de esta forma conseguimos que nadie fuese responsable de nada en los Departamentos de IT de las grandes empresas. Como yo digo a veces cuando hablo de esto con alguno de mis compañeros ya jubilados: “Ya no hay hombres como los de antes en IT”. Y esto es uno de los grande males de la informática departamental actual: nadie quiere ser responsable de nada. Si sale bien, el premio será para otro y si sale mal… marrón para ti. Así que todo es buscar subcontratas y externos. Así que avances y nuevas tecnologías… lo mínimo.