Lejos de pretender resultar ofensivo  -vaya lo de “pobre” con todo el respeto-,  el titular que precede estas líneas no hace sino constatar una evidente realidad: a diferencia de lo ocurrido con su hermana mayor  -a la que se ha dedicado no poca literatura-,  de la norma australiano-neozelandesa AS/NZS 8016(Int):2010. Corporate governance of projects involving information technology investments apenas se ha oído hablar en el año que lleva en vigor.

¡Poco se ha escrito sobre ella! ¡Pocas charlas/conferencias se le han dedicado! Una búsqueda en Google de la cadena “AS/NZS 8016(Int):2010″ arroja unos escuálidos 85 resultados. ¡Haga la prueba!

La publicación, en enero de 2005, de la norma australiana AS 8015-2005. Corporate governance of information and communication technology  , constituía el final de una etapa, iniciada cinco años atrás por un grupo de individuos preocupados y motivados pòr la aparición en el panorama corporativo y gubernamental australiano de una serie de escándalos económicos, en cuya génesis se encontraban determinadas inversiones  -dotadas de un notable componente tecnológico-  mal dirigidas y peor controladas.

Sin embargo, la aparición de la AS8015  -reeditada, en junio de 2008, como norma internacional ISO/IEC 38500:2008. Corporate governance of information technology, “pseudónimo”, por el que, hoy, es más conocida-  supuso, también, la apertura de una puerta a nuevos desarrollos normativos en ámbitos particulares del uso de las Tecnologías de la Información y las Comunicaciones. Dichos ámbitos se concretaban, particularmente, en dos: los proyectos de TI y las operaciones de TI.

Del segundo de aquellos, nada se ha vuelto a saber. Transcurridos seis años desde que la norma base  -AS8015-  viera la luz, no hay constancia de la publicación de resultado alguno sobre la gobernanza de las operaciones de TI  -supuesta AS8017-.  Cabe, en este sentido, pensar que los desarrollos habidos en estos años en los ámbitos de la gestión de los servicios de TI  -aparición de la serie de normas ISO/IEC 20000, en 2005, y sus recientes y actuales revisiones, unidas a la publicación de la tercera versión del modelo ITIL, en 2007-  hayan contribuido a frenar el ímpetu inicial de los promotores de la serie AS 801x. De confirmarse este extremo, habría que lamentarlo, por cuanto se estaría dejando pendiente de aclarar la, nunca suficientemente entendida, diferencia entre Gobernanza y Gestión, y, con ello, aquellos aspectos relativos a la toma de decisiones sobre los servicios de TI que reciben y sustentan las operaciones de negocio de las organizaciones. Estas últimas nada tendrían que decir  -asunto, en todo caso, más que discutible-  sobre cómo se operan los sistemas de información y de soporte al negocio; sin embargo, sí parece que debieran asumir un destacado protagonismo a la hora de decidir: qué servicios se han de recibir  -¿cuáles, por qué y para qué?-;  qué alcance habrían de tener tales servicios  -¿departamental o corporativo?-;  a qué coste  -¿qué dinero ha de dedicárseles, a juicio de la organización?-;  qué modelo de aprovisionamiento de dichos servicios conviene más al negocio  -¿interno o externo?-;  etc. ¡El tiempo despejará la incertidumbre sobre la AS8017!

Retomando el primero de los dos ámbitos citados más arriba, la materialización, hace un año, de la AS8016, publicada como norma provisional, permite ver con un mayor optimismo  -al menos, a priori-  las tareas de desarrollo normativo en torno a las inversiones en nuevas actuaciones, apoyadas significativamente en la tecnología; esto es, en torno a los que  -de forma simplificada, en exceso-  se denominan proyectos de TI.

Con un cierto paralelismo en relación a lo expuesto para las operaciones de TI, la elaboración de una norma sobre el gobierno corporativo de aquellos proyectos de negocio que impliquen inversiones en Tecnologías de la Información y las Comunicaciones, ha supuesto dar un paso más allá de la mera gestión de proyectos  -disciplina suficientemente cubierta por modelos del sector como CMMI-DEV, PMBoK o PRINCE2 y otras normas-,  poniendo el acento, no en la ejecución de tales proyectos, sino en el beneficio que, para la organización, supondrá abordarlos.

Este enfoque centrado en el valor de las inversiones  -ya explorado por ISACA, en su modelo Val IT, desde 2006; ITIM, VMM o, más recientemente, MoV, son otros ejemplos-  favorece, asimismo, la ampliación de la perspectiva tradicional del Gobierno Corporativo, centrado en la conformidad y en el cumplimiento con normas y regulaciones, hacia un nuevo planteamiento que apunta a la contribución (rendimiento/rentabilidad) que, desde TI, se hace a los resultados del negocio.

