Imagen: Adaptación de CaptechConsulting.com

• Inventario:  Parece un elemento obvio, pero no es raro que las organizaciones no tengan adecuadamente identificado las componentes de su infraestructura TI y el estado en el que se encuentra, lo cual implica realizar un levantamiento de todos los elementos constituyentes del soporte tecnológico.  El inventario debe incluir la documentación existente.

• Servicios TI:  En este nivel se debe establecer un modelo e iniciativas de optimización de los servicios tecnológicos existentes, lo cual implica entender adecuadamente su desempeño actual y las brechas de servicio que existen.

• Riesgos:  Como parte del plan se deben identificar los riesgos del soporte TI y establecer mecanismos para mitigarlos, reduciendo su impacto potencial.  Es esencial que este proceso se actualice constantemente para el monitoreo de los riesgos y su probabilidad de ocurrencia.

• Arquitectura:  La planificación debe considerar el diseño de una arquitectura objetivo.  Como complemento el plan debe establecer un camino de evolución (roadmap), el cual identifique los pasos a seguir para converger a la arquitectura tecnológica planteada como objetivo.

• Proyectos:  Desarrollo de los proyectos que permiten implementar la arquitectura tecnológica definida, estos proyectos deben estructurarse como una secuencia que direccione los esfuerzos y resultados con la arquitectura, esto es, deben estar estratégicamente alineados con ella.

Si bien parece un modelo simple y obvio, fue precisamente por eso que me gustó, ya que permite en pocos trazos establecer los elementos centrales de una estrategia TI.

El plan cuenta con metas cuantitativas y cualitativas y las principales son:

• Terminar con el menos un tercio de los proyectos tecnológicos con problemas de desempeño y resultados en los próximos 18 meses.
• Cada agencia debe identificar e implementar al menos 3 servicios en modalidad "cloud computing" en un plazo de 12 meses
• Reducir en al menos 800 dataceter del gobierno central, hoy cuentan con 2.100
• Establecer criterios más precisos para la entreaga de recursos a los proyectos, estos deben cumplir con: esquema y método claro de gestión, estrategia incremental de implementación, resultados cada 6 meses, uso de especialista de contratación  de proyectos TI
• Trabajar con el congreso en nuevos modelos presupuestarios para los proyectos TI más flexibles (estructura de externalización, multianualidad, varianza de resultados y requerimientos).
• Establecer mecanismos de colaboración e intercambio de prácticas.

Para lograr esto se va a trabajar como mencionaba en 25 iniciativas con los horizontes de tiempo planteados, las más relevantes son:

• Consolidación de servicios TI y datacenter
• Establecer un marketplace de servicios TI (convenio marco)
• Definir un política clara y precisa del uso de la modalidad cloud computing
• Estandarizar contratos para modelos IaaS y servivios TI comodities
• Desarrollar estrategia de servicios compartidos en el Estado
• Definir competencias y desarrollo profesional asociado a la gestión de proyectos tecnológicos basados en buenas prácticas (PMI)
• Eliminar los procesos de implementación en modalidad big-bang
  
• Desarrollar plataforma de colaboración e intercambio de prácticas
• Mantener y potenciar sesiones de trabajo TechStat
• Desarrollar competencias específicas en el proceso de contratación TI
• Simplificar los procesos de contratación TI bajando barreras de entrada a pequeñas compañías innovadoras
• Simplificar y modernizar el ciclo presupuestario asociado a los proyectos TI incorporando atributos que le son propios

Como vemos es un muy ambicioso plan que además debe contar en algunas de sus áreas con la venia de otros poderes del estado.  El horizonte de tiempo es corto veremos si Kundra tiene el nivel de convocatoria, empoderamiento y capacidad de ejecución (delivery) para lograrlo, pero ya es un gran logro que haya podido poner en agenda es documento de análisis y propuestas con el sello de la casa blanca en la primera hoja.  Recomiendo leerlo ya que da luces y propuesta que pueden ser replicadas en otras latitudes.
 
 Si desea bajar el plan: 25-Point-Implementation-Plan-to-Reform-Federal_IT.pdf

