Firma invitada


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.

  • En primer lugar, reconocer que todo error es humano.

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

  1. Estar encima (por Mark Toomey)
  2. Gobernanza de TI: La Dirección de Orquesta de los Sistemas de Información (por Rui Borges)
  3. 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.

Anuncios

Gobernanza de TI conmemora, hoy, el primer aniversario de la publicación de la norma ISO/IEC 38500:2008. Con motivo de esta especial celebración, la sección ”Firma invitada“, incorpora un demoledor y clarificador artículo (original y traducido, como viene siendo habitual en esta sección) de un apreciado colega. Se trata de Mark Toomey, fundador y Presidente Ejecutivo de Infonomics, Pty. Ltd., Presidente del Comité Técnico IT-030 de Standards Australia y co-creador de las normas AS 8015:2005 e ISO/IEC 38500:2008.

Bajo el título “Estar encima”, Mark ofrece una clara descripción del concepto de ‘gobierno corporativo de TI’, del porqué de la necesidad de establecer dicho buen gobierno y de cómo en la raiz de tal necesidad se encuentra el alejamiento (asincronía) que se ha ido dando, con el paso de los años, entre las personas que dirigen las organizaciones y las que están a cargo de sacar adelante las nuevas iniciativas tecnológicas y de mantener plenamente operativas las existentes.

En definitiva, Mark describe un panorame en el que, quienes debían hacerlo, han dejado de estar encima.

 

Estar encima

Cuando comencé mi carrera en el mundo de las Tecnologías de la Información (TI), los primeros “mini-ordenadores” aún estaban siendo adaptados a las aplicaciones comerciales; y las organizaciones, que nunca antes habían utilizado nada más potente que una calculadora, estaban comenzando a automatizar sus negocios.

En aquellos días no había “CIOs“ y eran pocos los departamentos de TI reconocidos como tales. Trabajábamos directamente con la gente que conocía y hacía funcionar el negocio para diseñar nuevas formas de operar, en busca de una mayor eficacia y eficiencia. Desarrollábamos el software al mismo tiempo que rediseñábamos  – siquiera mínimamente –  el negocio; y a la vez que se instalaban los nuevos sistemas, todo el mundo era entrenado y “re-adaptado”. La gente de arriba se lo tomaba con gran interés, no sólo supervisando el proceso, sino participando activamente para maximizar el valor de lo que estábamos haciendo.

La mayoría de aquellos proyectos finalizaron con mucho éxito, aportando lo que la organización demandaba, a un coste aceptable y conduciendo tanto a un mayor rendimiento, cuanto a un crecimiento del negocio.

Desde entonces, la tecnología se ha abaratado; la capacidad del software se ha incrementado; la dependencia por parte de los negocios  – y de la gente –  respecto de la tecnología se ha hecho más profunda; los proyectos que abordan las organizaciones se han hecho más ambiciosos; y la certidumbre en cuanto al éxito con las TI, ¡ha disminuido!

¿Por qué dicho éxito resulta, hoy, tan esquivo? ¿Por qué las organizaciones son, tan a menudo, víctimas de fallos, tanto en los proyectos, como en aquellas operaciones que tienen una alta dependencia de las TI? ¿Es que la tecnología ya no es buena? ¿Es que la gente que proporciona esa tecnología no está bien formada, o, acaso, es incompetente? ¿Es que los métodos que usamos no son satisfactorios? ¡No! Hoy, incluso el ordenador personal más barato es mucho más fiable que aquel “mini-ordenador” de 1975. El software en los años 70 era extremadamente simple y parco en funcionalidades; y mucho más propenso a fallos de lo que lo es actualmente. Hoy tenemos grandes esperanzas en la enorme capacidad del software, de modo que toleramos menos fallos. Hace treinta y cinco años la mayoría del personal informático no tenía formación universitaria  – muy pocos tenían una licenciatura -.  Algunos eran elegidos para sus trabajos porque habían superado una prueba de aptitud; pero la mayoría se habían visto implicados porque sus patrones necesitaban a alguien que conociese el negocio y que ayudase a informatizarlo. Y en cuanto a los métodos, hace treinta años el desarrollo de métodos se encontraba en su más absoluta infancia; sin madurez en nada y, definitivamente, sin normas.

