CobIT 5 y el valor de TI

Adentrándonos a como CobIT 5 nos puede ayudar a gestionar de manera holística las tecnologías de información en las empresas. Detallaremos como cada uno de los principios de este marco de trabajo nos permitirán contar con más información a la hora de implementar prácticas para un Gobierno Corporativo de TI.

Satisfacer las necesidades de las partes interesadas se destaca como el primer principio de este marco y expresa claramente que toda las empresas sean grandes o pequeñas deben asegurarse de crear valor para los demás, ¿Pero que significa crear valor? básicamente lograr beneficios para loa interesados con un costo óptimo de los recursos y minimizando el riesgo.

Sabemos que cada una de las partes interesadas pudiera llegar a tener conceptos diferentes de lo que significa crear valor, lo importante que debemos de tomar en cuenta y que este marco de trabajo puede aportar es como las metas corporativas y las metas de TI pueden alinearse y medirse basándonos en el tan mencionado Balanced Scorecard de Kaplan y Norton que ya como muchos sabemos esta herramienta se enfoca en 4 dimensiones importantes en las que cada una de las metas corporativas recaen, las cuales son: Financiera, Clientes, Procesos Internos y Crecimiento y Aprendizaje.

CobIT ha determinado 17 metas corporativas que nacen de las necesidades de las partes interesadas y como cada una de ellas podrían influir con los tres objetivos principales del gobierno: realización de beneficios, optimización de riesgos y optimización de recursos.
Y de igual manera 17 metas relacionadas con las TI alineadas de igual manera a las 4 dimensiones del BSC.

Algunas de las necesidades que tienen por resolver las partes interesadas son:
¿Cómo se consigue valor mediante el uso de TI?
¿Cómo se gestiona el rendimiento de TI?
¿Cómo puedo construir y estructurar mejor mi departamento de TI?
¿Cuánto dependo de mis proveedores externos?
¿Cómo de bien están siendo gestionados los acuerdos de externalización de TI?
¿Cómo puedo verificarlos sobre proveedores externos?
¿Cuáles son los requisitos para controlar la información?

Algunos de los beneficios de contar con metas corporativas y metas de TI es que le permite a la organización:
• Priorizar la forma en la que se implementará, se mejorará un Gobierno Corporativo de TI
• Definir objetivos y metas tangibles así como resultados más transparentes en todos los niveles de las organización
Sin embargo todos sabemos que no todas las organizaciones comparten los mismos objetivos, ni las mismas necesidades hacia sus interesados por lo que es importante recalcar que cada organización deberá identificar sus requerimientos de negocio que le permitan crear valor, identificar sus objetivos, sus metas corporativas y sus metas de ti que le permitan lograr y obtener resultados de que se cuenta con un buen Gobierno Corporativo de TI.

Esto es muy importante recalcarlo ya que muchas veces como Firma de Consultoría nos hemos enfrentado con organizaciones que quieren una implementación de Cobit 5 y no una implementación y definición de un Gobierno Corporativo adecuado para su organización ya que lo único que buscan es cumplir con lo que este “marco de referencia” nos ofrece y lo perciben como una norma que se debe seguir al pie de la letra.

¿Cómo sé si mi empresa está preparada para implementar un sistema de gestión de seguridad de la información?

Soy el nuevo CISO/CSO en mi empresa y me están pidiendo que mejore la seguridad de la misma, sé que existe algo llamado ISO 27001 y que me puede ayudar, pero ¿Estará lista mi empresa para esto?

1.- ¿Qué es?

De forma muy, muy, muy simplificada, podemos decir que es una serie de fases y áreas de conocimiento que permiten conocer e implementar medidas de seguridad (controles).

Así mismo, para entender un poco que es lo que busca, podemos hacernos algunas preguntas alrededor de los temas que se consideran en esta norma internacional que nos permitirán identificar que tan avanzados tenemos nuestro esquema de gestión de seguridad y que cosas no debemos omitir o dejar de considerar.

Política de seguridad -¿Tiene usted algún documento que demuestre soporte administrativo y compromiso con el proceso del Sistema de Administración de Seguridad de la Información?

Organización de seguridad -¿Tiene usted un esquema de administración establecido para iniciar y controlar la implementación de la seguridad de la información dentro de la organización y para administrar la provisión de seguridad de la información?

Clasificación de activos y control –¿Tiene usted un inventario completo de activos y responsabilidades asignadas para asegurar que efectivamente se mantenga la protección en relación a la seguridad?

Seguridad del personal –¿Tiene usted bien definido la descripción del trabajo de todo el personal, subrayando los roles y las responsabilidades de la seguridad?

Seguridad física y medio ambiental -¿Tiene usted en forma clara y concisa la definición de los requisitos de seguridad acorde con sus premisas y la gente involucrada?

Administración de las comunicaciones y operaciones – ¿Optimiza usted sus habilidades de comunicación para facilitar una clara operación del Sistema de Administración de Seguridad de la Información?

Control del acceso -¿Tiene usted administración de la red para asegurarse que solamente aquellos con la debida responsabilidad tienen acceso a la información de las redes y a la protección de la infraestructura?

Mantenimiento y desarrollo de los sistemas -¿Tiene usted por seguro que los proyectos de tecnologías de la información (IT) y las actividades de soporte son conducidas de una manera segura a través del control de datos y el cifrado donde es necesario?