Actualización:

Este post del 14 de marzo del presente año se transformó para mi en el inicio de un proceso de análisis del comportamiento de la infraestructura tecnológica frente a la catástrofe, si bien antes había escrito sobre el comportamiento de los sitios web de gobierno en dicho evento.  Hoy me llegó la publicación, que incluye un paper de mi autoría respecto de este tema, El comportamiento de la infraestructura tecnológica y de comunicaciones, publicado en la revista Cuadernos de Información, Facultad de Comunicaciones, Universidad Católica de Chile.  Si les interesa puede ser descargado desde aquí - Articulo PUC Comunicaciones

____________________

Es muy común en Chile que cuando se les pregunta a los ciudadanos por la infraestructra crítica piensen en caminos, energía eléctrica, agua, servicios de salud.  Algunos incluso irían más allá  y dirán transporte y telecomunicaciones, pero muchos de ellos cuando dicen telecomunicaciones están pensando en radio, telefonía y TV.  Estoy casi seguro que las redes de datos no formarían parte de ese análisis y esto quedó demostrado en la última catástrofe, no recuerdo noticarios en diferentes medios de comunicación o declaraciones de autoridades en las cuales aparecieran otros elementos.

Cuando hablamos de infraestructura crítica, lo primero que debemos hacer es intentar una definición de, no voy a ser muy creativo y voy a tomar la definición de Eric A. Luiijf, Helen Burger y Marieke Klaver en su paper -  Critical Insfraestructure Protection in the Nehterlands: A Quick -Scan

Ellos definen infraestructura crítica a partir de servicios o productos que tienen los siguientes atributos

• realizan una contribución esencial en la sociedad a mantener un nivel mínimos definidos de (1) estado de derecho y orden público local e internacional, (2) seguridad pública, (3) economía, (4) salud y (5) medio ambiente
• o cuando su pérdida o interrupción impactan a los ciudadanos y la administración (gobierno) a escala nacional o ponen en riesgo los niveles mínimos de calidad de servicio.

Los sectores y servicios definidos por el estudio anterior son:

Dada esta definición creo que todos ustedes coincidirán que las redes de datos y en particular la red pública de datos - Internet Chilena - forma parte de ese selecto grupo de productos/servicios de carácter crítico y es así como las consideran muchos países, del grupo selecto al que nos invitaron me refiero a la OCDE.  En muchos de esos países dos eventos en el pasado, subieron de categoría a la infraestructura TIC, me refiero al efecto año 2000 a fines de los 90 y el ataque a las torres gemelas de septiembre 11 producto de que en la zona 0 de Nueva York hubo grandes colapsos de telecomunicaciones en particular de redes de datos.  En Chile a fines de los años 90 muchas organizaciones realizaron detallados planes de contingencias y de evaluación de riesgo de sus infraestructura TI (datacener, equipos de comunicaciones, software, etc.)  al parecer una parte de ese aprendizaje lo perdimos con el correr de los años, vale la pena recordar que disponibilidades de 4 9's (99,99%) son 53' de indisponibilidad y 5 9's estamos hablando de 5 minutos de indisponibilidad en el año.

Recordemos algunas métricas de Gartner y Dataquest sobre caidas de sistemas, en términos porcentuales.

Hace un par de años, y producto del  ciberataque que sufrió Estonia, se estructuraron (me tocó iniciarlas en el Ministerio de Economía como Estrategia Digital) mesas de trabajo para analizar el tema y ver cual era nuestra situación.  En ese momento se identificaron varias debilidades, recuerdo algunas de las propuestas de NIC Chile, pero esa mesa de trabajo no tuvo la fuerza ni la prioridad adecuada, de hecho Subtel tomó el tema pero no pasó mucho después de esas sesiones de trabajo.