Por tanto, parece que, hoy, en el lado de la tecnología, estamos mucho mejor de lo que estábamos en los 70. Sin embargo, ahora tenemos proyectos de TI con una tasa de fallos por encima de lo aceptable; tenemos proyectos marginalmente exitosos que no aportan el beneficio cuantitativo, tangible, esperado; y tenemos negocios expuestos a un riesgo de daño, como consecuencia de sistemas que fallan. ¿Por qué?

Creo que la razón principal de esta situación no es que hayamos fallado al tratar de mejorar desde el lado de la tecnología; sino que, en realidad, lo que hemos hecho, ha sido desarrollar un problema en el lado del negocio. Donde una vez los ejecutivos de la alta dirección estuvieron involucrados y los consejos de aministración/comités de dirección supervisaban muy de cerca, ahora lo que tenemos son directivos demasiado ocupados y demasiado alejados y consejos que muy raramente se involucran. La implicación del negocio en los proyectos de TI se ha dejado en manos de mandos intermedios, muchos de los cuales están sobrecargados intentando una y otra vez recortar gastos, y muchos de los cuales han sido escasamente advertidos sobre su papel y responsabilidades en el éxito de los proyectos.

Hace treinta años, lo que hoy día llamamos proyectos de TI  – esto es, proyectos de cambio o mejora del negocio a través del uso de las TI –  eran objeto de un buen gobierno porque las personas encargadas de la gobernanza a alto nivel estaban directamente involucradas. Hoy en día, a medida que dicha implicación ha disminuido, así ha decrecido la eficacia del marco general de gobierno corporativo. Y la experiencia de los últimos años nos ha demostrado que, al tiempo que se reconoce que el gobierno es importante, intentar resolver el problema a base de más reglas, herramientas y marcos de referencia que invariblemente ponen el foco sobre la gestión de las TI, en lugar de en su gobierno, no es una estrategia que lleve a buenos resultados.

Un gobierno corporativo de las TI, eficaz, depende no sólo de herramientas, o de procesos, o de modelos, o de estructuras organizativas. Depende, simple y llanamente, de que la gente que gobierna la organización  – el consejo y la alta dirección –  comprenda y asuma su responsabilidad para aplicar sus habilidades de gobierno al uso de las TI, tal y como ya las aplican al resto de aspectos que forman parte del negocio.

Cuando lo hagan, las herramientas, los modelos, las estructuras y otros recursos que hemos diseñado para ayudarnos a controlar y a garantizar la eficacia en el uso de las TI, aportarán su valor más significativo.

Pensando en esos ejecutivos y directivos, la norma internacional ‘ISO/IEC 38500:2008. Corporate governance of information technology’, ofrece una clara directriz que les guiará en el desempeño de sus responsabilidades. La norma está escrita empleando su propio lenguaje; es tan concisa como puede serlo una guía de gobierno corporativo; y, les habilita para controlar aquello que ellos no entienden, poniendo el foco sobre las cosas que ellos sí entienden.

Gobernanza de TI conmemora, hoy, el primer aniversario de la publicación de la norma ISO/IEC 38500:2008. Con motivo de esta especial celebración, la sección ”Firma invitada“, incorpora un demoledor y clarificador artículo (original y traducido, como viene siendo habitual en esta sección) de un apreciado colega. Se trata de Mark Toomey, fundador y Presidente Ejecutivo de Infonomics, Pty. Ltd., Presidente del Comité Técnico IT-030 de Standards Australia y co-creador de las normas AS 8015:2005 e ISO/IEC 38500:2008.

Bajo el título “Being on top …”, Mark ofrece una clara descripción del concepto de ‘gobierno corporativo de TI’, del porqué de la necesidad de establecer dicho buen gobierno y de cómo en la raiz de tal necesidad se encuentra el alejamiento (asincronía) que se ha ido dando, con el paso de los años, entre las personas que dirigen las organizaciones y las que están a cargo de sacar adelante las nuevas iniciativas tecnológicas y de mantener plenamente operativas las existentes.