Este nuevo discurso, centrado en términos como priorización de inversiones, gobierno del valorrealización de beneficios, etc., debería servir, además, para atraer, hacia la problemática que plantean las inversiones tecnológicas, a todos cuantos tengan responsabilidades en la dirección y control de las organizaciones. Lamentablemente, la poca atención que parece haber recibido la norma en su primer año de vida, crea serias dudas sobre el interés que haya podido causar, siquiera, entre los más fervientes seguidores de su hermana mayor.

¡No se sorprendan! ¡Sigue tratándose de mensajes que no van dirigidos a nosotros, los técnicos!

 

Artículos relacionados

  1. Dos años de ISO 38500: ¿es éste el camino?
  2. ISO/IEC 38500:2008. Un año difundiendo el concepto de ‘Buen Gobierno Corporativo de las TIC’
  3. ISO/IEC 38500:2008. Un “salvavidas” en la difusión del concepto de “Gobierno Corporativo de las TIC”
  4. Gobernanza de TI en una línea (revisada)
  5. Una “misiva” para la alta dirección

¡Así es, cuatro!

Recurrir a un artículo que “Gobernanza de TI” publicaba el 28 de marzo de 2009 puede ser una agradable, y acertada, forma de conmemorar este cuarto aniversario. La reflexión recogida aquel día bajo el epígrafe “¿ITG 2.0?” llevaba a afirmar lo siguiente:

… puede decirse que en nuestro mercado se ha empezado a hablar  – respectivamente, a oir –  de Gobierno de TI hace apenas un par de años.

Efectivamente, fue en 2007 cuando comenzó a verse una difusión a mayor escala del concepto de Gobierno de TI desde diferentes frentes. Esa corriente, iniciada, tal vez a finales de 2006, tuvo su origen, en gran medida, en foros de gestión de TI  – gestión de servicios de TI -;  no en foros de gobierno corporativo, propiamente dichos, lo que ha llevado a crear una cierta confusión“.

Los anteriores párrafos encerraban dos realidades que, aún hoy  -como entonces-,  conservan una plena vigencia:

  • de un lado, 2007 había marcado, en cierto sentido, la explosión de la fiebre “gubernamental” en nuestro mercado. [Poco, o nada, tuvo que ver en ello la aparición de esta bitácora en el mes de febrero  -el miércoles, 7-].  Fue el año del inicio de la “masificación” (popularización) del término “gobierno/gobernanza” y, con ello, de un uso y un abuso que, cuatro años y unas cuantas decenas de artículos después, persiste  -si cabe, de manera más acentuada-;
  • de otro, la confusión a la que hace referencia la cita anterior tampoco se ha visto aclarada: se sigue hablando de amor (gobierno), cuando se quiere decir sexo (gestión). Los intereses en el lado del colectivo TIC  -al menos, en una parte del mismo-,  también, en este caso, se mantienen; y el alejamiento de las TI, por parte de los “líderes del negocio” (disculpen el anglicismo), no se ha visto recortado.

La situación descrita no constituye sino un reforzado argumento en favor del compromiso que, desde estas páginas, siempre se ha tenido con la información, formación y opinión sobre el Buen Gobierno Corporativo de la Información y sus Tecnologías afines. Compromiso que ahora se renueva.

Permítanme invitarles a participar de dicho compromiso y agradecerles la que, hasta ahora, ha sido su cálida compañía.

¡Gracias a todos! (Y manténganse al otro lado, ;-)).

 

Artículos relacionados

  1. Gobernanza de TI, 3er. aniversario
  2. ¡2º aniversario!
  3. ¡Bienvenido!
  4. ¿ITG 2.0?

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.

Corresponde a cada uno valorar la contribución que 2010 ha hecho a la consecución de sus particulares expectativas  -públicas/profesionales, y especialmente, privadas/familiares-.  Confío, no obstante, que, pese a la coyuntura, la  mayoría de vosostros, sino todos, lo recordéis como el próspero año que, con la mejor voluntad  -expresada doce meses atrás-,  os deseaba en mi última felicitación navideña.

La de hoy llega con un pequeño retraso. Retraso que me obliga a suprimir el siempre amable “¡Felices Pascuas!” y a restringir mis renovados buenos deseos a esta próxima, y ya Vieja, velada; y a todo lo que queda por venir.

Personalmente, una lectura optimista del año transcurrido  -ha habido de todo-  me lleva a confesaros la satisfacción que ahora me produce el hecho de poder extender mi agradecimiento a un mayor número de seguidores y visitantes  -todos amigos-  de Gobernanza de TI. Esto os incluye a vosotros, César, Natalia y Christian, que acabáis de uniros a nuestra comunidad-e en LinkedIn. Vuestra participación, con total seguridad, atraerá nuevas informaciones, formaciones y opiniones, tal y como reza el principio fundacional de la bitácora.