Este tema ya ha surgido, producto de algunos análisis ya circulando, los que recomiendo leer,  como es el caso del de José Miguel (Jo) Piquer con su columna Terremoto 2010: ¿Internet resisitió bien la prueba?, Jo es académico de la Universidad de Chile, probablemente una de las personas que más sabe en Chile de la Internet Chilena, lo que concluye en esa columna es que nuestra red pública de datos - Internet Chilena - no estuvo a la altura de las circunstancias y su desempeño no fue el que se espera de infraestructura crítica.  Otra opinión que apunta en la misma dirección es la de Juan Carlos Barroux en su blog.

Me atrevo a plantear algunas iniciativa que debieran ser prioritarias para mejorar nuestra desempeño en esta área

• Robustecer la topología de nuestro backbone de Internet, en este ámbito NIC Chile, SUBTEL, la academia e ISP's tienen mucho que decir
• Establecer un red alternativa para la conectividad voz/datos de las autoridades y organismos de emergencia, no es posible que las autoridades no tengan un verdadero teléfono rojo y que el Presidente de la república no pueda realizar un llamado telefónico o esté compitiendo con la saturación de la red
  
• Identificar y reducir al mínimos los puntos únicos de falla, por ejemplo: la fibra óptica al Sur de diferentes compañías pasa por los  mismos puntos
• Desarrollar enlaces alternativos de datos usando tecnología satelital para emergencias
• Priorizar tráfico de paquetes, en una catástrofe si se justifica el traffic shaping

Esto en al caso del mundo público, para los privados que exista mayor transparencia del comportamiento de algunos proveedores de infraestructura TI.  Si algo aprendimos (los más viejitos) con las inundaciones del 1982 y ECOM es que un datacenter no puede estar al lado de un río y más encima en un subterráneo.

La actitud en estos momentos es de acumular la mayor cantidad de información y de una buena vez establecer un backbone de Internet que de el ancho para este tipo de situaciones, la peor postura que puede tener la industria TIC (como lo he visto en otra industria los últimos días, que espero cambie)  es no transparentar la información, hay muchos rumores dando vuelta.  Debemos desarrollar propuestas que permitan robustecer el comportamiento de las TIC en catástrofes como las del 27 de febrero y que efectivamente las subamos de categoría a niveles de otras infraestructuras.

Imagen: http://www.taringa.net/posts/noticias/4787345/Gran-Tragedia-en-Chile-y-parte-del-Mundo.html

Hace unos días me invitaron a exponer a un seminario vinculado a los temas de planes de contingencias y gestión de crisis, el seminario organizado por la empresa Tata y el Diario Financiero, tuvo bastante convocatoria, estimo unas 100 personas, me tocó compartir el podio con Christian Nicolai ex Subsecretario de telecomunicaciones y Margarita Cabello (Gerente de Riesgo Operacional de Tata). Probablemente lo primero a decir es que producto del terremoto se han puesto de moda estos temas y hoy se habla y escribe mucho sobre el comportamiento de la infraestructura en particular la tecnológica frente a un evento como el del 27 de febrero, de lo cual me alegro y espero que el grado de sensibilidad frente al tema aumente así como ocurrió con el tema de la calidad de la construcción en Chile luego del terremoto de 1985.

Creo que tuvimos una buena complementación con Christian y Margarita en los temas, ya que mi presentación versó sobre como se comportó (o debiera decir como no se comportó) nuestra infraestructura TI (Internet, Telefonía Celular, Datacenter, Web) frente al terremoto, algo de ello he escrito aquí, luego Christian desarrollo su presentación en torno a una evaluación de las telecomunicaciones y como estas se han transformado en un elemento central en los negocios, para luego hacer algunas predicciones y que podremos esperar hacia adelante en el desarrollo de los servicios de telecomunicaciones, como es el caso de la mensajería unificada y la comunicación unificada.  Finalmente cerró Margarita con una mirada metodológica, para enfrentar el tema de los planes contingencia - BCP (Business Continuity Plan)  y planes de recuperación de desastres - DRP (Disaster Recovery Plan), pasando por análisis de impacto o BIA (Business Impact Analysis), para alguien que desee profundizar en esta materia, recomiendo ver este ejemplo de BIA