En definitiva, Mark describe un panorame en el que, quienes debían hacerlo, han dejado de estar encima.

 

Being on top …

When I began my career in information technology, the first “mini-computers” were being adapted to commercial applications, and organisations that had never before used anything more powerful than an adding machine were beginning to automate their businesses.

There were no Chief Information Officers in those days – and few established IT departments.  We worked directly with the people who knew the business, and ran the business, to design new ways to operate the business more effectively and efficiently.  We developed the software in parallel with redesigning (however minimally) of the business and as the new systems were installed, everybody in the business was retrained and adapted.  The people at the top took a great deal of interest, not just monitoring progress, but actively participating in the work to maximise the value of what we were doing.

Most of those projects were very successful – delivering what the organisation wanted, at a price that was acceptable, and leading to both better performance and growth of the business.

Since then, the technology has become cheaper, the capability of the software has increased, the dependence of the business (and people) on information technology has become profound, the projects that organisations undertake have become more ambitious, and the certainty of success with IT has diminished!

Why is success so elusive today?  Why are organisations so often victims of failure in both projects and operations that involve significant dependence on IT?  Is it that the technology is no good?  Is it that the people delivering the technology are poorly trained, or incompetent?  Is it that the methods that we use are unsatisfactory?  No! Today even the cheapest PC is much more reliable than the mini computer of 1975.  Software from the 1970’s was extremely simple and narrow in functionality, yet much more prone to faults than it is today.  Today we have high expectations based on the enormous capability of software, and so we tolerate software faults less.  Thirty-five years ago, most IT people were not university trained – few had degrees.  Some were chosen for their roles because they had an aptitude test – but most got involved because their employers needed somebody who knew the business to help get it automated.  And as for methods – thirty years ago the development of methods in computing was in its absolute infancy – with no maturity in anything and definitely no standards.

So today on the technology side we seem to be much better off than we were in the 1970’s.  Yet now we have IT projects failing at an unacceptable rate, many marginally successful projects failing to deliver any tangible, measured benefit, and business at risk of damage from systems that fail.  Why?

I think that the major reason for this problem is not that we have failed to get better on the technology side – but that we have actually developed a problem on the business side.  Where once the top executives were involved and the board monitored closely, now the top executives are too busy and too remote, and the board is hardly involved at all.  Business engagement in IT projects is left to middle managers – many of whom are grossly overloaded following round-after-round of cost cutting, and many of whom are poorly briefed on their roles and responsibilities in the success of projects.

Thirty years ago, what we today call IT projects (that is projects that change or improve the business through the use of IT) were well governed because the people responsible for top level governance were directly engaged.  Nowadays, as that engagement has diminished, so too has the effectiveness of the governance arrangement.  And experience of the past few years has shown us that while governance is important, attempting to fix the problem with yet more rules, tools and frameworks that invariable focus on the management of IT does not lead to good outcomes.

Effective corporate governance of IT depends not on tools, or processes, or frameworks, or organisation structures.  It depends, simply and fundamentally, on the people who govern the organisation – the board and the top executive, understanding and delivering on their responsibility to apply their governance skills to the use of IT as they do to the other aspects of the business.

When they do that, the tools, frameworks, structures and other resources that we have devised to help us control and assure the effectiveness of IT use will add their most significant value.

For those top executives and directors, the straight forward guidance they need on their job is found in ISO/IEC 38500.  It is written in their language, is as concise as any guide on corporate governance can be, and enables them to control what they do not understand, by focusing on the things that they do understand.

Los párrafos que siguen ofrecen la versión traducida al español, con permiso del autor, Rui Borges, del artículo “IT Governance: O Maestro dos Sistemas de Informação“, también publicado en su versión original, en portugués, en estas mismas páginas.

Borges, Director de Desarrollo de Negocio de TI, para España y Portugal, de SAS Institute ofrece una visión aglutinadora de la gobernanza TIC  – en tanto que elemento central de una estrategia de sincronización y armonización de cada uno de los componentes del entramado tecnológico de la organización -,  como si de dirigir una gran orquesta se tratase.

 

