¿La crisis 'obliga' al personal de TI a reinventarse?

Hace relativamente poco tiempo, leí este artículo que me llamó, especialmente, la atención por su título:

"La Crisis 'obliga' al personal de TI a reinventarse" (noticia publicada el pasado 10/03/2009 en http://www.idg.es/computerworld/noticia.asp?id=77363)

En él se exponían los siguientes puntos principales, cito textualmente:

(...) No hay duda de que las perspectivas del empleo dentro de la industria de TI son cada vez más negras. Las compañías están externalizando sus departamentos de TI, renovando sus plantillas y sustituyendo a veteranos del sector por mano de obra barata en un intento desesperado por reducir costes.

(...) Más que vaticinar el fin de la carrera del profesional especializado en TI, los analistas consideran que éste debe reinventarse, cambiar sus habilidades y combinar su conocimiento de la tecnología con su conocimiento sobre el negocio con el objetivo de poder salvaguardar su puesto del offshoring.

Dos reflexiones a lo que se expone en el artículo:

• Premisa 1: la reinvención, la innovación en definitiva, es una cualidad del cambio, así como el talento para desarrollarla es una característica intrínsecamente humana.

Está claro que en épocas de crisis o en circunstancias adversas se agudiza el ingenio y por tanto, se es especialmente proclive a los que llamamos vulgarmente "estrujarse los sesos", pero la capacidad humana de reinventarse, de innovar es una característica que forma parte de nuestro género "Homo" desde los albores de la humanidad.

Dice E. Punset en su blog (http://www.eduardpunset.es/blog/?p=175) que la capacidad metafórica es el primer requisito del talento y que la especie humana lo desarrolló hace unos cincuenta mil años, y que "sin el ejercicio del poder metafórico o multidisciplinar no hay talento que valga".

(...) Durante mucho tiempo se creyó que el talento era el fruto de una reflexión. Nunca se habían analizado científicamente los mecanismos intuitivos. La intuición no se consideraba siquiera conocimiento. No te podías fiar de la intuición. Más tarde, el análisis científico demostró que gran parte de la historia de la evolución transcurrió a golpe de intuición.

(...) En los últimos años, la ciencia ha ido más lejos y ha llegado a la conclusión de que, en determinados casos, es mucho más segura la intuición que la razón. ¿Cuándo? Cuando no se dispone de toda la información necesaria (...).

Por tanto, y aunque lo favorezca, no hace falta necesariamente que haya crisis para reinventarse, sólo que haya cambio, y el cambio es recursivo. Estamos en continuo cambio. Ya lo dijo Heráclito: "todo fluye, nada permanece".

Cuando en el ámbito de los negocios el entorno es cambiante, los parámetros de competencia varían, la tecnología evoluciona ofreciendo nuevas posibilidades, surge la incertidumbre...y la intuición...que nos lleva a la innovación...que nos lleva al cambio...que nos lleva, en definitiva, a reorientar o modificar de forma estratégica, los procesos de negocio para garantizar mejor su adaptación.

• Premisa 2: sin conocimiento no hay éxito

La aparición de la economía basada en el conocimiento supone que la capacidad de una empresa de crear valor ya no depende exclusivamente de su capacidad financiera y de producción. Se viene constatando desde hace algunos años que la información y el conocimiento son una fuente primordial para la creación de renta y de riqueza.

(...) La Gestión del Conocimiento surge en el nuevo escenario económico como la nueva visión con la que plantear la búsqueda de soluciones que contribuyan a modificar, adaptar o ajustar el entorno empresarial a la nueva realidad, cuyo principal y más claro atributo es la incertidumbre.

M. Fernández de Pinedo, "La Gestión del Conocimiento en el nuevo paradigma")

Nuevamente, ante un entorno de incertidumbre -que viene de la mano del cambio- el conocimiento se convierte en un factor fundamental para la adecuada gestión de la información que tratan los procesos de negocio.

El "know-how" no puede medirse, ni valorarse exclusivamente en términos de coste -barato frente a caro-. El conocimiento es capacitación, es saber identificar, evaluar, intuir, interpretar, medir, es en definitiva, valor añadido. Valor que aporta madurez a estos procesos de negocio y que predispone su adaptación al cambio, a la innovación.

Por este motivo, la reducción de los costes no debería buscarse en este sentido, sino que debería orientarse hacia una mayor optimización en el uso de los recursos, una mejora de la calidad de los procesos que generan productos finales y/o servicios con resultados más competitivos, o bien hacia la potenciación de los propios recursos humanos de TI (lo que se conoce como "empowerment") que permita precisamente, obtener ese valor añadido y esa efectividad resultado de su conocimiento y experiencia.

Por tanto, y bajo este prisma, la tendencia de abaratar costes en el contexto de las TI sustituyendo a "veteranos del sector por mano de obra barata" me parece, sin duda, un error.

En palabras de J. M. Viedma ("La Gestión del Conocimiento y del Capital Intelectual", 2001):

Tanto la gestión del capital intelectual como la gestión del conocimiento son de hecho la piedra angular del paradigma de empresa excelente o empresa triunfadora del siglo XXI.

Un dato significativo procedente de la presentación de resultados del informe 2009 de la Fundación para la Innovación Tecnológica -Fundación Cotec-:

Se confirma un descenso sobre la evolución y la capacidad del sistema español de innovación, rompiendo con la trayectoria de un crecimiento superior al 10% en los últimos años y pasando a unos niveles que no se apreciaban desde 2002.

¿Debemos atribuirlo únicamente a un problema de la crisis?

Estándares Metodológicos para la Gestión de los Sistemas de Información.

En la actualidad la variedad de metodologías (llamémosle así de forma genérica al conjunto de estándares, metodologías, o buenas prácticas) presentes en el mercado relacionadas con la gestión de los departamentos de TI es muy amplia, y parece que el futuro no va en la línea con la “consolidación” como pasa en el mercado de las empresas de TI, sino todo lo contrario, con nueva metodologías apareciendo en la cartelera mensualmente…..Lean Service Management, USMBOK (Universal Service Management Body of Knowlegde, www.usmbok.org), ISO 38500, CMMi Services, Six Sigma aplicado a TIC, y un largo etcétera.
De todas formas hay algunos de estos estándares que se han consolidado en el mercado, o que suenan en mayor medida, sobre todo los que ya llevan unos años de trayectoria. Entre estos, ITIL, en sus versiones 2 y 3 (14 millones de entradas en google), el estándar ISO 20000 (4,6 millones de entradas), nacido a raíz de ITIL, la ISO 27001 relacionada con la seguridad de la información (1,7 millones de entradas), CMMi en su totalidad (Development- Services-Adquisition) (2,1 millones de entradas), y Cobit (0,8 millones de entradas) como marco de gestión más enfocado a alinear los objetivos del negocio con las tareas de los departamentos de TI.
De todo este aglomerado de estándares cada organización debe ser capaz de entenderlos todos, saber qué puntos tienen en común y qué elementos define mejor cada uno, y a la vez saber utilizar aquellas herramientas que nos presentan individualmente los distintos enfoques.
Por ejemplo, ISO 20000 es, a nuestro modo de ver, un buen punto de partida para iniciarse en este camino, aunque no se persiga el fin último de una certificación. Este estándar define unos mínimos que toda organización debe cumplir (los “debes” de la norma, en su parte 1) para tener un sistema de gestión de servicios TI (SGSTI). Apoyando a esta norma certificable, podemos utilizar su parte 2 (ISO/IEC 20.000-2), como referencia para la mejora de este sistema de gestión (los “debería” de la norma).
En paralelo, no podemos desviar la vista de ITIL, en su versión 2, ya que contiene casi los mismos procesos que la norma certificable, aportando un conocimiento más profundo en cuanto a las interrelaciones entre los distintos procesos y una visión más detallada de los roles implicados y sus responsabilidades.
La última versión de ITIL, la 3ª de estas mejores prácticas, aporta una mayor profundidad en cuanto al ciclo de vida de los servicios, y se realiza una revisión de antiguos conceptos, actualizándolos y proponiendo algunas nuevas soluciones a dificultades encontradas en la versión anterior. De todas formas, la versión 3 en todo su conjunto, abarca un ámbito tan grande de procesos y funciones que no parece recomendable empezar con esta versión de esta metodología a no ser que hablemos de organizaciones ya muy maduras en la gestión por procesos y con un cierto tamaño, que nos permita dedicarle un esfuerzo considerable.
No olvidemos, de entre todas las metodologías, aquellas orientadas a asegurar la seguridad de la información, como requisito indispensable dentro de una organización que gestiona datos y por tanto debe asegurar su confidencialidad, integridad y disponibilidad. En este sentido la norma ISO 27001 (Sistema de Gestión de la Seguridad de la Información (SGSI)) sería la norma certificable, junto con toda la familia de la serie 27000, y por tanto el punto de referencia.
Como complemento a todas las anteriores, nunca deberíamos descuidarnos tener en cuenta Cobit (Cobit 4.1), sea cual sea el ámbito que nos interese (dentro de TI). Ya que nos aporta un visión complementaria a todos los procesos de ISO 20.000 e ITIL, y nos aporta mucha más información en relación a indicadores y como mapearlos a nuestros objetivos de negocio. Sin olvidar las propuestas de matrices RACI o los niveles de madurez propuestos para cada proceso.
En definitiva, para confeccionar un sistema de gestión de los sistemas de información, hay unos pasos que ninguna organización debería saltarse. En primer lugar, conocer las distintas metodologías, y posteriormente definir cuál es el objetivo que quiere conseguir la organización. Seguidamente, evaluar el estado de madurez de la organización respecto al objetivo marcado. En tercer lugar, llevar a cabo un proyecto (apoyado por la Dirección) para conseguir pasar del estado actual al deseado. Este paso puede realizarse internamente, o con ayuda externa, pero siempre debe quedar claro el objetivo, y se deben definir los indicadores que nos permitirán saber cuando hemos llegado al objetivo final.
Para finalizar y siguiendo el hilo del inicio de este artículo, comentar que 11 empresas en España (según distintas fuentes) ya han conseguido la certificación ISO 20.000, y nos consta que un número mucho mayor están en camino de implementar un modelo basado en dicha norma, lo que nos reafirma en nuestra opinión: La ISO 20.000 es un buen punto de partida hacia la mejora para las organizaciones que gestionan las TIC.

Artículo publicado en www.computing.es

http://www.computing.es/Informes/200905130005/Estandares-Metodologicos-para-la-Gestion-de-los-Sistemas-de-Informacion.aspx

Pongamos que hablamos de herramientas de análisis de riesgos en IT

A menudo, tenemos tendencia a creer que las herramientas nos van a proporcionar todas las respuestas que necesitamos con sólo apretar un botón (en el mejor de los casos). Toda la subjetividad que conlleva un clásico análisis de campo (descriptivo, empírico), basado en entrevistas, cuestionarios y observaciones varias, aunque, no por ello, ausente de metodología, parece condicionar su validez frente a un análisis basado en el uso de una herramienta generalmente específica y dedicada. El proceso analítico en que se basa la herramienta suele considerarse mucho más objetivo y, desde luego, mucho más racional en comparación con el anterior. De hecho, no podemos olvidar que las herramientas de análisis en general permiten obtener modelos conceptuales que, a su vez, permiten interpretar datos, predecir implicaciones y, por tanto, tomar decisiones; pero, frecuentemente, en esa creencia se pasa por alto un detalle fundamental, y es que ninguna herramienta o aplicación informática puede sustituir el conocimiento deductivo y la propia experiencia de quien realiza el análisis. Sobre todo, si se tiene en cuenta que, en muchos casos, la herramienta se basa o permite elegir opciones de tipo cualitativo donde es el propio usuario quien valora subjetivamente las variables en las que se fundamentarán los cálculos internos (por ejemplo, una valoración de frecuencia, probabilidad o degradación); cálculos que, por otro lado, son también discutibles.

De lo expuesto hasta el momento no debe deducirse necesariamente que esté en contra del uso de estas herramientas en el proceso de análisis; todo lo contrario, se trata simplemente que no comparto (o no entiendo) el uso indiscriminado que, en muchas ocasiones, se hace de ellas cuando, no disponiendo de conocimiento suficiente de la situación actual de la Compañía, se pretende, cual Oráculo, buscar respuestas a preguntas que no han sabido formularse primero. En estos casos, las respuestas perseguidas se contextualizan en un supuesto análisis numérico que, amparado en sus mecanismos de cálculo, esconde una carencia de conocimiento, de metodología, de objetivos y, en definitiva, de definición, que se hace patente, especialmente, en aquellos casos en los que no se precisa ninguna herramienta para valorar unas variables que son obvias, muchas veces, "a flor de piel". Si, además, se toman en cuenta los costes, la obtención de una valoración numérica final, no siempre compensan el tiempo invertido en la entrada y posterior mantenimiento-actualización de los datos y la dedicación que requiere el proceso relacional y de análisis.

Puesto que los procesos de negocio están soportados por servicios de TI, quizá deberíamos conocerlos primero un poco mejor.

La paradójica existencia de las "guerrillas" IT

Se ha escrito muchísimo sobre el llamado "Sun-Tzu" o "Arte de la Guerra" como un clásico de estrategia militar de actual aplicabilidad al mundo de los negocios y de la estrategia empresarial (véase por ejemplo "El Arte de la Guerra para Directivos" de Gerald Michaelson). Un aspecto muy recurrente de los muchos que se tratan en todas estas publicaciones, es la comparación del enemigo con la competencia directa externa, pero curiosamente, la mayoría de las veces, no hay que irse tan lejos para observar que los "mini campos de batalla" se suceden día tras otro, en nuestro entorno más cotidiano dentro de la propia compañía e incluso dentro de la propia área.

A lo largo de mi experiencia, he tenido la oportunidad de llevar a cabo proyectos para diferentes organizaciones, el desarrollo de los cuales, ha acontecido en el "campo de batalla" de sus áreas IT, eso sí, bajo un aparente clima de calma. Lo paradójico de esta situación y como sucede en todas las guerras, es que nunca produce vencedores, sino únicamente estancamiento y pérdida por igual.

Mi posición de observadora accidental en esta particular guerra IT encubierta, me ha permitido reflexionar sobre esta cuestión y sobre los posibles motivos que la fomentan, llegando a la conclusión que, salvando la predisposición tan humana al conflicto, son principalmente consecuencia de:

• Una carencia clara de estrategia, o bien de alineación entre la estrategia tecnológica y la corporativa de negocio de la organización, cuya primera implicación es la divergencia de directrices, objetivos y prioridades. Esto se traduce en la máxima: "a falta de criterio, el mío es el que vale".

• La consolidación del efecto "Reino de Taifas", cuyas características más destacadas son a mi modo de ver, por un lado, el establecimiento de "facciones" de poder que implican el posicionamiento de los integrantes de rango y por otro lado, una acentuada problemática de comunicación y coordinación entre "reinos" que impacta en el desarrollo normal de las actividades del área IT y por tanto, en el negocio.
  

• La inexistencia de la práctica del análisis de carácter iterativo (mejora continua) y en consecuencia, la resistencia como respuesta a la crítica y la oposición al cambio: "crítica vs fiscalización".

• Las propias aptitudes de liderazgo de sus componentes.

En resumen, estamos hablando de estrategia, trabajo en equipo, comunicación, metodología y liderazgo: ¡todo un clásico!.

Tomando como referencia el tratado de Sun-Tzu (capítulo 1) y salvando las distancias, estas problemáticas, analizadas bajo el prisma de los cinco fundamentos del arte de la estrategia, ponen de manifiesto que tanto éstas como cualquier otra proclive a la "guerra de guerrillas", no se rigen por criterios de gobierno y sin gobierno no hay victoria.

Como conclusión, y puesto que ya se ha escrito mucho sobre el tema, me quedo con esta reflexión:

Preveer una victoria que un hombre ordinario puede preveer, no es el espíritu de la excelencia. No importa si triunfas en la batalla y eres aclamado universalmente como "experto", pues levantar una hoja caída no requiere tener gran fuerza, distinguir entre el día y la noche no es prueba de gran visión, oír un trueno no es muestra de oído agudo.
(...)
Los que son expertos en la guerra cultivan sus políticas y se adhieren estrictamente a las reglas trazadas. De este modo, tienen en su poder el control de los acontecimientos.

(Sun-Tzu - El Arte de la Guerra, capítulo 4: Disposiciones)

¿Es sólo una cuestión de recomendaciones?

De un tiempo a esta parte, es muy frecuente oír hablar del auge que han tomado las redes sociales en internet. Quién más y quién menos forma parte de una de ellas, quizá dos o más. Se empieza recibiendo una invitación de un amigo, luego viene otra y otra hasta que, o bien las aceptas todas, o bien decides que ya es suficiente con las que tienes.

Darse de alta nos parece un puro trámite. Se presupone que leemos atentamente y aceptamos las cláusulas de confidencialidad o de privacidad, pero me atrevería a decir que en un 95% de los casos (no nos olvidemos de que siempre hay excepciones), no lo hacemos. El texto acostumbra a ser largo, pesado y aburrido: "total para estar en contacto con amigos y colgar unas cuantas fotos..."-solemos auto convencernos-. Ni siquiera pensaríamos en la privacidad y tratamiento que se realiza de nuestros datos personales, que voluntariamente consentimos en ceder, si no fuera por las noticias que últimamente están apareciendo en los medios de comunicación sobre la seguridad de las redes sociales, conservación de los datos de forma perpetua, imposibilidad de causar baja de ellas, etc, etc.

A continuación, nos sobreviene la sorpresa, en cierto modo, seguida de alarma y finalmente, surgen las preguntas: ¿Qué significa que Facebook pretendiese reservarse el derecho de almacenar de forma perpetua nuestros datos? ¿Qué significa que la misma red se negara a dar tratamiento a una solicitud de baja por fallecimiento? ¿Realmente mi consentimiento es tan universal? ¿Y todos aquellos derechos que se supone observa nuestra Ley de Protección de Datos (LOPD)? ¿Es sólo una cuestión de recomendaciones?...

Como punto de partida tenemos dos realidades:

Por un lado, existe una normativa europea de protección de datos (Convención nº108 del Consejo de Europa para la protección de las personas con respecto al tratamiento automatizado de datos de carácter personal), que

Comete a su jurisdicción a toda entidad instalada en la UE o que utilice medios establecidos en la UE para prestar sus servicios (A. Rallo, Director de la AEPD Entrevista digital 25 de noviembre 2008 El Pais.com)

Por tanto, en España se garantiza la aplicabilidad de la Ley de Protección de Datos (LOPD) sea cual sea el origen de la plataforma de internet que los contenga.

(...) cuando se producen infracciones en España que afectan a Google, Youtube u otros servicios de internet transnacionales, se les aplica la ley española (véase la misma cita)

Por otro lado, el usuario es responsable de su participación voluntaria en dichas redes, así como de publicar contenido de información personal en ellas. Otra cosa muy diferente es que realmente sea consciente de ello y del posible impacto que pueda tener para su privacidad.

Entonces, entiendo y estoy de acuerdo con las recomendaciones de la Agencia Española de Protección de Datos relativas a publicar únicamente la justa medida de información de carácter personal e informarse convenientemente de las condiciones de privacidad y cláusulas antes de pasar a formar parte de ellas. Así como de su desempeño en advertir a los usuarios confiados de los posibles riesgos que entraña.

Ahora bien, no entiendo y no comparto, que sólo trate como "recomendación" a las empresas que sustentan estas redes sociales y/o profesionales,

la mejora de sus técnicas de garantía de la privacidad (A. Rallo, Director de la AEPD Entrevista digital 25 de noviembre 2008 El pais.com)

Aunque formar parte de ellas sea un acto voluntario, la privacidad o mejor dicho, el respeto a la vida privada es un derecho fundamental amparado por la Constitución Española y Europea, que además se encuentra también protegido tanto por la Ley Orgánica 15/1999 de 13 de diciembre (Título 1, Artículo 1), como por la misma Convención nº108 del Consejo de Europa (Capítulo 1, Artículo 1).

Especialmente por este motivo, no puedo entender tampoco que las acciones que han contribuido a detener la puesta en marcha de decisiones tan abusivas como las comentadas anteriormente, que contravienen las actuales disposiciones legales y atentan contra los principios de la privacidad defendidos por ambos textos, procedan, tal y como se puede leer en la prensa, del "revuelo causado en toda la comunidad de usuarios" o de la "hermana del fallecido periodista William Bemister", por mencionar los últimos casos, y no, como a mi entender correspondería, de los organismos competentes.

¿Aberración o sublimación de la lógica?

Tengo que confesar que cada vez que veo estos ejemplos de exámenes de matemáticas que circulan por internet, me rio muchísimo.

Seguramente, los sufridos profesores que día a día luchan sin descanso para transformar tanto despropósito en algo de conocimiento, no estarán en nada de acuerdo y quizá hasta les parezca inmoral, pero no por ello, se puede negar que la conciencia de la realidad, es decir, la percepción de la misma, siempre depende del punto de vista de quien la observa, la evalúa y en última instancia, la interpreta.

Sin llegar a este extremo, he de reconocer que tuve una experiencia similar en mis años de colegio cuando un buen día, decidí aplicar una propiedad matemática a un problema de lógica de conjuntos y lo bueno es que me pareció entonces ¡brillante! A nadie se le había ocurrido. El resultado fue obvio: "¡suspendida, claro!". Mi hermano, que todavía se ríe, me otorgó el merecido calificativo de "alogos" y se preguntó qué mecanismo de mi mente pudo construir semejante tontería -pero si fue precisamente eso: ¡la lógica!-.

Viendo estos ejemplos, ¿Podemos considerarlos entonces carentes de lógica? ¿De sentido común? Pues depende. Como siempre y como en otros casos, depende del contexto. En un contexto enmarcado en el conocimiento y en la razon, estos ejemplos son desde luego aberrantes y atentan contra los fundamentos de lo que somos. Fuera de éste, constituyen llamémosle "respuestas simples a realidades obvias".

Nosotros, que en el mundo de las TIC no concebimos otro contexto que no sea el del conocimiento: observación, análisis, evaluación, estructuración de la información, definición de procesos y procedimientos, etc. etc., damos por sentado que todo el mundo comparte y entiende nuestro discurso, por otra parte lógico y de sentido común, pero ¿Cómo perciben la realidad nuestros clientes? ¿Entienden de siglas? ¿Saben de procesos? ¿Qué es obvio para ellos?...

En el ámbito de la Lengua, se considera hablante culto aquel que sabe cambiar de registro en función del contexto y la situación. Utilizando este símil, me pregunto entonces si a menudo sabemos mudar de uno a otro con la habilidad necesaria como para entender cuáles son las realidades (y lógicas) de todos ellos, sus necesidades y sus requerimientos.

Cuando empiezo un nuevo proyecto con un nuevo cliente, no puedo evitar pensar siempre: ¿Y tú de quién eres?.

El huevo (procesos) o la gallina (herramienta)

No es trabajo trivial tomar una decisión sobre si se debe primero definir los procesos de gestión de TI, y después realizar una selección entre las herramientas del mercado para implementar dichos procesos. O, por otro lado, si se debe seleccionar una herramienta y después implantar los procesos según nos permita la herramienta.
He visto casos de todos los colores, desde implementaciones de herramientas, con la implementación “estándar” de procesos. Ese caso, tampoco era tan descabellado. Era una organización muy grande, e iniciar un proceso de colaboración con todos los implicados para definir los procesos supongo que se previó costoso y problemático, así que la decisión fue implantar (comprar) una herramienta y unos procesos estándares……. El problema es que ese departamento de TI no puede diferenciarse del resto de departamentos de TI de cualquier otra empresa que utilice la misma herramienta y los mismos procesos…… (Se instala igual en “Brother Soons inc.” que en “Jamones Lucas”).
Tengo que decir que durante las primeras etapas a NADIE de esa organización le pareció que la herramienta se adaptase a su forma de trabajo….

El caso contrario ha sido, a mi forma de ver, un gran acierto…. Partiendo de unos procesos definidos, pensados y trabajados internamente; y utilizando SW libre, se ha llegado a crear una herramienta de gestión muy adecuada, facilitando así que este departamento de TI sí pueda distinguirse del resto de departamentos de TI y por tanto poder actuar de forma libre para alinearse con los objetivos del negocio y colaborar en el éxito de la empresa.
I al contrario de caso anterior, la herramienta se adapta como un guante a las necesidades de la empresa….

Bien, entre uno y otro extremo, hay variedad de opciones…. , todas válidas, y todas con contrapartidas. Pero yo creo, sin duda, que la mejor opción es la de definir primero como quiero que salga el huevo (procesos) y después escoger la gallina que lo ha de poner (herramienta).

De cómo la valoración del riesgo no debería ser fruto de la percepción

Hace un par de días me llegó uno de esos correos divertidos que los amigos suelen enviar para compartir una sonrisa. Mientras lo leía (y sonreía) no pude evitar pensar en que se trataba de un ejemplo claro de "voluntad de continuidad sin gestión del riesgo". Decía así:

Los indios de una remota reserva preguntaron a su nuevo jefe si el próximo invierno iba a ser frío o apacible. Dado que el jefe había sido educado en una sociedad moderna, no conocía los viejos trucos indios. Así que, cuando miró el cielo, se vio incapaz de adivinar qué iba a suceder con el tiempo...De cualquier manera, para no parecer dubitativo, respondió que el invierno iba a ser verdaderamente frío, y que los miembros de la tribu debían recoger leña para estar preparados. No obstante, como también era un dirigente práctico, a los pocos días tuvo la idea de telefonear al Servicio Nacional de Meteorología.
-¿El próximo invierno será muy frío?- preguntó.
-Sí, parece que el próximo invierno será bastante frío- respondió el meteorólogo de guardia.
De modo que el jefe volvió con su gente y les dijo que se pusieran a juntar todavía más leña para estar aún más preparados.
Una semana después, el jefe llamó otra vez al Servicio Nacional de Meteorología y preguntó:
-¿Será un invierno muy frío?
-Sí- respondió el meteorólogo -va a ser un invierno muy frío.
Honestamente preocupado por su gente, el jefe volvió al campamento y ordenó a sus hermanos que recogiesen toda la leña posible, ya que parecía que el invierno iba a ser verdaderamente crudo.
Dos semanas más tarde, el jefe llamó nuevamente al Servicio Nacional de Meteorología:
-¿Están ustedes absolutamente seguros de que el próximo invierno será muy frío?
-Absolutamente, sin duda alguna- respondió el meteorólogo -va a ser uno de los inviernos más fríos que se hayan conocido.
-Y ¿Cómo pueden estar ustedes tan seguros?
-¡Vaya, porque los indios están recogiendo leña como locos!

Tomando como referencia la entrada publicada por mi compañero Miguel A. Segura en este mismo blog, realizaremos una segunda lectura de la historia enmarcándola en la gestión del riesgo:

Tenemos por un lado, una Dirección TIC -jefe indio- que está familiarizada con algunos estándares y metodologías -había sido educado en una sociedad moderna- pero no conoce o no cuenta con los beneficios que conllevan las "best practices" -no conocía los viejos trucos indios-, así que no puede atender la petición de aseguramiento de continuidad requerida a su departamento -supervivencia-. No establece el contexto, ni identifica los riesgos, pero no quiere parecer dubitativo y da una directriz que se fundamenta en una percepción totalmente subjetiva de las necesidades -el invierno iba a ser verdaderamente frío-. Por consiguiente, no se realiza ningún análisis de impacto en el negoció (BIA). No se efectúa ninguna valoracion ni de impacto ni de costes, ni de esfuerzo, ni de eficacia -los miembros de la tribu debían recoger leña para estar preparados-. No obstante, y ante la duda, decide contar con colaboración externa para su evaluación -Servicio Nacional de Meteorología-, pero nuestra Dirección TIC no conoce con exactitud sus requerimientos, no ha definido los objetivos y tampoco ha diseñado el modelo de relación deseado (prestación de servicio, grado de implicación, métricas, etc.), así que el resultado obtenido no resuelve adecuadamente el requerimiento inicial y sigue fundamentándose en la carencia de análisis -Sí, parece que el próximo invierno será bastante frío- respondió el meteorólogo de guardia- No hay tratamiento del riesgo, en consecuencia, se incrementa el coste y el esfuerzo del departamento TIC sin que exista una necesidad probada de ello -el jefe volvió al campamento y ordenó a sus hermanos que recogiesen toda la leña posible, ya que parecía que el invierno iba a ser verdaderamente crudo-.

Moraleja de la historia:

La inexistencia y/o ineficacia de una correcta gestión del riesgo incrementará siempre los costes del departamento TIC y en consecuencia, de la Compañía, sin garantizar que el resultado obtenido cubra el objetivo deseado: la continuidad.

ITIL y la flexibilidad

La semana pasada, en una visita a un cliente, surgió uno de los reproches recurrentes hacia ITIL, con los que, de tanto en tanto, nos encontramos. Este reproche consiste en decir que ITIL resta flexibilidad a la organización de TI.

Desde mi punto de vista es imprescindible disponer de políticas, sistemas, procesos eficaces. Es imprescindible gestionar adecuadamente las actividades de TI para que, entre otras cosas, podamos dedicarnos a lo que realmente proporciona valor, podamos medir el desempeño y la consecución de los objetivos establecidos y podamos hacer un uso lo más productivo posible de los recursos de TI.

Si no disponemos de un marco de trabajo en el que movernos, es fácil que cada cosa que ocurre en el departamento de TI se convierta en una "excepción" susceptible de realizarse cada vez de forma diferente y contradictoria. Imaginemos, por ejemplo, un help desk donde cada técnico tratase las incidencias "a su manera". Y esto es perfectamente extrapolable a cualquier actividad del departamento de TI.

Si disponemos de una buena base (procesos, políticas, sistemas adecuados) podemos acometer cambios y cambios rápidos con la seguridad de que se realizan sobre una base sólida. Sin una base sólida, la búscada flexibilidad conduce al caos. Por tanto, sólo es posible ser flexible de forma inteligente si nos hemos dotado previamente de unos procesos y políticas adecuados.

El reto se encuentra en diseñar procesos eficientes (procesos bien definidos y estructurados que eviten actividades innecesarias), eficaces (definidos para alcanzar el objetivo buscado), y que huyan de la burocracia.

Gestión de riesgos en los planes de continuidad

Proceso de gestión de riesgos de seguridad de la información ISO/IEC 27005

Mucha gente trata de determinar cuáles son los factores clave que determinan el éxito o fracaso de los planes de continuidad del negocio. Existe unanimidad en que entre ellos se encuentra la correcta gestión de riesgos.

Sin embargo, es sorprendente descubrir cómo se trata de una de las fases en la que en la mayoría de los planes, menos esfuerzo se dedica. Los motivos pueden ser varios: requiere la realización de un estudio detallado y la participación de personal especializado, es necesaria la participación activa de la dirección, etc.

¿Por qué es necesario dedicar tanto esfuerzo en esta fase? La respuesta es la de siempre: se deben tratar infinidad de posibles amenazas, con un número limitado de recursos. Y es aquí donde la gestión adecuada de riesgos juega un papel fundamental, determinando qué riesgos se deben tratar de forma prioritaria para reducir al mínimo la posibilidad de sufrir en el negocio las consecuencias de daños irreparables.

Si no se realiza una correcta gestión de los riesgos, es posible que se dediquen recursos a evitar la materialización de incidentes muy poco probables, y que en cambio no se identifiquen (y por tanto no se traten) algunos con probabilidad alta de materializarse.

Ante esta situación, se ha definido la norma ISO/IEC 27005 que trata de definir un framework para la gestión de riesgos. Cada uno de los subprocesos que lo forman, que siguen el modelo PDCA (Plan-Do-Check-Act), se encuentra ampliamente detallado en la propia norma, sirviendo como una guía de referencia para la gestión de riesgos.

A continuación se resumen estos procesos, indicando ejemplos y conceptos clave para su implementación:

• Establecer el contexto: Esta actividad establece el ámbito y el alcance de la gestión de riesgos. También se crean los criterios para evaluar, decidir el impacto, y aceptar los riesgos. Además, en este paso se debe crear la estructura organizativa que debe soportar la gestión de riesgos.

1. Es aconsejable comenzar con la gestión de riesgos enfocada en los activos que sean críticos para la organización, ya que sin tener experiencia, pretender abarcar dentro del alcance toda la organización puede ser excesivo.
2. En una reunión con la dirección, se deben establecer los criterios para los riesgos, de forma que cada uno de ellos se comprometa a respetar los resultados que se obtengan.
   

• Identificar los riesgos: este proceso identifica los activos a proteger, las amenazas existentes, los controles que se han aplicado, las vulnerabilidades actuales y las consecuencias de materializarse cada una de las amenazas.

1. Mediante la realización de entrevistas con la dirección y los empleados, se realiza un inventario de activos, imputándoles un valor, siguiendo los criterios establecidos por la fase anterior.
2. Resulta práctico analizar las descripción de amenazas comunes que aparece en la misma norma, así como "brainstorming" del personal técnico.
   

• Estimación de riesgos: se describen varias metodologías para realizar una estimación del nivel de riesgo de que una amenaza se haga realidad (ya sea a nivel cuantitativo, cualitativo o una combinación de ambos).

1. Tal y como se recomienda en la norma, es conveniente comenzar por un análisis de riesgo cualitativo, y si se considera oportuno entrar en más detalle (cuantitativo) para ciertos riesgos específicos.
   

• Evaluación de riesgos: se realiza una priorización de los riesgos a tratar, dependiendo de los resultados obtenidos en los procesos anteriores. Así se establece el plan de acción.

1. Normalmente a cada riesgo se le asigna una puntuación, en función de su probabilidad y el impacto que supondría. Así se puede realizar una clasificación que servirá para establecer qué riesgos se deben tratar primero.

• Tratamiento de riesgos: se diseñan los controles a implantar para evitar o minimizar los riesgos.

1. Se deben tener en cuenta los "daños colaterales" de implantar las medidas, ya que a menudo al implantar un control se introducen nuevas vulnerabilidades en los sistemas colindantes.
   

• Comunicación de riesgos: este proceso asegura que se produzca el flujo de información necesario para que todo implicado esté al día de la evolución de la gestión de riesgos.

1. Es aconsejable la realización de reuniones periódicas entre los diferentes implicados de la gestión de riesgos.
   

• Monitorización y revisión: mantenerse al día de la evolución de las amenazas y de las medidas implantadas para reducir o evitar riesgos.
  

1. Cada vez que se implemente un control, se deben establecer indicadores que proporcionen a la organización información sobre su correcto funcionamiento para tratar los riesgos.
   
2. Como mínimo cada dos años, se recomienda realizar auditorías tecnologías para determinar el estado y la validez de los controles implantados.
   

Tal y como se puede comprobar, la norma ISO/IEC 27005 se trata de una guía de referencia bastante completa, muy aconsejable para los implicados en el diseño de los planes de continuidad. Sin embargo, como suele suceder, cada organización deberá "personalizar" estos procesos, de forma que se integren de un modo natural en la organización.

Solamente realizando una gestión de riesgos eficiente, se podrá asegurar que el plan de continuidad responde a la realidad de la organización, y únicamente enfocándolo como un modelo de mejora contínua se conseguirá mantenerlo al día.