Algunas de las cosas que se plantearon es que las situaciones como el 27 de febrero nos plantean desafíos importantes a la hora de diseñar e implementar las soluciones tecnológica en el ámbito público y privado, pero creo que el mayor desafío es de efectivamente darle un estatus de infraestructura crítica al soporte tecnológico de los procesos de negocios tanto en el mundo privado como público.  Ante un par de preguntas que hizo Margarita, quede sorprendido con la cantidad de respuestas. Primera pregunta cuantos de ustedes (refiriéndose a los presentes en el salón) antes del 27 de febrero tenían planes de contingencia y unas 20 personas levantaron la mano, a la siguiente pregunta cuantos estaban trabajando un plan producto del terremoto, unas 10 personas más levantaron la mano, lo que nos da unas 30 personas en un salón con más de 100. 

Esto demuestra que nos falta un rato para instalar adecuadamente este tema y por otro lado entenderlo como un problema sistémico y de negocios, no es el problema de y para los computines.

Y como en un seminario de contingencia no pueden faltar estas, yo esperaba hacer mi presentación con mi equipo (mac + keynote) en que había trabajado atractivas transiciones, para lo cual hice las pruebas de rigor antes del inicio del seminario y todo bien, pues a la hora de dar la charla nada funcionó, por lo que tuve que recurrir el plan de contingencia, un pendrive con la presentación pasada a formato pdf con lo cual se perdieron todas las transiciones, lo que demostró que en la operación de contingencia los niveles de servicio se reducen pero al menos se puede lograr el objetivo inicial.

Espero que iniciativas como estas se multipliquen y ayuden a poner en el debido sitial la infraestructura tecnológica y de comunicaciones, que hoy por hoy son centrales en la operación de nuestra sociedad.

Referencias

• Mas información sobre el comportamiento de Internet en NICLabs

Esto ha generado un diferencial importante en los proyectos de desarrollo de software, particularmente en las aplicaciones de negocios.  Esta brecha se aprecia de forma importante en el no cumplimiento de tiempos y recursos definidos para el proyecto y en una percepción bastante generalizad por parte de áreas usuarias, de que los informáticos no cumplen con plazos y costos.

Las principales dificultades que se plantean a la hora de desarrollar software (aplicativos de negocios) corresponden a la etapa de capturar los requerimientos de los usuarios, ya que luego de aquello se tiene la esperanza por parte de los desarrolladores que el mundo se va a congelar, es como jugar el juego del un, dos tres momia es.  Sin hacerse cargo de los continuos cambios que tienen los modelos de negocios, producto de la competencia, otros productos y en general situaciones de mercado en muchos casos no previsibles.  Según Standish Group cerca del 60% de los requerimientos cambian a lo largo de un proyecto.  Otro elemento importante a tener en cuenta que si cambias de opinión en algún requerimiento al comienzo y esto tiene un impacto financiero de X, este mismo cambio cuando el proyecto lleva un 70% de avance el impacto se multiplica por 100 (100X).  Por eso es que hay que congelar el mundo ya que sino el costo puede ser enorme.

El desafío que se plantea a futuro en el proceso de desarrollo de software es comprimir el tiempo, esto es, reducir el tiempo entre el surgimiento de la necesidad y contar con la aplicación que la soporta.  A partir de esto es que han surgido metodologías cuyo propósito es precisamente reducir ese tiempo y hacerse cargo de que el mundo sigue girando con su consecuente impacto en los sistemas de soporte al negocio.

Las metodologías denominadas "ágiles" que las hay en varios sabores, siendo las más conocidas XP y SCRUM han comenzado a ganar gran cantidad de adeptos.

SCRUM, método desarrollado por Jeff Sutherland y Ken Schwaber, el cual se basa en un método de producción en la industria automotriz, en particular, la empresa Toyota.  Dicha empresa diagnóstico un problema similar al mencionado en el caso del software, demasiado tiempo entre la idea de un nuevo modelo y su puesta en el mercado.   Con este método logró reducir órdenes de magnitud el time to market de nuevos modelos, transformándose en un líder en esta área.

Fuente: Softhouse

Algunos elementos básico de SCRUM