Mantengo la confianza  -no puede ser de otro modo-  en la consolidación de nuestra disciplina y en la aceptación de los mensajes que encierra. ¡Sabemos que no es más que cuestión de tiempo! Ese tiempo que aún juega a nuestro favor y que, mucho me temo, seguirá justificando nuestros argumentos en los próximos años.

¡Feliz noche y los mejores deseos para la Nueva Década 2011-2020!

 

Artículos relacionados

  1. Feliz Navidad y Próspero Año Nuevo 2010

Nuevo encuentro de Gobernanza de TI con Manolo Palao, su sana ironía y su buen humor (particularmente presentes en el Texticulillo™ de hoy). ¡Están Uds., tan sólo, a unas lineas de comprobarlo!

Fiel a su compromiso con los objetivos de esta bitácora, Manolo desarrolla su análisis, un vez más, en torno a uno de los principios generales del Buen Gobierno Corporativo de las Tecnologías de la Información: la conformidad.

El mundo de la regulación resulta prolífico. Sirva, como ejemplo, el caso de España: aquí, el número de reglamentaciones que pretenden guiar  -las más de las veces, limitar-  las actividades de ciudadanos y organizaciones se cifra, según los expertos, en miles, decenas de miles  -hay quien eleva ese número por encima del centenar (de miles)-.

Esa miríada de normas es un claro reflejo de la aparente “alegría” con que el regulador de turno ejerce su función. Otra prueba de tal “alegría” puede encontrarse en la existencia de no poca reglamentación ambigua, sujeta a interpretación, y, por tanto, de dudoso, cuando no difícil, cumplimiento. A ello se refiere Palao en su exposición.

Como apuntara, en relación al relevante papel de la conducta humana en el Gobierno Corporativo de TI, el destacado académico e investigador del MIT, Peter Weill, “de poco sirve definir sistemas de gobernanza formales, si no se siguen“. Cabría, con toda humildad, parafrasearle diciendo “de poco sirve definir [complejas] reglamentaciones, si no se pueden seguir“.

 

Texticulillo™ nº 13: Perfiles y Auditoría de Sistemas (1)(2)

Un día de estos me tengo que pasar por el centro de salud a que me hagan una analítica porque debo tener la perplejidad muy baja de densidad. Tan baja, que me sumo en ella sin poder salir a flote; y, si consigo seguir respirando, es gracias a lo largo que tengo el snorkel.

Una de las inmersiones más profundas que he hecho en mi perplejidad  -y en esa fosa abisal continúo-  fue la primera vez que leí el punto 4 del Artículo 4 del Real Decreto 994/1999, de 11 de junio, por el que se aprueba el Reglamento de medidas de seguridad [RMS, en breve] de los ficheros automatizados que contengan datos de carácter personal de la LORTAD (3), que reza:

[...] 4. Cuando los ficheros contengan un conjunto de datos de carácter personal suficientes que permitan obtener una evaluación de la personalidad del individuo deberán garantizar las medidas de nivel medio establecidas en los artículos 17, 18, 19 y 20”.

RMS que la vigente Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal mantiene en vigor (4), en virtud de su Disposición transitoria tercera.

Y yo me pregunto ¿qué es “un conjunto de datos de carácter personal suficientes que permitan obtener una evaluación de la personalidad del individuo“? 

Y como no me doy respuesta, me sumo unas brazas más en mi perplejidad  -¡y estiro el snorkel!-.

Quizás el legislador podría haberlo aclarado, o aclararlo, pero  -ya se sabe-  su densidad de perplejidad es inferior a la de la madera de pino oregón  (0,50 Kg./litro); o sea, que flotar le resulta chupao.

Creo firmemente que, para opinar sobre  la “evaluación de la personalidad“, habría que convocar  -y desde aquí, con mi limitado oxígeno, lo hago-  a los psicólogos, psiquiatras, psicoanalistas  -incluso lacanianos-  y evaluadores de aura  -sin pretender ofender a nadie con una lista tan heterogénea-.

Entretanto, los expertos en CRM (Gestión de Relaciones con Clientes), terminales de punto de venta, minería de datos, cookies y e-commerce van obteniendo,  archivando, actualizando y gestionando cientos de millones de “perfiles” de usuarios.

Lo del perfil tampoco me gusta mucho: ¡salgo mejor de frente!; y, además, siempre me recuerda la pareja de fotos, con las cotas de estatura al fondo, y un cartel con un número en el pecho, que la tele y el cine nos han mostrado reiteradamente. ¡Esperemos que pronto lo hagan con todos los que se lo merecen!