Gobernanza de TI: La Dirección de Orquesta de los Sistemas de Información

Cuando se observa una orquesta, se constata que todos los instrumentos son relevantes y que el papel del director en la coordinación de cada uno de ellos es muy importante, ya que ayuda a transformar un conjunto de sonidos en una sinfonía.

En los Sistemas de Información se observa una situación semejante. Hay profesionales, procesos, instrumentos/herramientas y un director que, unidos y coordinados, generan un proceso de transformación que demuestra el valor y el rendimiento de las Tecnologías de la Información (TI). A este proceso de transformación y medición, se le aplica una arquitectura modular de Gobierno de TI que permite obtener de cada profesional, proceso e instrumento, lo mejor que cada uno puede dar en beneficio del conjunto.

Es verdad que en la fase de preparación, o ensayo, de una orquesta cada instrumento intenta, aisladamente, obtener una mejoría en su rendimiento; sin embargo, su evaluación final va a depender del resultado producido por la totalidad del grupo: la orquesta.

Como ocurre en las orquestas, el estado de madurez de la dirección de los Sistemas de Información es esencial para medir la calidad del servicio prestado y el retorno de la inversión realizada, sobre la base de la ganancia efectiva para los usuarios de dicho servicio.

De este modo, el gran desafío a que se enfrentan los Sistemas de Información es obtener e integrar, en un todo, de forma armoniosa, lo mejor de cada componente, ya que ninguna solución aislada es estratégica ni eficaz por sí misma.

Un proyecto de TI se compone de muchos elementos y procesos, más o menos complejos, que varían en función de los desafíos de las unidades de negocio y de los sectores del mercado. Sólo la Gobernanza de TI permite dirigir esta orquesta, impidiendo incoherencias, falta de armonía y ritmo, y evitándole sentimientos de insatisfacción, u otros problemas, al usuario final.

Un vez más, lo mismo aplica a los Sistemas de Información. Cada aplicación o proceso interno debe mejorar su eficiencia; pero sólo en conjunto y coordinados de acuerdo a “buenas prácticas” van a conseguir generar valor y demostrar resultados. Igualmente importante es no excluir ningún elemento de la orquesta, cualquiera que sea su papel. Existen aplicaciones en el área de los Sistemas de Información que podrán no ser estratégicas o prioritarias, como, por ejemplo, las soluciones de Gestión Financiera de TI o de Gestión del Rendimiento de TI; pero que han de ser tenidas en cuenta en la implantación de un modelo de Gobernanza de TI.

En este sentido, los Directores de Sistemas de Información necesitan herramientas complementarias para controlar y medir la contribución y el beneficio de la función de TI en las organizaciones, ya sea en régimen interno o de manera externalizada.

Existe un modelo de madurez de Gobernanza de TI que cubre estos requisitos. El modelo, basado en el “Marco de referencia Analítico del Negocio” (Business Analytics Framework), estructurado y distribuido en cinco fases  – Estabilización, Optimización de Recursos, Optimización del Servicio, Optimización Financiera y Gobernanza –  refleja el enfoque de dirección de las Tecnologías de la Información asociada a la creación y demostración de valor, sincronizando los Servicios con la estrategia de la organización y presentando resultados en cada nivel del modelo.

Es por esto que se hace tan importante conocer la función estratégica que desempeñan algunos de los componentes del modelo de Gobernanza de TI. Conocer significa compartir la información a lo largo de toda la estructura de la organización y saber cómo va a responder el departamento de TI a cada uno de los retos de la empresa. En este punto surgen soluciones como la Gestión del Rendimiento de TI o la Gestión Financiera de TI, que habilitan la presentación sistematizada y resumida del desempeño de las TI dentro de las organizaciones.

Estas soluciones permiten sincronizar las TI con las diferentes áreas de la organización y, además de la revisión de los indicadores de negocio, facilitan, también, la medida del valor de cada uno según su correspondiente dimensión y cuadrante. En esta medición, se aplica un modelo “de arriba a abajo” y de correlación de indicadores, que va a uniformizar los procesos y a establecer niveles de madurez; orientándose hacia las verdaderas necesidades del negocio, y evitando, de este modo, inversiones mal dirigidas.