1. Opera en base a iteraciones cortas (15 días a 1 mes)
2. Equipos de trabajo pequeño (7-9 personas)
3. En cada iteración se implementan funcionalidades usuarias y estas deben ser demostrables
4. Usuario participa en las iteraciones
5. No requiere que digas todo desde el comienzo
6. Puedes cambiar de opinión en el camino
7. Cada equipo tiene un líder
8. Se trabaja con reuniones diarias (CORTAS), en las cuales cada miembro del equipo contesta: ¿Qué ha cumplido desde la última reunión?, ¿Qué obstáculos se presentan?, ¿Qué voy a terminar?

El propio Schwaber define SCRUM como una colección de buenas ideas más que una metodología en el sentido estricto y se basa en la transparencia, ya que todo el mundo sabe que está pasando con el desarrollo de una determinada aplicación en periodos cortos de tiempo (cada iteración) y no se encuentra con un "conejo" al final, que habitualmente parece más un jira-mono-canguro.  No todas las organizaciones han podido implantar estas prácticas con éxito, sólo el 35% lo logra ya que muchas no están dispuestas a transparentar el proceso.

La gracia de este proceso incremental además es que se implementa lo que se requiere realmente y no todos los chiches que a alguien se le ocurrió al comienzo del tiempo, recuerden que el 65% de las funcionalidades de un producto nunca son usadas, ¿qué porcentaje de Office utilizan?

Les recomiendo vean estos videos que adjunto de los ideólogos del SCRUM

Scrum et al. - Ken Schwaber, Google Tech Talls - 5/9/2006

Scrum Tuning: Lessons learned - Jeff Sutherland, Google Tech Talks - 7/12/2006

Fuente Imagen: www.drdudd.co.uk

En el último tiempo me han llegado muchas solicitudes por herramientas para gestión de proyectos y PMO en general.  Lo primero a decir es que existe una cantidad enorme de herramientas para la gestión de proyectos, de hecho en uno de los repositorios que les menciono más abajo aparecen más de 400 herramientas, desde planillas adecuadas para tal efecto hasta sistemas de clase mundial, tales como: Primavera (Oracle), Mercury (HP) o Clarity (CA), pasando por sistemas en modalidad SaaS (Software as a Service), de desktop o bien para ser instalados en servidores corporativos.

Dado que existen una enorme variedad de soluciones de software para la gestión de proyectos, diría que el principal problema no es encontrar herramientas sino identificar cual es la que mejor se adapta a mis necesidades.  Estas herramientas cubren las diferentes necesidades funcionales: gestión de tareas y actividades, gestión de recursos, calendarios, colaboración, gestión documental, administración de portafolios, gestión de riesgos.  A continuación les adjunto un listado de sitios donde se pueden encontrar información de herramientas de gestión de proyectos.

Algunos de los sitios donde pueden encontrar referencias y análisis comparativos de estas herramientas son:

• Análisis comparativos de herramientas de gestión de proyectos en Wikipedia
  

• Evaluación de las principales herramientas de gestión de proyectos en el sitio Top ten Reviews 
  

• En el sitio Gantt Head existe una herramienta que permite seleccionar por tipo diferentes sistemas de gestión de proyectos (muy interesante)

• Portal de herramientas de gestión de proyectos del tipo web cuenta con un listado de 468 herramientas y una pequeña descripción de sus características el mismo sitio cuenta con una revisión de un panel de especialistas de algunas de las herramientas

• Artículo de revista francesa Journal du Net en el cual se analizan las principales herramientas de gestión de proyectos del tipo Open Source (afortunadamente el artículo está en francés para aquellos que nos gusta ese idioma) 

Los estándares de “Proyecto” corresponden a un conjunto de guías que buscan establecer un modelo de diseño y ejecución de proyectos, predecible, escalable y que cuente con un esquema de gobierno de los proyectos.  Para esto existen diversos enfoques metodológicos pero me atrevo a decir que los más difundidos a nivel mundial el estándar PMI y estándar Prince2.  Estos estándares proveen de guías para todo tipo de proyectos, sin importar su tamaño ni industria.  Ambos tienen una terminología y un ciclo de vida de los proyectos diferentes, les recomiendo que analicen ambos y adopten uno de ellos.