El perfil es una “evaluación pragmática” del comportamiento histórico de un individuo. (Suficiente para los intereses de quien lo elabora, y sin llegar, con mucho, a una “evaluación de la personalidad”).

El uso generalizado del perfil debería disminuir el spam (e-mails intrusivos)  -por aquello de aumentar la focalización (segmentación)-;  pero eso requiere lograr perfiles adecuados, si no excelentes. No es mi caso, ya que sigo recibiendo e-mails que dicen: “Manuel: Consiga, en quince días,  unos pechos más grandes y firmes”. Alternados con otros que me ofrecen un alargamiento del 25% del … snorkel. Está claro que no sólo es un problema de perfil, sino de frente. O de opción.

La empresa finesa Davisor ha publicado, no hace mucho, unos documentos interesantes sobre perfiles.

Hoy hay tecnología disponible para ocultar el perfil, pero es todavía engorrosa para el gran público. La otra alternativa es vestir de burka. Bajo la burka tod@s seríamos iguales, sin perfil  -pero se liga menos, o con menos ilusión-.

Los ASITIC (5) tienen la formación, experiencia y sensibilidad para tratar seriamente estos temas. Plantéese sentar uno a su mesa (antes de Semana Santa).

Hay también, a lo que parece, una movida que  -por intereses espurios-  defiende que cualquiera, mayor de edad, con una cierta titulación  -mínimo carné de conducir-,  puede realizar una ASITIC (haciéndose acompañar, si fuera  -a su juicio-  necesario, de un experto, bajo burka). No se fíe Ud. y, en este caso, si lo sienta a su mesa, asegúrese de no ser Ud. quien prueba el primer bocado.

 

Artículos relacionados

  1. Continuidad del Negocio y Auditoría de Sistemas (por Manolo Palao)
  2. DC y Auditoría de Sistemas (por Manolo Palao)
  3. San Agustín y la Auditoría de Sistemas (por Manolo Palao)
  4. El Burro Flautista y la Auditoría de Sistemas (por Manolo Palao)
  5. Riesgo y Auditoría de Sistemas (por Manolo Palao)
  6. Fraude y Auditoría de Sistemas (por Manolo Palao)
  7. Evidencia y Auditoría de Sistemas (por Manolo Palao)
  8. Competencia y Auditoría de Sistemas (por Manolo Palao)
  9. Independencia y Auditoría de Sistemas (por Manolo Palao)
  10. Teseo y la Auditoría de Sistemas (por Manolo Palao)
  11. Juvenal y la Auditoría de Sistemas (por Manolo Palao)
  12. Arquímedes y la Auditoría de Sistemas (por Manolo Palao)
  13. Promoviendo el Buen Gobierno Empresarial [... ¿de las TI?]

 

(1) Copyright 2002-2010, Manolo Palao, CGEIT, CISM, CISA, CobiT Foundation Certificate, Accredited CobiT Trainer.

(2) Publicado inicialmente en el invierno de 2002 a 2003 por la Asociación de Auditores y Auditoría y Control de los Sistemas y Tecnologías de la Información y las Comunicaciones (ASIA)  -hoy, Capítulo 183 de ISACA-.

(3) En la legislación española, Ley Orgánica 5/1992, de 29 de octubre, de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal que mantuvo su vigencia hasta el 14 de enero de 2000, tras su derogación por la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

(4) El autor hace referencia a la coyuntura legal existente en el año 2002. La circunstancia mencionada en el texto cambia tras la publicación del Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal, que deroga el anterior RMS.

(5) Auditoría/Auditor de Sistemas de Información y Tecnologías de la Información y las Comunicaciones.

Cualquiera que afirme que el principal objetivo de un empresa privada  -frente a la pretendida, a priori, finalidad social de las empresas públicas-  es el excesivamente simplista “¡ganar dinero!“, estará incurriendo en un grave error. Por encima de cualquier otra consideración, la principal meta de toda compañía privada es   -desde una perspectiva de Buen Gobierno Corporativo, habrá de ser-  garantizar su perdurabilidad, la permanencia y continuidad de su actividad, en el tiempo. Sólo de ese modo tendrá sentido plantearse otros objetivos. [Presumiblemente, el más importante  -pero en segundo lugar-,  el referido más arriba].

La obviedad del anterior razonamiento es evidente, por simple: la inexistencia, la desaparición, de la empresa invalidará automaticamente cualquier otra pretensión de rentabilidad y beneficio  -por ejemplo, para los que hasta ese momento hayan sido sus propietarios o accionistas-.  ¡Sencillamente, ya no aplicará!