Conformidad -¿Puede usted demostrar a sus clientes, empleados y autoridades, su compromiso por cumplir los requisitos estatutarios y reguladores de la seguridad de la información?

Gestión de incidentes de seguridad – ¿Existe alguna forma de comunicación de eventos y evaluación de puntos débiles de seguridad de la información?; ¿Se tiene algún proceso para la gestión de incidentes y mejoras de seguridad de la información?

Administración de la continuidad del negocio -¿Usa usted un proceso administrativo para el desarrollo y mantenimiento de planes de contingencia de negocios que protejan a los procesos críticos de mayores desastres o fallas?

2.- ¿Cómo puedo implementarlo?

1. Adquiera la norma
2. Considere entrenamiento
3. Organice un grupo y determine su estrategia y alcance
4. Considere opciones de servicios profesionales
5. Emprenda una evaluación de riesgo
6. Defina las políticas
7. Genere documentos de apoyo
8. Implemente el sistema de administración de seguridad de la información
9. Desarrolle una forma de medir su nivel de avance
10. Mida sus avances de forma periódica

3.- ¿Dónde pido ayuda?

http://www.asentti.com/iso27001-informacion.html

Contáctenos, estamos a sus órdenes para ofrecerle asistencia y resolver sus dudas.

¿Sabías que la norma ISO 27001 ha cambiado su versión?

Recientemente se anunció que la norma ISO/IEC 27001 cambiará de la versión 2005 a la 2013, con la finalidad de mejorar los Sistemas de Gestión de Seguridad de la Información implementados en las empresas.

¿Sabes cuánto tiempo se tiene para este cambio?

Las certificadoras aproximan que las empresas tendrán hasta el 2015 para realizar su transición de 2005 a 2013.

Cambios significativos de la norma ISO/IEC 27001:2013

¿Cuántos Dominios forman la nueva ISO/EC 27001:2013?

La norma ISO 27001:2005 solicitaba 11 Dominios, los cuales al cubrir en su totalidad, aseguraba el correcto funcionamiento del SGSI de una empresa. Hoy en día ISO/IEC 27001:2013 aumenta sus dominios a 14 esto con la finalidad de mejorar la efectividad de un SGSI dentro de una organización.

¿Sabes cuantos controles forman la nueva versión de ISO 27001:2013?

Anteriormente la norma ISO/IEC 27001:2005 estaba formada por 133 controles, con esta nueva actualización han disminuido a 113, esto debido a que se eliminan controles no muy funcionales dentro de un SGSI.

Conoce la Nueva Estructura de ISO 27001:2013