Con la idea de entregar algunos elementos al momento de la selección de la metodología a utilizar, me parece adecuado dar algunos antecedentes de ambos métodos

PMI, es un estándar desarrollado en los Estados Unidos de Norteamérica, con el mercado americano en mente cuando se desarrolló, PMI desarrolló su metodología denominada PMBOK en cual ya va en su cuarta versión (recientemente lanzada) y cuenta con esquemas de capacitación y certificación.  Adicionalmente cuenta con capítulo en cada país donde está presente en Chile, lo pueden ver en .  En nuestro país esta metodología se ha utilizado con mucha fuerza en proyecto industriales en particular en el caso de proyectos mineros.  No cubre las etapas de pre-proyecto y tiene un enfoque a las actividades (WBS), es decir es un “project management process”. 

Project Management Body of Knowledge (PMBOK)

Prince2, se trata de un estándar desarrollado en Gran Bretaña, por la OGC, oficina del gobierno británico, su foco original fue el sector público, pero ha sido adoptada en otras industrias, tiene una fuerte presencia en Europa y en las zonas de influencia del Reino Unido.  Los seguidores de este método le critican a PMI su excesivo enfoque comercial al momento de adoptar dichas prácticas y en los procesos de certificación.  No cubre las etapas de adquisición, define roles estándares para los miembros de los equipos de trabajo y tiene un enfoque a producto más que a actividad, es decir es un product oriented process.

Les adjunto un documento que compara ambas metodologías, esto es a partir del PMBOK realiza un análisis de Prince2, es bastante interesante y permite tener una mejor visión de ambos métodos. Ver en A comparison of Prince2 vs PMBOK

Cualquiera sea su decisión de metodología a utilizar, es fundamental tener en consideración algunos elementos que pueden ayudar su adopción

• Instalar la nomenclatura, todas las metodologías de proyecto cuentan con sendas terminologías y glosarios (de hecho para certificarse PMI hay que aprenderse todos esos términos), los más importante es que sus equipos de proyecto al momento de utilizar el método entiendan todos lo mismo por un determinado concepto.

• Implementar el ciclo de vida de los proyecto para los nuevos proyectos, no tiene sentido insertarlo en los proyectos en curso.  Esto logrará una mayor motivación el los equipos de trabajo y no afectará a los proyectos en curso.

• Utilice las guías y recomendaciones del estándar, evalúe las herramientas que el estándar provee y adóptelas en su  proyecto, sea selectivo, recuerde que estos estándares están pensados en forma genérica y son para cualquier tipo de proyecto en cualquier industria, existirán etapas, prácticas que en sus proyectos no aplican “no fuerce su uso”.

• Realice importante esfuerzos de capacitación e inducción del método en su equipos de trabajo, debe contar con un proceso de entrenamiento constante de su personal.

• Utilice herramientas tecnológicas como apoyo, idealmente herramientas de gestión de proyectos, sea majadero en su uso ya que eso implica mayor orden en el proceso.  Seleccione la mejor herramienta para el soporte (interna, comercial, Web u otra)

¿Seleccionó la metodología de su agrado?

1. Alineamiento Estratégico
2. Gestión de Recursos
3. Valor generado
4. Desempeño
5. Gestión del Riesgo

A las organizaciones se les plantea el desafío de instalar un modelo de gobierno TI que de cuenta de dichos elementos.

El año 2008, el IT Governance Institute  desarrolló un estudio (Estudio ITGI - 2008) a nivel global de la relevancia de TI en las organizaciones y de los niveles de madurez del gobierno TI.  La encuesta se desarrolló en agosto de 2008 a 250 gerentes generales (CEO) de organizaciones de 22 países en distintos continentes, 50% de las empresas encuestadas pertenecían al sector manufactura, 14% en servicios profesionales, el resto se repartía en forma igualitaria en Telecomunicaciones, Servicios Financieros, Retail y Transporte.