El cortoplacismo que, en gran medida, rige, hoy, la vida corporativa  -lamentablemente, no es la única que rige-  es uno de los principales inhibidores de la continuidad de los negocios. El caso ENRON, por lo muy documentado y divulgado  -véase “ENRON. Los tipos que estafaron a América“-,  resulta uno de los más paradigmáticos. En él  -y en el propio documental-  queda ampliamente reflejada la incompatibilidad entre la meta de “ganar dinero”, planteada como meta prioritaria, y la de mantenerse en el mercado. ¡Pregúntenles, si no, a los accionistas de la compañia! Eso, por no hablar de sus empleados y, por tanto, futuros jubilados, destinatarios últimos de sus fondos de pensiones.

El tema, ampliamente discutido en los foros profesionales sobre Buen Gobierno Corporativo, se materializa en la “contaminación”  -desde la perspectiva del conflicto de intereses-  que muestran los consejos de administración, cuando en ellos participan miembros de los propios equipos directivos de las compañías. Estos consejeros ejecutivos, particularmente, cuando haya suculentas primas por resultados sobre la mesa, deberán equilibrar dos fuerzas contrapuestas: a) de un lado, su particular interés por alcanzar un rápido crecimiento, garantizándose, con ello, su gratificación personal; b) y, de otro, el de sus representados en el Consejo, esto es, la Junta de Accionistas  -y, por extensión, el de toda la propiedad-,  quienes, presumiblemente, querrán ver el beneficio mantenido en el tiempo y no sólo en un momento puntual. ¡Ni Lay, ni Skilling alcanzaron dicho equilibrio!

Al hilo de esta necesidad de garantizar una larga vida a los negocios, como premisa de otros éxitos empresariales, Manolo Palao acerca a Gobernanza de TI este nuevo Texticulillo™ en el que expone el papel que, en este asunto,  juegan las Tecnologías de la Información y las Comunicaciones.

 

Texticulillo™ nº 12: Continuidad del Negocio y Auditoría de Sistemas (1)(2)

En otro artículo de esta serie, he descrito la revolución que, para la ASITIC (3), supuso la publicación, en 1996, de CobiT, por el Instituto para la Gobernanza de los SITIC, a su vez, parte de ISACA (4).

CobiT es un instrumento para la gobernanza de los SITIC, puesto a disposición de directivos y auditores, para facilitar el buen gobierno y el control de los sistemas de que aquellos se ocupan.

La revolución que CobiT supuso fue la de plantear la gestión de la totalidad de los SITIC al servicio de la empresa (u organismo).

Y uno de los objetivos primordiales de toda empresa es la continuidad de sus operaciones; al menos, las vitales.

El enfoque hacia la Gestión de la Continuidad del Negocio ha ido evolucionando con el tiempo, adoptando en los últimos años formas más estratégicas e integradas.

Comenzó hablándose de Recuperación ante Desastres, después se habló de Reanudación de la Operativa del Negocio y, sólo posteriormente, se ha tratado la Continuidad del Negocio (5). Yo me atreví, hace unos años, a pronosticar que ese planteamiento evolucionaría hacia el de la Continuidad de la Cadena Logística.

A toda empresa le interesa sobrevivir, con costes controlados, a una alteración o interrupción de sus operaciones.

Los atentados del 11-S, y sus consecuencias, han aumentado la concienciación por estos temas. Los accidentes también acarrean, en ocasiones, graves consecuencias.

Cuando escribo estas líneas la prensa dice que “La compañía Iberia logró ayer por la mañana, tras 21 horas de caos absoluto, resolver la avería que le ha obligado a cancelar 48 vuelos y provocó retrasos en otros 970” (6).

Convencionalmente, podemos clasificar las perturbaciones a la buena marcha de la empresa como incidencias, siniestros y catástrofes.

Las incidencias son disfunciones menores  -en ocasiones usuales-  que el sistema productivo absorbe (y, a veces, corrige automáticamente). Ejemplos de ellas pueden ser las averías locales, las interrupciones breves, los errores corregibles con un esfuerzo limitado.

Los siniestros son perturbaciones mayores que pueden causar interrupciones de horas o días y conllevar costes  -de prevención, de detección y/o de corrección-  significativos.

Las catástrofes son siniestros mayores que pueden suponer una larga interrupción de las operaciones y llevar al cierre definitivo de la empresa. Según un estudio de la Universidad de Tejas (7), relativo a fábricas, “tras una catástrofe, un 43% nunca reabre, un 51% sobrevive, pero está fuera del mercado en 2 años y sólo el 6% logra sobrevivir a largo plazo“.

Incidencias, siniestros y catástrofes pueden ser directos o indirectos  -a través de los SITIC, que es lo que aquí nos concierne; o por otros servicios (el eléctrico, por ejemplo)-.  Un fuego en la fábrica sería un siniestro directo; una inundación en el centro de cálculo lo sería indirecto para la empresa entera, con la concepción de la informática al servicio de la empresa antes expuesta. Muchas empresas tienen una alta y creciente dependencia de sus SITIC, lo que desdibuja esa distinción entre directo e indirecto.