Criptografía se ha convertido en una sección separada (#10) y ya no es (lógicamente) parte del dominio de «Desarrollo y adquisiciones de sistemas». Algo similar ha sucedido con las «relaciones con los proveedores» y se han convertido en una sección aparte (#15). El dominio «Gestión de comunicaciones y operaciones» se dividió en «Operaciones de seguridad» (#12), y «Comunicaciones de seguridad» (#13). Las secciones ahora son:

• 5 Security Policies
• 6 Organization of information security
• 7 Human resource security
• 8 Asset management
• 9 Access control
• 10 Cryptography
• 11 Physical and environmental security
• 12 Operations security
• 13 Communications security
• 14 System acquisition, development and maintenance
• 15 Supplier relationships
• 16 Information security incident management
• 17 Information security aspects of business continuity
• 18 Compliance

Reestructura de Controles ISO/IEC 27001:2005 Vs ISO/IEC 27001:2013

ISO/IEC 27001:2005 Control	ISO/IEC 27001:2013 Cambio
Control de dispositivos móviles y teletrabajo, previamente en el control de acceso.	Pasa a ser parte de la sección 6.2 Organización de la seguridad de la información.
Manipulación de los medios de comunicación que anteriormente era parte de Gestión de comunicaciones y operaciones.	Forma parte de la Gestión de activos 8.3.
Control de acceso al sistema operativo, las aplicaciones y el control de acceso a la información.	Se han fusionado en el Sistema de control de aplicaciones y acceso 9.4.
Control del software operativo, anteriormente un único control en el Sistema de información de la adquisición, desarrollo y mantenimiento.	Es ahora una categoría aparte 12.5 en la sección de Operaciones de seguridad.
Las consideraciones de Auditoría sistemas de información.	Pasan del dominio de Cumplimiento a la sección 12.7 de Seguridad de operaciones.
Control intercambio de información.	Ahora es parte de la sección 13.2 Seguridad en las comunicaciones.
Controles relacionados con comercio electrónico.	Se fusionan en el dominio 14.1 sobre Requisitos de seguridad de sistemas de información.
Controles relacionados con la Continuidad del Negocio.	Se agrega una nueva categoría, la 17.2 que nos habla sobre la redundancia de datos.
Gestión de Incidentes.	Dos categorías de la sección de Gestión de Incidentes se han unido en una sola.

Implementar ITIL… ¿Por dónde empiezo?

Un error que cometemos muy a menudo es centrarnos en reducir costos y resolver problemas técnicos, si bien estos aspectos no se deben de descuidar nunca, hoy en día hay otros factores que debemos considerar para el éxito de las TICs, si no los tomamos en cuenta podría costarnos la supervivencia en el mercado.

Para ello debemos atender las demandas de los clientes y entregar soluciones de calidad, en éste punto entra en juego la Gestión de Servicios de TI; para logarlo debemos tomar en consideración la implementación de buenas prácticas de ITIL.

Antes de iniciar con la planeación de la estrategia de implementación de ITIL, primero debemos plantearnos las siguientes preguntas ¿Qué le duele al negocio? ¿Cuáles son los objetivos de negocio?… una vez que tengamos la respuesta de éstas preguntas podremos identificar a hacia dónde quiere ir la organización, pero nunca debemos perder de vista en dónde se encuentra la organización y qué se puede lograr.

Para poder implementar ITIL es necesario que elaboremos de forma estratégica una sólida tomando en consideración la perspectiva financiera, es decir ¿qué resultados esperamos para los socios y accionistas?, para nuestros clientes cómo crearemos valor, procesos internos y el aprendizaje e innovación.

Es importante que revisemos todos los detalles sobre cómo podemos implementar ITIL, ya que un proyecto de ésta naturaleza debemos considerar diversos aspectos, tales como tecnología, procesos y gente, sobre todo gente; y precisamente en el último aspecto radica una de las cuestiones fundamentales y uno de los motivos más comunes para que muchos proyectos se conviertan en verdaderos desastre.

Si queremos que la implementación de ITIL sea un éxito en nuestra organización es muy importante considerar desde la planeación el cambio organizacional, lo cual permitirá que todos los involucrados puedan romper paradigmas.

Tips para Implementar ITIL

Por cada éxito en una implementación de ITI, al menos hay una que no va tan bien, por tan motivo es muy importante tomar en cuenta algunos Factores Críticos de Éxito que nos evitaran dolores de cabeza y harán menos pesada la transición.

• Contar con el apoyo de la alta gerencia; el compromiso de la alta gerencia es muy importante en cualquier organización, de hecho se considera como uno de los primeros requisitos en el establecimiento de sistemas de gestión para diversos estándares, tales como ISO 9000, 27000, 20000, etc.; si intentamos implementar ITIL como si fuera una iniciativa del departamento de TI, sin involucrar al negocio, será un costoso error que puede ocasionar retrasos en el proyecto y situaciones adversas debido a que no se dieron a conocer las ventajas de tener éste tipo de procesos.

Debemos iniciar con un trabajo de pre-venta, para evitar que se tenga la percepción de algo peligrosamente creativo y en muchos casos, altamente burocrático. Para iniciar correctamente nuestro proyecto es recomendable elaborar políticas corporativas firmadas por la alta gerencia, así encontraremos menos obstáculos en el camino.

• Se requiere que sea un proyecto formal; es muy importante que asignemos recursos, humanos, materiales y económicos suficientes. En muy importante tener en cuenta que al inicio habrá muchas tareas extras que realizar, además de la operación normal, entre las cuales se encuentran:
  • Administración del Proyecto
  • Actualización de la documentación de los procesos actuales, si es que existe dicha documentación, si no, habrá que documentarlos desde cero.
  • Revisión y análisis de los procesos para alinearlos a ITI, lo cual puede conllevar a la adopción de nuevas herramientas y sistemas que deberán ponerse en funcionamiento mientras continua la operación normal.
  • Establecimiento y seguimiento del plan de comunicación interna del proyecto.

• Contar con un cronograma; para iniciar el proyecto debemos contar con un mapa, ruta o camino a seguir que nos indique el punto de partida y el destino sin complicaciones ni desvíos.

• Personal capacitado; el personal encargado del desarrollo del proyecto deberá estar capacitado en situaciones reales de implementación (no solo teoría), que haya experimentado el desarrollo, la puesta en marcha, y la mejora continua de varios de los procesos ITIL . Si no tenemos en nuestra organización a las personas con esa experiencia, es necesario que busquemos apoyo en consultores con trayectoria, experiencia y reconocimiento en el mercado.

• No ofrecer soluciones milagrosas; si bien es cierto que al implementar ITIL trae consigo múltiples beneficios, entre ellos, la reducción de costos y la satisfacción del cliente, sin embargo éstos no se verán reflejados a corto plazo, sino en un lapso de uno a cinco años dependiendo de la complejidad de nuestra organización.

• Adoptar los principios que beneficiaran a la organización, no debemos adoptar todos, si nos centramos en los procesos más críticos para el negocio, podemos iniciar con los puntos más dolosos, los cuales pueden ser incidentes, problemas y gestión de cambios, con estos podemos producir resultados rápidos y visibles.

• Capacitar al personal en todos los niveles; es muy común certificar a un pequeño grupo de personas, los cuales se convertirán en los gurús de ITIL; debido a que se trata de un nuevo esquema de trabajo es muy importante capacitar mucha gente en todos los niveles de la organización. Debemos de contar con un grupo de personas que entiendan con claridad lo qué es ITIL para que funjan como guías y entrenadores, para que durante la ejecución del proyecto se proporcionen cursos internos, de acuerdo a las necesidades de la organización.

Además es muy importante considerar en la capacitación a los usuarios de TI, ya que deberán comprender qué lograremos con la implementación de ITIL, cuña será su participación, cómo recibirán los servicios de TI (aprobaciones y tiempos de respuesta).

Nunca debemos perder de vista que el éxito de nuestro proyecto depende en gran medida de cómo afrontemos el cambio en la cultura organizacional, así podremos reducir la curva de aprendizaje y la resistencia al cambio.

• Contar con un plan de comunicación efectivo; dar a conocer el proyecto antes, durante y después de la implementación son la llave del éxito. Debemos mantener informado tanto el personal de TI, como usuarios y proveedores, los avances de cada actividad relevante, por ejemplo, los cambios e interrupciones a los servicios antes de que sucedan, el no hacerlo generará incertidumbre.

• Asignar roles y responsabilidades; debemos iniciar por definir dueños de servicios, ya que si se ve afectado en algún momento un servicio ellos podrán tomar la decisión cualquier alteración, adición, cambio o interrupción. También debemos realizar un nombramiento oficial de los roles involucrados en los procesos, que incluya sus nuevas responsabilidades y así lograremos que cada uno de los involucrados cumpla con sus responsabilidades.

Bibliografía

http://gestionconocimientoti.blogspot.mx/2012/11/intentar-implementar-itil-en-mi-empresa.html

http://articulosit.files.wordpress.com/2012/07/itil-v33.pdf

http://www.bitcompany.biz/gestion-de-servicios-implementar-itil/#.UchxE9KZZ14

http://eliopercesepe.com/los-8-errores-al-implementar-itil/

http://www.slideshare.net/NFiguerola/cmo-asegurar-el-xito-en-itil

http://www.magazcitum.com.mx/?p=551

La responsabilidad del Equipo de Proyecto

En un ambiente estable donde un alto porcentaje de las actividades planeadas, suceden de manera esperada y cumplen con sus especificaciones, es fácil atribuir el resultado de un proyecto a las habilidades del gerente y el equipo de proyecto.

En todos los casos, si el gerente de proyecto o su equipo son inexpertos es muy posible que el proyecto fracase; pero aun cuando fueran muy aptos y laboriosos, los cambios en el ambiente del proyecto podrían dictaminar un fracaso. Parte de la dificultad de asumir la responsabilidad de un proyecto en un ambiente inestable es que el éxito o el fracaso del proyecto no tienen una relación tan directa con las habilidades o el empeño del gerente y su equipo.

Ante el fracaso, la reacción de las personas ajenas al equipo es negativa y a nadie le interesa entrar en detalles sobre las causas reales. En estos casos un grupo de personas que trabajó muy bien termina con la mancha del fracaso aun cuando, en realidad, las causas estaban fuera de su alcance.

En un escenario estable, como sucede en países de primer mundo, cuando hay cambios relevantes, los proyectos se replantean lo mismo que los planes y los presupuestos. En Latinoamérica, es más común que se pretenda seguir “a como dé lugar” sin molestar a la “autoridad” con las noticias de cambios inesperados. Por su parte, la “autoridad”, finge desconocimiento o tiene auténtica ignorancia sobre la situación del proyecto conservando así sus expectativas originales.

Chile, como excepción, siendo uno de los países más estables de América Latina, disfruta de una saludable relación comercial con los Estados Unidos. La estabilidad Chilena les permite actuar y hacer transacciones de manera similar a la Americana.

La lista de dificultades que los Latinoamericanos tenemos a la hora de participar en proyectos internacionales es muy larga. Es mucho más larga que la que tienen los Americanos con respecto a nosotros. Sin embargo para nosotros es más fácil hacer negocios con ellos que para ellos hacer negocios con nosotros.

¿Por qué nuestra lista de problemas es más larga?

Cuando alguien acostumbrado a un ambiente altamente estandarizado encuentra excepciones, las visualiza como un estándar roto. Por ejemplo: informalidad, mal manejo del tiempo, problemas de género. Cada ítem incluye todos los casos donde esa persona encontró que no se seguía el estándar.

Cuando no se tiene un esquema estandarizado, una persona describe un obstáculo en términos del obstáculo mismo. Se describe el hecho o la característica en sí y no como un desvío del estándar. Por esto es que nuestra lista de desafíos es más larga y detallada y no se refiere al desvío de un estándar sino al desvío de la expectativa individual. Esa expectativa varía de país a país en la región haciendo la tarea difícil inclusive entre nosotros los Latinoamericanos.

Cuando hablamos en América Latina tenemos que escuchar lo que el otro dice con atención porque es muy posible que me diga algo de una manera que nunca escuchamos antes, aunque el concepto sea familiar. En EEUU hay que tener mucho cuidado de no usar determinadas palabras que, aunque tienen un sentido amplio en el diccionario, solo se usan en determinado contexto. La gente está entrenada para escuchar menos pero entender el uso de “palabras clave”. Hablan mucho menos y de manera más estandarizada. Cada conversación no es un acto de creación, sino un acto de comunicación lo más precisa posible.

Al hablar y escribir, esperamos que escuchen y lean lo que estamos diciendo con nuestra peculiaridad y nuestro enfoque, sin perder la sutileza. Es más fácil conseguir eso de una audiencia Latinoamericana acostumbrada a vivir con menor grado de estandarización.

Ante un ambiente cambiante es muy común encontrar gente flexible, acostumbrada a cambiar de estrategia rápidamente. Lo que hoy funciona, puede o no, funcionar mañana porque el entorno puede no ser el mismo. En cambio, en mercados donde la estabilidad es menos esquiva, la gente establece lo que entiende como “la mejor manera de hacer esto” y lo sigue haciendo igual.

En cada extremo de este espectro la estrategia tiene sentido. Si funciona no se arregla y si no funciona se cambia. El problema se plantea cuando alguien pretende instalar una metodología rígida en un lugar inestable. No se trata de la recepción que tenga este emprendimiento ni de buena voluntad, se trata de que cuando exista un cambio el plan deberá ser ajustado y si es muy rígido habrá fricción y luego fracaso.

A veces es difícil explicar que es cierto el dicho: lo perfecto es enemigo de lo bueno, y que lo bueno es bueno. En América Latina esta situación es un ejercicio diario. Si se hace con medida o en exceso dependerá del criterio de la gente involucrada.

Cuando la idea es hacer las cosas como se deben hacer, lo primero es entender lo que significa: “cómo se deben hacer”. Lo que en ese momento se convierte en la regla. Cuando los Americanos o Europeos Occidentales hablan de comunicar expectativas, muchas veces lo que hacen es pasar el reglamento… Ante estas situaciones esperamos de ustedes estas reacciones.

Nuevamente, lo estandarizado funciona en un ambiente estable. En América Latina lo más valioso es tener un criterio afilado, sazonado, trabajado, en fin; un buen criterio. No es tan importante seguir la regla como poder diagnosticar la situación y decidir, in situ, qué hacer.

Para alguien ajeno a nuestro ambiente, nuestra permanente creatividad a la hora de tomar decisiones es desconcertante. Y esto, el desconcierto, es lo más dominante en los proyectos multiculturales. Es importante destacar que el Gerente de Proyectos desconcertado tiene que hacer un esfuerzo por sobreponerse y evaluar el resultado de un hecho inesperado. Para los Latinoamericanos esto es incómodo pero cotidiano, para los Americanos en general esto, como modo de trabajo, es inaceptable.

Dicho todo esto una persona con criterio en un proyecto de México, tendrá mayores posibilidades de éxito que 5 personas que pretenden seguir la regla.

Cuando se trabaja en un ambiente donde las reglas cambian constantemente, las personas con criterio son el único pilar del proyecto mientras los planes y presupuestos de ajustan, si es que alguna vez se ajustan.

La Administración de Proyectos con el Folklore Latino

Existe un perfil particular en el estilo de trabajo latinoamericano. Esta visión se basa, por un lado, en hechos reales y por otro en el desconocimiento de las causas de esos comportamientos.

Todo Gerente de Proyectos con experiencia conoce las consecuencias de trabajar con gente de distintas culturas e idiosincrasias. Lo inesperado se convierte en la norma.

Los mexicanos (y en general los latinos), no entendemos por qué no logramos alcanzar algunos estándares de operación de Europa o Estados Unidos. Tampoco estamos seguros de que esos lineamientos nos llevarán al éxito en nuestro entorno tan particular, sin embargo nuestra formación y las “normas internacionales” nos ponen en posición de COPIAR.

Los mexicanos tenemos un conjunto de capacidades distinto al de otras regiones. Ni mejor ni peor, solo diferente, pero con valor propio. Nuestras capacidades son útiles bajo ciertas circunstancias y tienen muchos beneficios. Debemos valorar los beneficios de nuestro estilo de trabajo y aceptar que nuestros talentos son muy útiles en el mundo de la Gerencia de Proyectos, conocerlos de manera sistemática y tomar ventaja de ellos.

Principales desafíos en México

Escases de recursos; se espera del equipo el mismo nivel de conocimiento y desempeño que en primer mundo sin el dinero ni el tiempo para el entrenamiento.

Desconocimiento

• Del problema real
• De las herramientas realmente necesarias
• De las expectativas y motivaciones
• De lo que cuesta y tarda hacer las cosas realmente
• De la burocracia local
• De la brecha de conocimiento (no saben que no saben)
• De la rivalidad entre personas y grupos

Comunicación ruidosa y complicada por distintos factores:

• Idiosincrasia
• Prejuicios enraizados con respecto a los demás que deja pocas posibilidades para el desarrollo del equipo (cultura, clase, género, etc.)
• Diferencias de “idioma” profesional
• Enredos con códigos, supuestos, expectativas, etc. (Si quiere decir “SI”; Mañana no solo significa “HOY NO” etc.)
• La conciencia de “clase” y la relación de “autoridad”
• La excusa como herramienta

Manejo “inesperado” del tiempo

• Nos parece que el otro maneja el tiempo de manera inapropiada
• Relevancia de los horarios (comienzo y fin de reuniones)

Manejo de la información

• Secrecía excesiva
• Presentación parcial o incompleta
• Descripciones inexactas por salvar una postura

Alineación de Objetivos

• Abandono del proyecto una vez cumplida la tarea individual
• Prioridad baja/cambiante para los proyectos

Distintos grados de planificación, seguimiento y control de los proyectos

• Informalidad Vs. formalidad
• Varios planes paralelos (necesidad de elegir un escenario “a”, “b” o “c”)
• Falta de responsabilidad (“accountability” no tiene traducción al español)
• El poder informal por encima de lo acordado
• Grados de análisis necesario vs. excesivo
• Reuniones desorganizadas que no cumplen su objetivo (¿todos tenían el mismo objetivo?)

Falta de confianza

• En el objetivo del proyecto
• En el gerente de proyecto
• En el equipo
• En el jefe

Diferencia de “estilo de trabajo”

• Uso de herramientas, (utilización muy distinta en el mismo equipo de trabajo).
• Técnicas de gerencia
• Técnicas de motivación
• Manejos políticos dentro de las organizaciones

¿Es todo esto un riesgo para nuestro proyecto?

¡NO! Las diferencias culturales son una CERTEZA en los proyectos, el riesgo está en el éxito o fracaso de nuestra estrategia para enfrentarlas. Sabiendo que van a existir diferencias culturales y que van a impactar el proyecto, tenemos que buscar minimizar el impacto y, a partir de ahí, analizar el riesgo de que este acercamiento sea o no apropiado. El plan, que puede ser tan simple como usar gente con experiencia en proyectos similares o muy complejos y los entrenamientos adecuados, tiene que existir porque el obstáculo EXISTE.

Soluciones Propuestas

¿Qué hacemos con esta larga lista de desafíos? ¡Abordarlos de frente! De manera proactiva. En México, gran parte del trabajo del gerente de proyecto es actuar con liderazgo y flexibilidad. El no ver toda la realidad con sus matices impide al “jefe” valorar lo que este gerente y su equipo están haciendo por el proyecto. ¡Nosotros mismos le quitamos visibilidad a nuestro trabajo!

Hay que abrir el juego. Si el equipo es multifuncional hay que abordar las diferencias culturales de entrada. Debemos trabajar por un lado con las personas y por otro con la comunicación. Tener en cuenta que cuando uno se divierte el tiempo pasa rápido. Si disfrutamos de estos desafíos, los tomamos como oportunidades de crecimiento profesional y personal, si usamos el sentido del humor, la paciencia, la tolerancia y el amor a nuestro trabajo, los proyectos se vuelven experiencias muy satisfactorias. De hecho, estas capacidades personales son herramientas fundamentales en todo tipo de proyecto.

Pregúntese: “¿Quiero tener razón o quiero tener éxito en el proyecto?” 

No somos “la excepción” de la norma, solo tenemos matices diferentes. Debemos ser promotores del cambio a la PRODUCTIVIDAD con tolerancia, aplicando nuestro valor.

Herramientas Tecnológicas de Administración de Proyectos

La Administración de proyectos y las herramientas de tecnologías han tenido un progreso considerable,   apenas es reconocible la situación en la que se encontraba hace 10 años, en el año 2003 el PMBOK® se convierte en un estándar reconocido internacionalmente.

La administración de proyectos internos y externos de las organizaciones actualmente es un proceso esencial de la organización,  en donde es fundamental contar con herramientas que ayuden a la administración de los proyectos,  garantizando así que los recursos materiales y humanos sean utilizados adecuadamente y que los resultados de los proyectos serán de acuerdo al alcance y costos esperados en la organización y con el cliente.

Existe actualmente un gran número de herramientas orientadas a la administración de proyectos, algunas de  las utilizadas por las organizaciones son: Changepoint de Compuware, Microsoft Project,  Clarizen, Primavera Systems, Daptiv, Clarity,  PlanView, entre otras. Gartner Group Inc. ha publicado una tabla comparativa de las herramientas en el Magic Quadrant for Integrated IT Portfolio Analysis Applications.

 El elegir una de estas herramientas tecnológicas para la administración de proyectos depende de las necesidades de la organización, del presupuesto con el que se cuente para la implementación de la herramienta y el tiempo que se desea dedicar para capacitar a los recursos humanos.

Todas las herramientas tecnológicas de administración de proyectos ofrecen módulos que permiten administrar el portafolio de proyectos, planear y gestionar los proyecto, el alcance de las mismas depende de la herramienta que se elija.

Las tendencias tecnológicas se encaminan hacia la integración de los procesos de la organización con el objetivo de contar con una visión integral de los proyectos para la toma de decisiones.

Las herramientas de administración de proyectos se apegan  a metodologías de administración de proyectos y a las mejores prácticas definidas en la  Guide to the Project Managment Body of Knowledge (PMBOK®) del Project Management Institute (PMI®), algunas herramientas permiten apegarse a la metodología propia de la organización.

 El elegir una herramienta de administración de proyectos desarrollada con base en la propia metodología de la empresa permite:

1. El cambio sea aceptado con mayor tolerancia por los recursos humanos involucrados en la gestión del proyecto dentro de la organización.
2. Definir las entradas y salidas que se necesita por cada fase del proyecto de acuerdo a los procesos de la organización
3. Definir los roles que la organización ya tiene definida por cada fase del proyecto
4. Mejorar la metodología con la que ya se encuentra la organización familiarizada
5. Utilizar los documentos y formatos que ya cuenta la empresa

 Ventajas de utilizar herramientas tecnológicas de Administración de Proyectos:

1. Uso de interfaces web, lo que permite administrar y revisar el seguimiento del proyecto desde cualquier lugar en cualquier momento.
2. Contar con el avance del proyecto en tiempo real.
3. Contar con informes del avance del proyecto (Definidos por la herramienta o definidos de acuerdo a las necesidades de la organización)
4. Control en la asignación de las tareas, asignación de recursos, actualización de las planificaciones.
5. Mayor control de versiones de documentos.
6. Integrar la información de los procesos de la organización en la gestión de proyectos
7. Resguardar los resultados generados en los proyectos.
8. Contar con el costo del proyecto (pérdidas y ganancias).
9. Tener control de los recursos invertidos en el proyecto
10. Mejorar los procesos de la organización haciéndolos más agiles.
11. Reducir pérdidas de información de los proyectos.
12. Tener control de los recursos humanos subcontratado y de la empresa.
13. Contar con servicios de recursos humanos externos a distancia.
14. Mejorar la administración del portafolio de proyectos de la organización de acuerdo a las necesidades (urgentes, costos, etc.).
15. Mejorar la comunicación del equipo del proyecto, informando de todos los eventos (riesgos, problemas, necesidades, acciones, resultados, etc.), para que se pueda reaccionar de manera oportuna en cada fase del proyecto.

Desventajas de utilizar herramientas tecnológicas de Administración de Proyectos:

1. Costo de inversión de acuerdo a la herramienta elegida (licencias, implementación, software, etc.)
2. Organizar y agilizar los procesos de la organización que se ejecutaran en la herramienta
3. Crear una cultura organizacional del uso de la herramienta para lograr contar con la información que se necesita en los proyectos.
4. Capacitar al personal involucrado en los procesos y proyectos de la organización en el uso de la herramienta.
5. Elegir una herramienta que no cuenta con la madurez que necesitan los proyectos de la organización podría incrementar los costos de la implementación.

ITIL a lo largo del tiempo…

ITIL

¿Qué es la Gestión de Servicios de TI?

Hace algunas décadas, la mayor preocupación se centraba en mejorar y desarrollar nuevo hardware y software, sin embargo desde la década de los 90s la atención se ha centrado en la Gestión de los Servicios. Derivado de esto se ha generado la incógnita de ¿qué es la gestión de servicios de TI?… La Gestión de los Servicios de TI es llevada a cabo por los Proveedores de Servicios de TI a través de la combinación apropiada de personas, Procesos y Tecnologías de la Información.

En la actualidad existen diversos marcos de referencia para la Gestión de Servicios de TI, sin embargo en ésta publicación nos centraremos en la biblioteca de infraestructura de tecnologías de información, ITIL por sus siglas en ingles.

¿De dónde viene ITIL?

ITIL fue desarrollado por la Oficina de Comercio Gubernamental del Reino Unido (OGC por sus siglas en inglés).

En una primera instancia ITIL se ideó para mejorar la administración del servicio de TI en el área central del gobierno del Reino Unido, sin embargo, es aplicable para todo tipo de organizaciones, ya sean del sector público o privado, pequeñas o grandes.

La OGC no desarrollo toda la biblioteca. Consejeros editoriales, conformados por expertos de la industria, determinaron el enfoque de cada uno de los libros. Una organización redactó los libros y otras se encargaron de revisar la calidad de los mismos. La OGC se encargó de la función editorial y verificó los procesos de cada uno de los libros.

Todas las organizaciones participantes se aseguraron de que se cumpliera con los requerimientos de calidad establecidos en ISO 9001, con la finalidad de asegurarse de que ITIL mantuviera un enfoque de calidad de ISO.

¿Qué entendemos por buenas prácticas?

Seguramente el concepto “buenas prácticas” lo hemos escuchado pero a ciencia cierta no lo conocemos; es un conjunto de metodologías, sistemas, herramientas y técnicas, las cuales han sido aplicadas con resultados sobresalientes en empresas de clase mundial.

¿Qué es ITIL?

Es un conjunto de buenas prácticas para alinear el capital humano, procesos y tecnología, y de ésta manera proporcionar servicios de TI de calidad.

Es muy importante mencionar que no se trata de una camisa de fuerza o norma rígida como suele considerarse a veces; aunque ITIL establece un conjunto de directrices, cada implementación es diferente y cambia en función de las necesidades de cada organización.

En la actualidad existe un creciente interés en ITIL y esto ha conllevado a representar más que sólo libros, se ha generado una industria completa que incluye:

• Capacitación
• Certificación
• Consultoría
• Herramientas de Software

Versiones de ITIL

Versión 1

Fue desarrollada bajo el auspicio de la CCTA, se tituló Método de Infraestructura de Gobierno Tecnología de Información, GITM por sus siglas en inglés; durante varios años terminó expandiéndose hasta 31 libros.

Versión 2

Para hacer más accesible ITIL, se agruparon los libros de acuerdo al objetivo de los procesos. El tema Gestión de Servicios (Soporte de Servicios y Provisión de los Servicios) es él más difundido e implementado.

Versión 3

Fue realizada en junio de 2007, ésta versión incluye las experiencias de las versiones anteriores y se centra principalmente en mejorar las actividades de TI, además se caracteriza por una mayor orientación al cliente.

ITIL v3 consta de cinco libros, que en conjunto forman el Ciclo de Vida del Servicio:

• Estrategia del Servicio
• Diseño del Servicio
• Transición del Servicio
• Operación del Servicio
• Mejora Continua del Servicio

Actualización 2011

Cuatro años después se genera la actualización de la versión tres, se realizaron modificaciones a la nomenclatura para una mayor claridad y algunos aspectos en cada libro, a continuación citamos algunos de ellos:

• Estrategia del Servicio: se agregan dos nuevos procesos, Gestión de Relaciones con el Negocio y Gestión de la Estrategia.
• Diseño del Servicio: se incluyó un nuevo el proceso Gestión de Coordinación del Diseño y se han aclarado y agregado conceptos para mejorar el resto del libro.
• Transición del Servicio: se cambia el nombre de Gestión de Evaluación como Gestión de la Evaluación del Cambio, también se realizan mejoras en la utilización del CMS y aclaraciones sobre otros componentes.
• Operación del Servicio: se realizan aclaraciones con respecto a las técnicas de análisis de la Gestión de Problemas y se modifican los diagramas de flujo.
• Mejora Continua del Servicio: se realiza cambio al nombre CSI Model por CSI Approach. Además se incluye el concepto de un registro de mejoras para las iniciativas individuales.

¿Cuáles son los tipos certificaciones de ITIL?

Con la llegada de ITILv3 en 2007 la OCG cambió el esquema de certificación de profesionales en ITIL. Este esquema permanece con la edición 2011.

A continuación detallaremos el esquema de formación de ITIL:

• Fundamentos ITIL: es primer certificado que se obtiene después de aprobar un examen y está basado en los conceptos generales de ITIL.

• ITIL Nivel Intermedio: El nivel Intermedio proporciona dos flujos específicos de educación – el ciclo de vida del Servicio (color verde, el cual consiste en dar 1 examen por cada fase del servicio) y el Modulo de las Habilidades (rojo, presentan 4 exámenes, uno por cada módulo).

• ITIL Expert en IT Service Management: Para a obtener el certificado, es necesario contar con 22 créditos.

Como primer requisito es poseer la certificación “Fundamentos ITIL”, éste otorga 2 créditos; posteriormente obtener 15 créditos a través de los exámenes de nivel intermedio. Estos exámenes corresponden a los módulos Service Lifecycle y/o Service Capability, y otorgan entre 3 y 4 créditos cada uno (ver gráfico) y final mente realizar el examen “Managing Across the Life Cycle” que otorga 5 créditos.

• ITIL V3 Master: Es la certificación más alta disponible, ésta se reservan para todas aquellas personas que puedan demostrar, con pruebas de su capacidad de aplicar las buenas prácticas definidas por ITIL en el mundo real.

La Seguridad de la Información desde el Punto de Vista Negocio

La información es un valioso activo del que depende el buen funcionamiento de una organización.

Mantener su integridad, confidencialidad y disponibilidad es esencial para alcanzar los objetivos de negocio.

Por esa razón, desde tiempos inmemorables las organizaciones han puesto los medios necesarios para evitar el robo y manipulación de sus datos confidenciales.

En la actualidad, el desarrollo de las nuevas tecnologías ha dado un giro radical a la forma de hacer negocios, a la vez que ha aumentado los riesgos para las empresas que se exponen a nuevas amenazas.

Desafortunadamente, es relativamente fácil tener acceso a las herramientas que permiten a personas no autorizadas llegar hasta la información protegida, con poco esfuerzo y conocimientos, causando graves perjuicios para la empresa.

La mayor parte de la información reside en equipos informáticos, soportes de almacenamiento y redes de datos, englobados dentro de lo que se conoce como sistemas de información.

Estos sistemas de información están sujetos a riesgos y amenazas que pueden generarse desde dentro de la propia organización o desde el exterior.

Existen riesgos físicos como incendios, inundaciones, terremotos o vandalismo que pueden afectar la disponibilidad de nuestra información y recursos, haciendo inviable la continuidad de nuestro negocio si no estamos preparados para afrontarlos.

Por otra parte, se encuentran los riesgos lógicos relacionados con la propia tecnología y, que como hemos dicho, aumentan día a día. Hackers, robos de identidad, spam, virus, robos de información y espionaje industrial, por nombrar algunos, pueden acabar con la confianza de nuestros clientes y nuestra imagen en el mercado.

Introducción a la ISO/IEC 20000:2011

La ISO 20000 es una norma internacional enfocada a establecer los requisitos en la planificación, implementación, operación, monitoreo, revisión, y mejorar del Sistema de Administración de Servicios.

¿Cuáles son los beneficios de adoptar la norma ISO 20000?

Permite alinear los requisitos y las necesidades del negocio. Define un lenguaje común y las herramientas para garantizar la integración de nuestros proveedores en la cadena de valor hacia los servicios, clientes y usuarios de las TI’s.

¿Quién puede incorporar la ISO 20000 a su organización?

La ISO 20000 aplica tanto para empresas donde la TI es core del negocio y a las que cuentan con un departamento de TI que da servicio a usuarios internos, en ambos casos garantiza que sus servicios estén alineados con los requisitos del negocio y se puedan proveer con calidad y a un costo razonable.

¿Cuál es la similitud entre la ISO 20000 e ITIL v3?

La norma ISO 20000 es un documento breve, que define los requerimientos mínimos que una organización debe cumplir para tener conformidad y para obtener la certificación mediante una auditoría de certificación. ITIL, por otro lado, es una recopilación de buenas prácticas, es decir, un marco para el diseño, implementación, operación y mejora de la Administración de los Servicios.

¿Cuáles son las diferencias más significativas entre la versión 2005 y 2011 de la ISO 20000?

Los principales cambios en la nueva versión de la ISO 20000 son:

• Ofrece mayor detalle en cada requerimiento.
• Establece requisitos para definir un alcance correcto.
• Brinda más términos y definiciones.
• El PDCA es mucho más claro, detallado y mejor estructurado.
• Se pide la integración con otros sistemas como, SGSI y SGC.
• Establece requerimientos para la Revisión por Dirección.
• Agrega una nueva clausula sobre el Diseño y Transición de nuevos servicios o servicios modificados.