Al analizar los resultados, el 51% de las respuestas consideran que la contribución de TI a su negocio es catalogada como muy importante, este porcentaje sube a un 87% cuando se agrega la categoría algo importante.  La contribución de TI más significativa se refiere al ámbito de la eficiencia siguiéndole la categoría de efectividad.

La mayoría de los encuestados perciben que las inversiones en TI generan valor al negocio y el 58% dice que dichas inversiones están alineadas con las expectativas.

En una cantidad significativa de empresas, los CIO’s son parte del equipo directivo, pero su dependencia mayoritaria es de los gerentes de finanzas (CFO).

SIn perjuicio de lo anterior, el tema TI no está presente en la agenda del directorio (comité directivo) en forma recurrente, sólo es analizado en casos específicos.

Lo que sorprende es que dado el nivel de importancia asignado a las TI y su aporte al negocio las organizaciones no cuentan con un modelo de gobierno establecido, un 20% está partiendo en este tema y un 38% ha tomado algunas medidas ad-hoc implementadas, recordemos que el nivel inicial de madurez de gobierno TI es medidas ad-hoc, por lo que podemos concluir que cerca de un 60% de las organizaciones no cuentan con un modelo de gobierno. 

Si comparamos estos resultados, con los obtenidos por el estudio desarrollado por el CETIUC  denominado ENTI, podemos apreciar una brecha muy significativa de la relevancia de las TI y su aporte al negocio, no nos queda más que tener confianza que a futuro esto mejorará en nuestro país, la esperanza es lo último que se pierde.

Sería interesante que el ENTI 2009 incorpore el método de “cluster analysis” (análisis de conglomerados) realizado en el trabajo de ITGI respecto de medir la correlación entre las dimensiones relevancia TI, estatus del gobierno TI y resultados TI.

• Relevancia TI: corresponde al nivel de importancia de las TI para la visión y estrategia del negocio.

• Estatus del gobierno TI: frecuencia con que este tema se discute en el directorio, accountability de los proyectos/inversiones  T, nivel de madurez del gobierno TI y su alineamiento con el gobierno corporativo.

• Resultados TI: capacidad de las inversiones para crear valor  al negocio y nivel de cumplimiento de las expectativas.

Veremos como evoluciona este tema y que nos deparará el ENTI de este año en esta materia.  Pero algo que he podido ver es que mientras más madura es una organización mejor gobierna su TI.

• En Brasil a hay una mayor percepción de incremento de los riesgos, con 78% de los encuestados en tanto en nuestro país sólo el 50% piensa en que aumentó.
• Respecto de la atención que la alta gerencia le presta a este tema en Brasil el 75% dice que es alta o muy alta versus 60% de Chile.
• En Chile los peligros que más no preocupan son el spyware y malware respecto de los otros países.
• En Chile hay una preocupación muy alta de la perdida o robo de dispositivos móviles (smartphones y PDA's) con contenido corporativo, esta preocupación llega al 73% y está más de 10 puntos por sobre el país que le sigue.
• La integración de la seguridad física con la TI donde se parecía más importante es en Chile (80%) y Brasil (77%)

El tema de la seguridad de la información es un problema a nivel mundial y se requiere de una importante cuota de sensibilización en todos los niveles (en la empresa, en la casa con nuestros hijos y en nuestra vida cotidiana), más aún cuando nos encontramos en un fuerte proceso de digitalización, en los últimos años he visto un cambio importante en este sentido.  Recuerdo hace no mucho tiempo me tocó discutir con un afamado periodista respecto del accionar de un hacker, la prensa en ese minuto los veía como una especie de Robin Hood modernos, y el referido periodista en un programa radial alabó lo que realizó este hacker, caso en el que me tocó participar de cerca (realizar un peritaje del caso a petición de la Corte de Apelaciones, de la cual soy perito), la persona en cuestión no la sacó barata, fue expulsado de su carrera y su trabajo y fue sentenciado por delito informático, ley 19.223.

Aún nos queda mucho por sensibilizar en este campo y creo que estudios como estos ayudan en tal sentido.