La empresa debe partir de una clasificación de sus SITIC. Una clasificación usual permite hablar de sistemas críticos  -no pueden ser reemplazados por métodos manuales; el coste de la interrupción es muy alto-,  vitales  -durante un período breve pueden ser ejecutados a mano-,  sensibles  -pueden realizarse manualmente durante períodos largos, a costes razonables-  y no críticos  -pueden interrumpirse durante plazos largos, a coste bajo-.

Un estudio de la Universidad de Minesota (8) citado por el Prof. Dr. Jorge Ramió Aguirre (9) del Departamento de Lenguajes, Proyectos y Sistemas Informáticos de la UPM indica “períodos críticos de recuperación”  -para no poner en peligro su supervivencia-  de los sistemas de información: inferiores a los siete días (con carácter general, en todos los sectores), e inferiores a los dos días (en el sector financiero).

Para los distintos sistemas  -y según su criticidad en el tiempo-  hay que tener previstas medidas, que deben estar recogidas en un Plan integrado de Continuidad del Negocio, debidamente actualizado, difundido  -Kodak, por ejemplo, lo hace por su intranet-  y probado.

Entre las medidas preventivas figuran el tener copias actualizadas de programas y datos en un almacén remoto, disponer de líneas de comunicaciones redundantes y tener probado un centro de cálculo alternativo, también, remoto. Esto último admite diversas variantes  -de distinto coste y eficacia-,  desde un acuerdo de reciprocidad de ayuda con otra empresa, a tener centros de cálculo redundantes, con una instalación más o menos básica, o con una completa.

Los ASITIC tienen formación y experiencia especializadas para ayudar a establecer dichos planes y para comprobar la idoneidad de su gestión.

CobiT contiene excelentes recomendaciones para Directivos y Auditores de SITIC en relación con la Continuidad del Negocio.

El portal Contingency Planning (10)  -lamentablemente sólo en inglés-  reúne una variedad de informaciones y servicios relacionados con la continuidad del negocio. Nadie interesado en este tema debería dejar de registrarse y estudiarlo.

En su sección dedicada a “Defensas ante Interrupciones” (del inglés, “Disruption Defenses“) (11), trata los diversos riesgos con un amigable formato de ficha técnica, con los siguientes apartados: “Causa y Efecto“; “Dónde y Cuándo“; “Medidas Mitigadoras“; “Tras el Siniestro“; “Consejo del Experto” y “Un Caso Real“.

No me resisto  -por si alguien cree que ya tiene su plan de continuidad bastante completito-  a ofrecer la lista de los riesgos cubiertos en esas fichas:

Accesos no Autorizados; Adicciones en el Puesto de Trabajo; Apagones; Ataques con Virus [biológicos]; Ataques de Denegación de Servicio; Clima Invernal; Conflictos Laborales; Crimen de Cuello Blanco; Disfunciones en Entregas; Emergencias Médicas; Espionaje; Factor Humano; Falta de Mano de Obra; Falta de Registros; Fallos de Ordenador; Fallos de Energía; Fuego; Fusiones y Adquisiciones; Piratas Informáticos; Huracanes; Instalaciones con Varias Empresas Usuarias; Interrupciones de Transporte; Inundaciones; Moral de los Empleados; Planificación de Sucesiones; Problemas Legales; Publicidad Negativa; Reubicación del Negocio; Riesgos Biológicos; Riesgos Medioambientales; Síndrome del Edificio Enfermo; Temas relacionados con la Plantilla; Terremotos; Tormentas Invernales; Tormentas de Nieve; Tormentas Eléctricas; Tornados; Tumultos; Violencia en el Puesto de Trabajo; Virus de Ordenador.

 

Artículos relacionados

  1. DC y Auditoría de Sistemas (por Manolo Palao)
  2. San Agustín y la Auditoría de Sistemas (por Manolo Palao)
  3. El Burro Flautista y la Auditoría de Sistemas (por Manolo Palao)
  4. Riesgo y Auditoría de Sistemas (por Manolo Palao)
  5. Fraude y Auditoría de Sistemas (por Manolo Palao)
  6. Evidencia y Auditoría de Sistemas (por Manolo Palao)
  7. Competencia y Auditoría de Sistemas (por Manolo Palao)
  8. Independencia y Auditoría de Sistemas (por Manolo Palao)
  9. Teseo y la Auditoría de Sistemas (por Manolo Palao)
  10. Juvenal y la Auditoría de Sistemas (por Manolo Palao)
  11. Arquímedes y la Auditoría de Sistemas (por Manolo Palao)
  12. Promoviendo el Buen Gobierno Empresarial [... ¿de las TI?]

 

