Manolo Palao muestra, una vez más, su generosidad para con Gobernanza de TI a través de esta nueva contribución. A diferencia de sus habituales ‘texticulillos‘, se trata, en este caso, de un extenso artículo, que junto a los de Rui Borges y Mark Toomey -que, hace ya meses, le precidieron-, pasa a engrosar los contenidos de la sección ‘Firma invitada‘.
El autor, sin mencionarlo de forma explícita, ofrece, a lo largo del texto, una reiterada referencia al sexto principio general del buen gobierno corporativo de las TIC, tal y como recoge la norma ISO/IEC 38500:2008. Corporate governance of information technology: el factor humano. Recuerda cómo dicho factor subyace, de manera omnipresente, a los innumerables errores que el mundo de la Informática ha conocido.
Tras ofrecer un repaso por algunos de los más sonados fiascos tecnológicos y presentar una taxonomía de la naturaleza de tales errores, finaliza su exposición alzando una lanza en defensa de los propios sistemas informáticos e, incluso, de sus creadores.
Paralelamente, recuerda también el papel que, como responsables últimos de rendir cuentas, han de jugar aquellos individuos dotados de la pertinente capacidad y autoridad para dirigir y controlar -gobernar- el uso que, de tales sistemas, se hace en el seno de las organizaciones.
¡Disfrútenlo como si de un elongado texticulillo se tratase!
Presunción de inocencia (1)(2)
Hace unos treinta y nueve siglos se esculpió el ‘Código de Hammurabi‘ -conservado en el Louvre-, que es considerado como la primera codificación conocida de derechos y obligaciones humanos.
Como referencia, quizá más familiar, Moisés bajó del Sinaí con las ‘Tablas de la Ley‘ cinco o seis siglos después.
Hace unos 75 años, Isaac Asimov acuñó las ‘Tres Leyes de la Robótica’ –luego evolucionadas a la Roboética– codificando derechos y obligaciones de robots, demonios y otro software de Inteligencia Artificial.
En 2002 Rodney Brooks, director del MIT Artificial Intelligence Laboratory, pronosticaba que, igual que históricamente se habían ido reconociendo ciertos derechos -por ejemplo, a un trato digno- a muchos animales y, sobre todo, a las mascotas, era plausible que surgiesen corrientes de reconocimiento de derechos a algunas de esas máquinas, especialmente a las más antropomorfas y a las que ‘conviviesen’ en nuestros hogares -robots domésticos; ¡las nuevas aspiradoras no sindicadas, para entendernos!-.
Si bien los profesionales de los SI (Sistemas de Información) y de las TIC (Tecnologías de la Información y las Comunicaciones) estamos sujetos -por convicción y/o adhesión a un código ético profesional- a ciertos compromisos respecto a los SITIC, ello no obliga, en general, a otras personas; lo cual favorece un pernicioso, generalizado y continuado linchamiento impune de los SITIC e, indirectamente, de sus profesionales. Pernicioso, porque nos impone un sambenito; pero, sobre todo, porque puede desembocar en un fallo sistémico.
Me explicaré; pero, antes, descendamos a lo concreto.
Botones de muestra
Creo que las siguientes referencias son autoexplicativas y se aceptarán como meros botones de muestra de algo mucho más generalizado.
«La juez sustituye la fianza de un millón de euros al alcalde de Seseña por otra de 10.000 / Emite un auto de rectificación para aclarar un error informático debido a «introducir más dígitos de los que procedían«» (3)(4)
«La patronal fotovoltaica ASIF pidió un análisis a una empresa, que concluyó que podía tratarse de que el contador considerara que las 12 de la mañana eran las 12 de la noche o fallos informáticos» (5)
«La lista de premiados -premios Max de la SGAE entregados el 3 de mayo de 2010- publicada en la página web de la SGAE «por un error informático«» (6)
«EE UU busca el ordenador fantasma / Los reguladores bursátiles descartan el factor humano como causa del pánico que sacudió a Wall Street» (7)
«Las máquinas se apoderan de Wall Street y provocan el pánico en el mercado / El Dow Jones llegó a caer más del 9,16% por el temor a la crisis griega y un conjunto de operaciones descontroladas / […] Un senador aprovechó ayer para reclamar que se ponga coto a las máquinas en las operaciones bursátiles. El demócrata Ted Kaufman denunció que se había puesto de manifiesto una vez más «el potencial de los ordenadores gigantes de alta capacidad para alterar el mercado y crear el caos» en lo que denominó «la batalla de los algoritmos». Kaufman presentará una enmienda a la ley de reforma financiera para que se endurezca la regulación.» (8)
««No podemos permitir que un error tecnológico espante a los mercados y provoque pánico» [desplome bursátil], señaló el congresista demócrata Paul Kanjorski. El propio presidente, Barack Obama, pidió aclarar el desplome para «evitar que algo así vuelva a suceder».» (9)
Como no parece probable que ni Hammurabi ni Moisés vayan, a estas alturas, a ocuparse de este tema, nos incumbe a los profesionales -sobre todo a través de nuestras asociaciones- intentar reencauzarlo.
Reflexiones, actitudes y actuaciones
Para reencauzarlo parecen obligadas ciertas reflexiones, actitudes y actuaciones.
Lucius Annaeus Seneca -cordobés, coetáneo de Jesucristo, tutor y consejero de Nerón- ya afirmó que «errare humanum est, perseverare diabolicum» [errar es humano, perseverar diabólico].
Lo que fue parafraseado -y convertido en eslogan- por Alexander Pope (1688-1744) [más papista que el papa], en su famoso verso: «To err is human, to forgive divine» [errar es humano, perdonar divino]. (10)
El famoso HAL (11) 9000 (12) no era tan perverso como parecía. Simplemente, fue programado así (‘heurístico-algorítmico’ [¡signifique esto lo que signifique!]). Pero eso era ciencia ficción: ¡intentemos mantenernos en la realidad!
-
En segundo lugar, aceptar que “…. sin duda es un abuso del lenguaje … y si … [el] error lo hubiesen tenido hace 20 años, sería un error «mecano-gráfico«; o hace 100 años, un error «plumo-gráfico«; … la cuestión es tipificar el error sobre el instrumento y no sobre la persona que lo comete …pues al final, como todos los errores, es humano(-gráfico)«. (13)
-
En tercer lugar, asumir que, pese a todo, hay/ha habido muchos [¡demasiados!] “errores informáticos/tecnológicos”; esto es, errores humanos en materias informáticas/tecnológicas. En algunos de los cuales he/(¿quizá?) hemos incurrido por omisión o acción.
La tabla siguiente (14) extracta alguno de los más señalados, e indica su coste:
El excelente reciente «artículo de Darren Dalcher (15), … cita algunos importantes errores informáticos que efectivamente fueron tales. Como caso más relevante, al final de la sección 2 se dice que el fracaso en la introducción de un sistema informático en la Oficina de Recaudación del Reino Unido causó que no se enviasen recordatorios a los asalariados sobre que tenían que actualizar sus contribuciones al sistema nacional de seguros. ¡Y que, ahora, 10 millones de personas sufren recortes en sus pensiones debido a eso!». (16)
Otro proyecto valorado por Darren por el impacto del proyecto en la fase de producción es “un sistema de envío de ambulancias que fue entregado a los usuarios -al tercer intento – y falló, posteriormente, en producción, dando lugar a potenciales pérdidas de vidas humanas”.
Dice Darren: “La práctica contemporánea de desarrollo de software se caracteriza sistemáticamente por proyectos descontrolados, entregas retrasadas, presupuestos excedidos, funcionalidad recortada, y una calidad cuestionable, lo que a menudo se traduce en cancelaciones, reducción del alcance, y un ciclo significativo de revisiones”.
Y continúa: “El resultado neto es una acumulación de desperdicios, medidos tradicionalmente en términos financieros. Por ejemplo, en 1995, los proyectos fallidos en EEUU costaron … un total de 140 000 M USD; … en 1996, 100 000 M USD; … en 1998 75 000 M USD”.
A mí, en este artículo, me interesa resaltar un aspecto que el texto de Darren -y toda la excelente Monografía de la que forma parte- tratan, pero sólo de forma secundaria: el de las pérdidas y molestias ocasionadas por el uso de sistemas una vez que fueron dados de alta para su explotación.
Incluso, cuando no hay evidencia de defectos o fallos en el proyecto, pueden, evidentemente, darse fallos en la explotación.
La tabla presentada más arriba reseña unos cuantos fiascos, pero los presenta desde la óptica del promotor del proyecto -las pérdidas o costes incurridos por el fracaso-, no desde la óptica de los costes/perjuicios ocasionados a los usuarios por la operación de sistemas defectuosos o por la operación defectuosa de los sistemas.
En 2007 el Ayuntamiento de Torrelodones (Madrid) (17) -por lo que parecía tratarse de un simple error administrativo- emitió dos veces recibos, distintos, pro-forma, para el cobro de la ‘tasa de recogida de basura’.
La empleada/funcionaria encargada del tema contesta al teléfono -a la tercera llamada, en las anteriores ‘estaba desayunando’- y reconoce que sí, que lo que me acontece es un error, “parte de un error masivo”, y que «… nada, que arreglado«. Cuando entonces le pido confirmación fehaciente de que lo mío -ya que no lo de todos- ha sido corregido, como error masivo del Ayuntamiento, que es de su responsabilidad, me dice imperturbable que ¡para eso, que presente un recurso!, y que, entonces, se revisará mi duplicado.
O sea, que unos miles de recibos erróneos se corrigen con unos miles de recursos administrativos.
Mientras, yo sigo teniendo dos recibos pro-forma enviados por el Ayuntamiento: el correcto y el erróneo. ¿O serán los dos erróneos? ¿Y los demás masivos? Afortunadamente, pagado que fue uno de los recibos, el silencio administrativo condonó -espero- el otro.
¡Séneca tenía razón: perseverar en el error es diabólico!
- En cuarto lugar, está la cuestión del huevo o la gallina (o más académicamente, de la recursividad).
Me parece evidente, a estas alturas de este breve e informal artículo, que todos debemos aceptar que en la raíz de todo error ‘informático’ hay un error ‘humano’.
La cuestión ahora es de trazabilidad y, sobre todo, de imputabilidad (chargeability).
¿En qué estrato(s) organizativo(s) radica la responsabilidad por el error?
- En quinto lugar, está la cuestión del temido y temible ‘fallo sistémico’.
Parece mentira que los denunciantes de ‘fallos informáticos’ -políticos o periodistas, muchos de ellos, por lo que no es tan sorprendente; profesionales, en otras ocasiones, lo cual resulta más difícil de comprender- no entiendan, o ignoren, el principio básico de que NUNCA se debe culpar al sistema. (¡Aunque fuese verdad!).
Culpar al sistema es concitar un ‘fallo sistémico’: la profecía que se autocumple.
Los protocolos de actuación de los portavoces de células de emergencia, de entidades en crisis y -a mucha menor escala- aquellos propios de los ‘chaquetas rojas’ (o ‘verdes’, o ‘azules’) en aeropuertos u otros servicios públicos coinciden. Siempre hay que decir: 1) que las causas se desconocen y se están investigando; y 2) que se ha debido, probablemente, a un fallo humano: NUNCA a un FALLO DEL SISTEMA.
Reconocer la causa humana es atenerse a la verdad, pero además es políticamente interesante: si falla el sistema, ¿qué nos queda?
De hecho, ciertos manuales de gestión de incidentes recomiendan acusar en público -incluso en falso, o sin suficiente información- a algún empleado y, luego, disculparse ante los vejados y compensarles de algún modo.
- En sexto lugar, reconocer que «un sistema informático -por el hecho de estar construido por humanos y, ¡ojo!, especificado o solicitado por humanos- es imposible que sea infalible». (18)
- En séptimo lugar, recordar que, por una parte, los errores (humanos) pueden no ser indeseables, sino tolerados, e incluso, buscados -como en ciertas fases del proceso científico o técnico: prueba y error-; y, por otra, que (como se sabe en gestión de la calidad) no todo error acarrea necesariamente una disfunción o un defecto.
Los defectos o fallos son discrepancias entre producto/proceso y especificaciones/normas (o características deseables, incluso no especificadas).
“Un «defecto» [/fallo] es una instanciación individual de alguna no conformidad con algún requisito, mientras que un producto/proceso/servicio defectuoso [deffective], contiene uno o más «defectos».” (19)
«Los defectos se clasifican, generalmente, en tres grandes grupos. Estos grupos son (20): 1) defectos inherentes (resultantes de la fabricación o de las materias primas); 2) defectos fabricados (resultantes de la transformación de las materias primas en una pieza, producto o servicio terminado); y 3) defectos inducidos por el servicio (generados durante el funcionamiento de algún componente)”.
«Los defectos pueden deberse a una materia prima/componente defectuoso, o a una pieza/componente defectuoso (procedente de un proceso previo), a una puesta a punto (‘setup’)/ensamblaje o mantenimiento defectuoso de la maquinaria/material, a métodos erróneos, o a errores humanos«. (21)
A la postre, todos los defectos se deben a errores humanos. Esta es la razón por la que la lucha contra los defectos es fundamentalmente una cuestión de formación y motivación del personal.
Los errores pueden clasificarse según 10 grandes criterios (22): 1) omisiones; 2) errores debidos a falta de comprensión; 3) errores de identificación; 4) errores debidos a falta de experiencia; 5) errores voluntarios (consentidos); 6) errores inadvertidos; 7) errores debidos a lentitud; 8 ) errores debidos a falta de normas; 9) errores por sorpresa; y 10) errores intencionales.
No todos los errores causan defectos/‘defectuosos’ [deffective]/fallos. Sí los suelen causar los: 1) olvidos; 2) errores debidos a desconocimiento; 3) errores de identificación; 4) errores por inexperiencia; 5) errores voluntarios; 6) errores por inadvertencia; 7) errores debidos a lentitud; 8 ) errores debidos a falta de estándares o normas; 9) errores por sorpresa; y 10) errores intencionales.
Se han estudiado y publicado correlaciones fuertes entre errores y defectos (23). Por ello se conocen diversas grandes estrategias de prevención de defectos. Una de tales estrategias la constituyen las técnicas de poka-yoke (24); si bien éstas pueden resultar más fáciles en el mundo ‘real’ (industria manufacturera, por ejemplo), que en el ‘virtual’ (aplicaciones web, por ejemplo).
Frente a errores, defectos y fallos sólo hay una panacea: calidad. Pero calidad integral.
- En octavo lugar, aceptar que «[L]os usuarios (y sobre todo los responsables últimos del trabajo de los usuarios) deben saber que un sistema informático … es imposible que sea infalible. Y, por ello, son tanto -yo diría que aún más- responsables de las consecuencias de no verificar que el sistema funciona, como lo son los propios informáticos.
Una vez, en cierta empresa donde trabajé [Llorenç Pagés] hace ya muchos años, nos asignaron un supervisor del trabajo informático, entre cuyas frases favoritas se encontraba: «Me gusta la Informática porque es una ciencia exacta. Es como las Matemáticas o el ajedrez, exacta». Claro, con esta mentalidad, ¡cualquier error en un sistema informático es culpa del informático!». (25)
Para concluir
Los sistemas informáticos son, frecuentemente, imputados por haber causado errores, en ocasiones graves. Ello es falso -por cuanto el origen de todo error es humano- e imprudente -por cuanto culpar al sistema degrada su credibilidad-.
La presunción de inocencia es ciertamente un derecho -también de los sistemas y de quienes los desarrollan-; pero la historia demuestra que los derechos se conquistan y que hasta que son ampliamente reconocidos y respetados -y luego, de vez en cuando- hay que invertir mucho activismo y tiempo.
Artículos relacionados
- Estar encima (por Mark Toomey)
- Gobernanza de TI: La Dirección de Orquesta de los Sistemas de Información (por Rui Borges)
- Vea, también, la sección «Texticulillos» para leer más artículos del mismo autor
-
(1) Copyright 2010-2011, Manolo Palao. Socio de ATI nº 1103. Socio senior.
(2) Publicado, en una primera versión, en el nº 206 de Novática, la revista de la Asociación española de Técnicos de Informática, ATI. Verano de 2010.
(3) Fuente: Diario «El País«. Madrid, 14 de enero de 2010. URL: http://www.elpais.com/articulo/espana/juez/sustituye/fianza/millon/euros/alcalde/Sesena/10000/elpepuesp/20100114elpepunac_13/Tes.
(4) Nota de Manolo Palao: Las negritas, en las citas, son mías.
(5) Fuente: Diario «El País«. Rafael Méndez. Madrid, 5 de mayo de 2010. URL: http://www.elpais.com/articulo/sociedad/Francia/ofrece/Espana/intercambio/residuos/nucleares/elpepusoc/20100505elpepisoc_3/Tes. Véase cuadro «Las eléctricas desmienten el timo de los huertos solares nocturnos«, a pie de artículo.
(6) Fuente: Televisión Española, TVE1, «Telediario 1«, 4 de mayo de 2010.
(7) Fuente: Diario «El País«. Sandro Pozzi. Nueva York, 7 de mayo de 2010. URL: http://www.elpais.com/articulo/economia/EE/UU/busca/ordenador/fantasma/elpepueco/20100507elpepueco_13/Tes.
(8) Fuente: Diario «El País«. Sandro Pozzi. Nueva York, 7 de mayo de 2010. URL: http://www.elpais.com/articulo/economia/maquinas/apoderan/Wall/Street/provocan/panico/mercado/elpepueco/20100506elpepueco_20/Tes.
(9) Fuente: Diario «El País«. Sandro Pozzi. Nueva York, 8 de mayo de 2010. URL: http://www.elpais.com/articulo/economia/EE/UU/replantea/negociacion/electronica/derrumbe/bursatil/elpepueco/20100508elpepieco_7/Tes.
(10) Fuente: AnswerBag.com. URL: http://www.answerbag.com/q_view/666955.
(11) HAL = IBM desplazando cada carácter al precedente [según algunos].
(12) Fuente: Wikipedia.com. URL: http://en.wikipedia.org/wiki/HAL_9000.
(13) Nota de Manolo Palao: El autor de la feliz frase – que reproduzco con permiso- es Dídac López, en correo cruzado con motivo de la preparación de este artículo.
(14) Fuente: Palao, Eduardo. «Del Caos al Buen Gobierno: Paradigmas y Tendencias en las Tecnologías de la Información y las Comunicaciones y su relación con el Buen Gobierno«. Universidad de Deusto. Máster en Buen Gobierno de las TIC, II Edición (MaGTIC2). Trabajo Fin de Máster. Usado con autorización.
(15) Fuente: Dalcher, Darren. “El éxito de los proyectos de software: yendo más allá del fracaso”. Revista Novática, nº 200. Julio-agosto de 2009, p. 45.
(16) Nota de Manolo Palao: Contribución de Llorenç Pagés Casas, con motivo de la preparación de este artículo.
(17) Nota de Manolo Palao: Donde resido y tengo mi despacho. Naturalmente, por si alguien manifestara más interés, tengo un expediente completo y detallado. Naturalmente, sin que el incidente se haya resuelto satisfactoriamente aún (junio de 2010).
(18) Véase nota 16.
(19) y (20) Fuente: Juran, J. M. «Juran Quality Handbook», 1979, p. 19-23.
(21) Fuente: Hayward, G. P. «Introduction to Nondestructive Testing«. ASQC. Wisconsin, 1978, p. 2.
(22) Fuente: Hiroyuki Hirano. «Kaizen«, 1988.
(23) Fuente: Juran, J. M. «Juran Quality Handbook», 1979, p. 18-22.
(24) Fuente: Hiroyuki Hirano & Nikkan Kogyo Shimbun. «Poka-yoke«. Ernst & Young, 1991. Véase también Wikipedia. URL: http://es.wikipedia.org/wiki/Poka-yoke.
(25) Véase nota 16.
Gobernanza de TI 