Cuestiones como la optimización de recursos y servicios de TI, la implantación de procesos de TI, el cumplimiento de los niveles de servicio y la optimización de los modelos de coste de los servicios de TI, entre otros muchos, están cubiertos por una solución de Cuadro de Mando Integral de TI.

También debería añadirse que cuanto mejor sea el proceso de calificación y selección de las inversiones en TI, mejor será el proceso de dirección y seguimiento de las mismas, el cual pasará a ser impulsado por la medición de los resultados. En estas condiciones, queda garantizado el éxito de los proyectos ejecutados y se facilita, de modo más correcto, el planteamiento de futuras apuestas.

Cada organización deberá tener su propio modelo de gobernanza, pero son las implementaciones por etapas las que pueden ser más eficaces, una vez que acompañan y contribuyen a la madurez de la empresa. A fin de garantizar la menor inversión para los niveles de servicio acordados, la adopción de un modelo de Gobierno de TI deberá ser una decisión estratégica e inevitable para cualquier organización que tenga como objetivos la optimización de los costes de explotación, la adopción de arquitecturas innovadoras de apoyo a nuevos modelos de negocio y la optimización de la infraestructura de TI.

La Gobernanza de TI es, por excelencia, el modelo para la dirección de las TI. Implantada correctamente, garantiza un resultado final mucho mayor que el proporcionado por los distintos componentes de forma aislada. Al introducirse nuevas disciplinas en el ámbito de los Sistemas de Información, como la Gestión Financiera de TI y la Gestión del Rendimiento de TI, se va más allá de la simple ejecución, evaluando y preparando los futuros, y presentes, desafíos de las organizaciones.

Gobernanza de TI comienza, hoy, una nueva sección que, bajo la etiqueta “Firma invitada“, dará cabida a interesantes artículos remitidos por otros profesionales y colegas del sector. Sin duda, sus opiniones, comentarios y aportaciones enriquecerán de manera notable la información contenida en este cuaderno de bitácora y reforzarán con ello el espíritu con el que nació: Informar-Formar-Opinar, en español, sobre el Gobierno Corporativo de la Información y sus Tecnologías Afines, en el seno de las organizaciones.

Fieles a ese mismo espíritu, en aquellos casos en los que el artículo no haya sido escrito en lengua española, será ofrecido, tanto en su versión original, como en español. Éste es, precisamente, el caso de hoy: Rui Borges, Director de Desarrollo de Negocio de TI, para España y Portugal, de SAS Institute ofrece en “IT Governance: O Maestro dos Sistemas de Informação” una visión aglutinadora del gobierno de TI  – en tanto que elemento central de una estrategia de sincronización y armonización de cada uno de los componentes del entramado tecnológico de la organización -,  como si de dirigir una gran orquesta se tratase.

 

IT Governance: O Maestro dos Sistemas de Informação

Quando se observa uma orquestra constata-se que todos os instrumentos são relevantes e que o papel do maestro na coordenação de cada um deles é muito importante, já que ajuda a transformar um conjunto de sons numa sinfonia.

Nos Sistemas de Informação encontra-se uma situação semelhante. Há profissionais, processos, instrumentos/ferramentas e maestro que, unidos e coordenados, geram um processo de transformação que demonstra o Valor e a Performance da gestão das Tecnologias de Informação (TI). Para este processo de transformação e medição, aplica-se uma arquitectura modular de IT Governance que permite obter de cada profissional, processo e instrumento, o melhor que cada um pode dar em benefício do todo.

É verdade que na fase de preparação ou ensaio de uma orquestra cada instrumento tenta isoladamente obter uma melhoria de performance, no entanto, a sua avaliação final vai depender do resultado produzido pela totalidade do grupo: a orquestra.

Tal como nas orquestras, o estágio de maturidade da gestão dos Sistemas de Informação é essencial para aferir a qualidade do serviço prestado e o retorno do investimento realizado, com base  nos ganhos efectivos dos utilizadores desse serviço.