(1) Copyright 2002-2010, Manolo Palao, CGEIT, CISM, CISA, CobiT Foundation Certificate, Accredited CobiT Trainer.

(2) Publicado inicialmente en el invierno de 2002 a 2003 por la Asociación de Auditores y Auditoría y Control de los Sistemas y Tecnologías de la Información y las Comunicaciones (ASIA)  -hoy, Capítulo 183 de ISACA-.

(3) Auditoría/Auditor de Sistemas de Información y Tecnologías de la Información y las Comunicaciones.

(4) Antigua Asociación para el Control y la Auditoría de los Sistemas de Información (del inglés, Information Systems Audit and Control Association) con una audiencia objetivo que se extiende, en la actualidad, a todo profesional con intereses en torno a  las Tecnologías de la Información.

(5) El término de moda, hoy, es, sin duda, ‘resilience‘ -la ‘resiliencia‘ como, con toda probabilidad, diría Palao-,  la elasticidad de que deberían estar dotadas las organizaciones a fin de ser capaces de resistir ante adversidades importantes que afecten a sus sistemas de información y de recuperar su “forma” original, su operativa previa al impacto. Piense en el comportamiento de los modernos edificios japoneses tras recibir el envite de un terremoto.

(6) Fuente: Diario “El País“. Verónica Martín/Carlos E. Cué. Madrid, 9 de noviembre de 2002. URL: http://www.elpais.com/articulo/espana/Iberia/repara/averia/despues/21/horas/caos/48/vuelos/cancelados/elpepiesp/20021109elpepinac_4/Tes.

(7) El tiempo transcurrido desde la publicación inicial de este Texticulillo™ ha hecho imposible recuperar la referencia original. No obstante, documentos posteriores, más recientes, apuntan al Emergency Management Forum americano como fuente de la cita.

 (8) Como en (7), la referencia al documento original se ha perdido.

(9) Véase (8).

(10) El autor hace referencia, en este punto, al antiguo portal de Internet “Contingency Planning” localizado a finales de 2002 en la URL http://www.contingencyplanning.com. Hoy día, la misma remite a la dirección-e http://contingencyplanning.com que alberga la sede web de la conferencia y exposición “Contingency Planning & Management“.

(11) Véase (10).

Gobernanza de TI les acerca esta nueva prueba de la fecundidad literaria de Manolo Palao, en la que  -en el habitual formato de sus  “Texticulillos™“-  el autor vuelve a hacer gala de una aguda ironía al exponer sus reflexiones sobre ciertos aspectos del Control Interno; específicamente, sobre determinados mecanismos de control dirigidos, de forma inequívoca, a salvaguardar  -de su corrupción, o uso indebido-  la información y sus sistemas y tecnologías asociados.

Concluirá recordando cómo un uso descuidado  -negligente-  de tales artilugios de control será garantía, más que suficiente, de su fulminante pérdida de eficacia.

 

Texticulillo™ nº 11: DC y Auditoría de Sistemas (1)(2)

DC, para cualquier globalizado o globalizable  -o sea, la mayoría-,  es el apellido de Washington. No George Washington, sino Washington, DC.

DC, District of Columbia, es el único distrito federal de los EEUU. Aprobado por el Artículo 1 de su Constitución de 1787, éste autorizaba a constituir un reducido espacio federal para la capitalidad del estado. El 1 de diciembre de 1800 la capital se movió de Filadelfia, a su actual y maravilloso enclave, a orillas del Potomac.

Sin perjuicio de todo lo que “DC” ha dicho, y haya de decir, acerca de la ASITIC (3), lo que hasta ahora, histórica y prácticamente, importa es lo que viene diciendo ISACA (4)  -internacionalmente, la más reputada  entidad normalizadora en este campo-  desde su sede en Rolling Meadows, Illinois.

Pero el motivo de estas líneas es otro DC  -u otros , como se verá-.

Entre nosotros, DC significa, más generalmente, “dígito de control”.

Los  “caracteres de control”  -uno o varios; dígitos o no-  se suelen añadir, en posición predeterminada, a números o textos, que aquí llamaremos “códigos”, para comprobar que no ha habido error en su transcripción, transmisión o tratamiento. Suelen ser breves y fijos, en número de caracteres (5). Se computan con un algoritmo barato, pues su cálculo va a ser frecuente. Una vez que se tiene un código ampliado con sus caracteres de control, para validar el código se vuelven a calcular los caracteres de control que le corresponden y se comparan con los que llevaba el código ampliado. Si hay coincidencia, se entiende que el código no ha sido alterado. El algoritmo empleado debe satisfacer diversas características para impedir, o dificultar, que un código que sí ha sido alterado arroje los mismos caracteres de control que el original. Hay diversos algoritmos muy adecuados, entre ellos los que se usan para la “firma digital”.

Los ASITIC creemos que los DC son una técnica excelente y recomendable para validar datos de entrada en un sistema de información. Esto es particularmente importante cuando esos datos, como el DNI (6), pretenden ser datos clave  -identificadores únicos-  en una base de datos.

La redundancia  -los dígitos añadidos-  supone un coste extra en transcripción, tratamiento, transmisión y almacenamiento; pero está justificada por las ventajas que aporta.

Un número dígito es, en la numeración decimal, cualquiera de los caracteres comprendidos desde el ‘0’ al ‘9’, como confirma el Diccionario de la RAE. Ello prueba el encomiable trabajo de revisión de los académicos. La edición del Diccionario que yo tengo en mi estantería es del siglo pasado  -¡1970!-  y dice que número dígito es “el que puede expresarse con un solo guarismo; en la numeración decimal lo son los comprendidos desde el uno al nueve, ambos inclusive”, escamoteando así, no sólo un 10% de los dígitos, sino el esencial para una aritmética posicional.

[Aprovecho para prevenir al lector, que estuviera tentado, de que se limite a entrar en el diccionario por "número", porque si se le ocurriese hacerlo por "dígito" se encontraría con la académica definición: “Cada una de las doce partes iguales en que se divide el diámetro aparente del Sol y el de la Luna en los cómputos de los eclipses.” ...

… No es seguro, pero sí muy probable, que defender en público semejante definición de "dígito" pudiera acarrear a tal defensor tener que cambiar su modelo preferido de camisa por una con correas y las mangas atadas.]

Todo el que tenga y use una cuenta corriente bancaria, y ordene o reciba transferencias de otras, sabe probablemente que los dígitos  -de izquierda a derecha-  9º y 10º del “número de cuenta”  -o, más modernamente, los 13º y 14º del IBAN, el identificador internacional bancario-  son los dos DCs (aunque se les llama “el DC”).

Quienquiera que dé los datos de su DNI/CIF (7),  probablemente sabe que el último/primer carácter  -de nuevo, de izquierda a derecha, como buenos cristianos-  es el de control: una letra.

Lástima que, en el caso del DNI, esa fácil identificación única la haya desvirtuado la propia Administración al reasignar números de DNI a otras personas.

¿Es que no sabemos, o que no queremos? Porque los tratamientos son distintos.

 

Artículos relacionados

  1. San Agustín y la Auditoría de Sistemas (por Manolo Palao)
  2. El Burro Flautista y la Auditoría de Sistemas (por Manolo Palao)
  3. Riesgo y Auditoría de Sistemas (por Manolo Palao)
  4. Fraude y Auditoría de Sistemas (por Manolo Palao)
  5. Evidencia y Auditoría de Sistemas (por Manolo Palao)
  6. Competencia y Auditoría de Sistemas (por Manolo Palao)
  7. Independencia y Auditoría de Sistemas (por Manolo Palao)
  8. Teseo y la Auditoría de Sistemas (por Manolo Palao)
  9. Juvenal y la Auditoría de Sistemas (por Manolo Palao)
  10. Arquímedes y la Auditoría de Sistemas (por Manolo Palao)
  11. Confianza en, y valor de, los sistemas de información

 

(1) Copyright 2002-2010, Manolo Palao, CGEIT, CISM, CISA, CobiT Foundation Certificate, Accredited CobiT Trainer.

(2) Publicado inicialmente en el invierno de 2002 a 2003 por la Asociación de Auditores y Auditoría y Control de los Sistemas y Tecnologías de la Información y las Comunicaciones (ASIA)  -hoy, Capítulo 183 de ISACA-.

(3) Auditoría de Sistemas de Información y Tecnologías de la Información y las Comunicaciones.

(4) Antigua Asociación para el Control y la Auditoría de los Sistemas de Información (del inglés, Information Systems Audit and Control Association) con una audiencia objetivo que se extiende, en la actualidad, a todo profesional con intereses en torno a  las Tecnologías de la Información.

(5) Constituyen un hash (literalmente, triturado/picado, como la carne picada). En Informática, código resumen, resultado de la aplicación de una función homónima sobre un dato  -“código” en palabras del autor-  (documento, registro, archivo, …) original.

(6) En España, Documento Nacional de Identidad de las personas físicas, en referencia a su código de identificación  -el número de DNI-  que acaba con un carácter alfabético (una letra).

(7) En España, Código de Identificación Fiscal de las personas jurídicas, en referencia a su código de identificación  -el número de CIF-  que comienza con un carácter alfabético (una letra).

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 68 seguidores