Assim, o grande desafio que se coloca aos Sistemas de Informação é obter e integrar de forma harmoniosa o melhor de cada componente num todo, já que nenhuma solução isolada é estratégica e eficaz por si própria.

Um projecto de TI é composto por muitas componentes e processos, mais ou menos complexos – que variam em função dos desafios das unidades de negócio e dos sectores de mercado – só o IT Governance permite gerir esta orquestra. Tal como o maestro, o IT Governance evita a incoerência, desarmonia e as falhas de ritmo, e previne os sentimentos de insatisfação ou outros problemas junto do utilizador final.

Mais uma vez, o mesmo se aplica aos Sistemas de Informação. Cada aplicação ou processo interno deve melhorar a sua eficiência, mas só em conjunto e coordenados de acordo com as “Boas Práticas” vão conseguir criar valor e demonstrar resultados. Igualmente importante é não excluir nenhum elemento da orquestra, qualquer que seja o seu papel. Existem aplicações na área dos Sistemas de Informação que poderão não ser estratégicas ou prioritárias, como por exemplo as soluções de IT Financial Management ou de IT Performance Management, mas que têm que ser levadas em conta na implementação de um modelo de IT Governance.

Neste sentido, os Gestores de Sistemas de Informação necessitam de ferramentas complementares para Controlar e Medir o contributo e benefício do Serviço TI nas Organizações, quer em regime interno ou em Outsourcing.

Existe um modelo de maturidade de IT Governance que abrange estes requisitos. O modelo baseado no Business Analytics Framework, estruturado e faseado (Stabilization, Resource Optimization, Service Optimization, Financial Optimization e Governance), reflecte a abordagem da gestão das Tecnologias de Informação associada à criação e demonstração de valor, alinhando os Serviços com a estratégia da organização e apresentando resultados em cada nível do modelo.

É por isto que se torna tão importante conhecer a função estratégica que desempenham alguns dos componentes no modelo de IT Governance. Conhecer significa partilhar a informação por toda a estrutura da organização e saber como é que o departamento de TI está a responder a cada um dos desafios da empresa. É aqui que entram soluções como o IT Performance Management e de IT Financial Management, que viabilizam a apresentação sistematizada e resumida do desempenho das TI nas organizações.

Estas soluções permitem alinhar as TI com as unidades de negócio e, para além de analisarem os indicadores do negócio, permitem também medir o valor de cada um deles de acordo com a respectiva dimensão e quadrante. Nesta medição, é aplicado um modelo “top-down” e de correlação de indicadores, que vai uniformizar os processos e estabelecer níveis de maturidade, focalizando-se nas verdadeiras necessidades do negócio, evitando investimentos mal direccionados.

Questões como a optimização de recursos e serviços de TI, a implementação de processos de TI, a garantia dos níveis de serviços e a optimização dos modelos de custeio dos serviços de TI, entre muitos outros, estão abrangidos por uma solução de IT Scorecard.

Importa ainda acrescentar que, quanto melhor for o processo de qualificação e selecção dos investimentos em TI, melhor será o processo de gestão e monitorização desse investimento que passa a ser orientado pela medição dos resultados. Nestas condições, o sucesso dos projectos implementados é assegurado e o planeamento de apostas futuras mais correcto.

Cada organização deverá ter o seu modelo de governação, mas são as implementações faseadas que poderão ser as mais eficazes uma vez que acompanham e contribuem para o nível de maturidade da empresa. A implementação de um Modelo de IT Governance deverá ser uma decisão estratégica e incontornável para qualquer organização que tenha como objectivos a optimização dos custos operacionais, a adopção de arquitecturas inovadoras para suporte de novos modelos de negócio e que pretendam optimizar a infra-estrutura de TI de maneira a garantir o menor investimento para os níveis de serviços acordados.
 
O IT Governance é por excelência o modelo de gestão das TI. Implementado correctamente, garante um resultado final muito superior ao proporcionado pelas componentes isoladas. Ao introduzir-se novas disciplinas na área dos Sistemas de Informação, como o IT Financial Management e o IT Performance Management, vai-se para além da simples execução, avaliando e preparando os desafios actuais e futuros das organizações.