martes, 8 de febrero de 2011

Como identificar un proyecto con riesgo de fracaso

Las estadísticas del artículo son muy interesantes y bastante reales sobre los proyectos de TI. Y es muy importante contar con la información al día sobre la salud del proyecto. En lo personal encuentro 3 elementos críticos para el éxito o fracaso de un proyecto:
  • Comunicaciones inadecuadas: Si importar que metodología o proceso se esté utilizando para controlar y administrar el proyecto, es necesario contar con un eficiente y ágil proceso de comunicaciones, con evidencia real de su realización, que genere entregables que den visibilidad del proyecto. Como mínimo contar con reuniones sino diarias, semanales de avance del proyecto, con documentación clara y concisa (minutas y reportes). Y de ser posible (dependiendo el tamaño y formalidad de la empresa) implementar un proceso automatizado con métricas reales sobre la salud del proyecto.
  • Falta de Compromiso: Desde el adecuado patrocinio y financiamiento del proyecto, como el proceso de liderazgo para el continuo enfoque del equipo en los objetivos y resultados del proyecto día con día. Esto derivado de la correcta definición del alcance del proyecto y su detalle a través de la ingeniería de requerimiento.
  • Riesgos desatendidos: Comúnmente en los proyectos siempre hay buenas intenciones de que estos se lleven a cabo y se concluyan exitosamente. Sin embargo, la falta de planeación y atención de los riesgos, deriva en falta de asignación temprana en los proyectos para su prevención, corrección, transferencia o eliminación. En particular con los proyectos de TI, implementar un proceso de definición, validación y actualización de arquitectura empresarial (o arquitectura de software/tecnológica, según aplique el alcance del proyecto). Permitirá la planeación e identificación de riesgos derivados de la complejidad de esta arquitectura, de esa manera se podrán asignar recursos y tomar decisiones desde el inicio del proyecto, para controlar estos riesgos.
También es importante aclarar que es posible obtener ciertos beneficios alternativos de los fracasos de los proyectos:
  • Catalizador de cambios. Es posible que del fracaso, surjan elementos que indiquen aéreas de oportunidad. Lo cual pueda derivar en una implementación de procesos que permitir mejorar estas aéreas.
  • Base de Conocimiento y mejores prácticas aprendidas. Este nuevo conocimiento surge de situaciones negativas, pero apoya la continua mejora y próximas implementación (tanto de proyectos como de procesos).
  • Soluciones alternativas o cumplir con algunos requerimientos esperados del proyecto. Es importante medir el valor sobre aquellos requerimientos obtenidos.
  • Análisis Holístico. Se recomienda realizar un análisis integral para identificar lo sucedido con el proyecto cubriendo las aéreas de TI y aéreas del Negocio, tanto las afectadas, involucradas, dependientes y participantes en el proyecto.

Como identificar un proyecto con riesgo de fracaso

Las estadísticas del artículo son muy interesantes y bastante reales sobre los proyectos de TI. Y es muy importante contar con la información al día sobre la salud del proyecto. En lo personal encuentro 3 elementos críticos para el éxito o fracaso de un proyecto:
  • Comunicaciones inadecuadas: Si importar que metodología o proceso se esté utilizando para controlar y administrar el proyecto, es necesario contar con un eficiente y ágil proceso de comunicaciones, con evidencia real de su realización, que genere entregables que den visibilidad del proyecto. Como mínimo contar con reuniones sino diarias, semanales de avance del proyecto, con documentación clara y concisa (minutas y reportes). Y de ser posible (dependiendo el tamaño y formalidad de la empresa) implementar un proceso automatizado con métricas reales sobre la salud del proyecto.
  • Falta de Compromiso: Desde el adecuado patrocinio y financiamiento del proyecto, como el proceso de liderazgo para el continuo enfoque del equipo en los objetivos y resultados del proyecto día con día. Esto derivado de la correcta definición del alcance del proyecto y su detalle a través de la ingeniería de requerimiento.
  • Riesgos desatendidos: Comúnmente en los proyectos siempre hay buenas intenciones de que estos se lleven a cabo y se concluyan exitosamente. Sin embargo, la falta de planeación y atención de los riesgos, deriva en falta de asignación temprana en los proyectos para su prevención, corrección, transferencia o eliminación. En particular con los proyectos de TI, implementar un proceso de definición, validación y actualización de arquitectura empresarial (o arquitectura de software/tecnológica, según aplique el alcance del proyecto). Permitirá la planeación e identificación de riesgos derivados de la complejidad de esta arquitectura, de esa manera se podrán asignar recursos y tomar decisiones desde el inicio del proyecto, para controlar estos riesgos.
También es importante aclarar que es posible obtener ciertos beneficios alternativos de los fracasos de los proyectos:
  • Catalizador de cambios. Es posible que del fracaso, surjan elementos que indiquen aéreas de oportunidad. Lo cual pueda derivar en una implementación de procesos que permitir mejorar estas aéreas.
  • Base de Conocimiento y mejores prácticas aprendidas. Este nuevo conocimiento surge de situaciones negativas, pero apoya la continua mejora y próximas implementación (tanto de proyectos como de procesos).
  • Soluciones alternativas o cumplir con algunos requerimientos esperados del proyecto. Es importante medir el valor sobre aquellos requerimientos obtenidos.
  • Análisis Holístico. Se recomienda realizar un análisis integral para identificar lo sucedido con el proyecto cubriendo las aéreas de TI y aéreas del Negocio, tanto las afectadas, involucradas, dependientes y participantes en el proyecto.

sábado, 15 de enero de 2011

Discusiones sobre la Alineación Estratégica y TI

Muy interesante el artículo al identificar uno de los principales factores por el cual la alineación entre los objetivos del negocio y las aéreas de tecnologías de información es deficiente. Este factor se refiere a la estructura organizacional aislada. Donde los esfuerzos para cumplir los objetivos de negocio directos o indirectos se realizan aislados y en algunos casos incluso se genera re-trabajo. Otro indicador interesante de este aislamiento, seria que las iniciativas de automatización de procesos únicamente son esfuerzos del área de TI, y no tienen patrocinio adecuado, y por lo tanto el impacto es limitado de estas iniciativas es limitado, y comúnmente desperdiciado, incluyendo esfuerzos robustos como la implementación de BPM o SOA en la organización.

El éxito para la alineación empresarial y las aéreas de TI, se basa en la integración del negocio, eliminando así el aislamiento empresarial. A manera que las iniciativas de automatización de procesos y generación de la arquitectura empresarial se permeen en toda la organización, integrando a los patrocinadores clave desde la concepción de las iniciativas, y controlando el avance de estas iniciativas como se vayan ejecutando. Para lo cual existe ya practicas bastante robustas y completas como COBIT (ValIT y RiskIT), y TOGAF para diseñar, implementar y medir la ejecución de la arquitectura empresarial.

martes, 4 de enero de 2011

Introducción a COBIT, ValIT y RiskIT

Definición: 

Objetivos de Control para la información y Tecnologías relacionadas (COBIT- Control Objectives for Information and related Technology) es un conjunto de mejores prácticas para el manejo de información creado por la Asociación para la Auditoría y Control de Sistemas de Información,(ISACA - Information Systems Audit and Control Association), y el Instituto de Administración de las Tecnologías de la Información (ITGI - IT Governance Institute) en 1992.

Objetivo:

"Investigar, desarrollar, publicar y promocionar un conjunto de objetivos de control generalmente aceptados para las tecnologías de la información que sean autorizados (dados por alguien con autoridad), actualizados, e internacionales para el uso del día a día de los gestores de negocios (también directivos) y auditores." Gestores, auditores, y usuarios se benefician del desarrollo de COBIT porque les ayuda a entender sus Sistemas de Información (o tecnologías de la información) y decidir el nivel de seguridad y control que es necesario para proteger los activos de sus compañías mediante el desarrollo de un modelo de administración de las tecnologías de la información.

ValIT:

Es un conjunto de documentos que proveen un marco de trabajo para el gobierno de las inversiones en TI, creado por ITGI. Es una declaración formal de los principios y procesos para la administración del portafolio de TI.





Las organizaciones siguen haciendo importantes inversiones en negocios posibilitados por TI: Inversiones en el mantenimiento, crecimiento o transformación del negocio que tienen un componente crítico de TI. La experiencia y un creciente volumen de investigaciones empíricas demuestran que dichas inversiones, cuando se gestionan bien dentro de un marco de gobierno efectivo, generan oportunidades importantes en las organizaciones para la creación de valor.

Muchas organizaciones han creado valor mediante la selección de las inversiones oportunas y la gestión efectiva de las mismas desde la concepción, pasando por la implementación, hasta la realización del valor esperado. Entre los ejemplos se encuentran IBM, que ha podido ahorrar más de 12 mil millones de USD en dos años uniendo las diversas partes de su cadena de suministro, reduciendo así los niveles de inventario, y Southwest Airlines, que ha podido reducir los costes de aprovisionamiento y aumentar los niveles de servicio mediante su proyecto de transformación de la cadena de suministro.

Sin embargo, sin un gobierno efectivo y una buena gestión, estas inversiones generan una oportunidad igualmente significativa para erosionar o destruir valor. De hecho, según una publicación de Gartner de 2002, 2 se desperdicia el 20 por ciento de todos los gastos en TI, representando, a nivel global, una destrucción anual de valor de 600 mil millones de USD.

Una lección fundamental es que la inversión en TI ya no trata solamente de implementar soluciones de TI, sino que cada vez más trata de implementar el cambio posibilitado por TI. Esto implica mayor complejidad y mayor riesgo que en el pasado. Las prácticas de gestión que tradicionalmente se han aplicado ya no son suficientes. El mensaje es claro: las inversiones de negocio posibilitadas por TI pueden dar enormes beneficios, pero solo con los procesos de gobierno y gestión apropiados y el pleno compromiso e implicación de todos los niveles de dirección. Hasta ahora, sin embargo, la dirección no ha tenido un procedimiento claro que indique la forma de considerar las inversiones en TI o de informar sobre o monitorizar el posible éxito o fracaso de dichas inversiones.
Al considerar que existía una falta de guías de inversión y gestión de TI, el IT Governance Institute, trabajando conjuntamente con otros profesionales líderes en la comunidad de negocio y TI, ha lanzado la iniciativa Val IT.

Esta iniciativa, en la que se incluyen investigaciones, publicaciones y servicios de soporte, tiene como objetivo ayudar a la gerencia a abordar este reto, así como garantizar que las organizaciones logren un valor óptimo de las inversiones de negocio posibilitadas por TI, a un coste económico, y con un nivel conocido y aceptable de riesgo. Val IT constituye una extensión y complemento de COBIT, que proporciona un marco de control global para el gobierno de TI.

En concreto, Val IT se centra en la decisión de invertir (¿estamos haciendo lo correcto?) y la realización de beneficios (¿estamos obteniendo beneficios?), mientras que COBIT está enfocado en la ejecución (¿lo estamos haciendo correctamente, y lo estamos logrando bien?).

El gobierno efectivo parte del liderazgo, compromiso y respaldo desde arriba. Sin embargo, dicho liderazgo, aunque es crítico, no es suficiente. En Val IT, se da soporte al liderazgo estableciendo un marco global, con un complemento completo de procesos de soporte y otros materiales de orientación desarrollados para ayudar al consejo / directorio y a la dirección ejecutiva a comprender y desempeñar sus papeles relacionados con las inversiones de negocio posibilitadas por TI.

En Val IT, soportado en el marco de control en COBIT, se proporciona una fuente única, creíble y codificada para dar soporte a la creación de un valor de negocio real a partir de las inversiones posibilitadas por TI. Val IT es relevante para todos los niveles de dirección a todo lo ancho tanto del negocio como de TI, desde el Director General y el consejo / directorio hasta todos aquellos involucrados directamente en los procesos de selección, aprovisionamiento, desarrollo, implementación, despliegue y realización de beneficios. Val IT contiene guías esenciales para todos.


RiskIT



El marco de los riesgos de TI, RISK IT, se complementa con COBIT,  que proporciona un marco integral para el control y la gestión de las organizaciones de soluciones y servicios de TI. Aunque COBIT establece las mejores prácticas para la gestión de riesgos proporcionando un conjunto de controles para mitigar los riesgos de TI, RISK IT establece las  mejores prácticas con el fin de establecer un  marco para las organizaciones para identificar, gobernar y administrar los riesgos asociados a su negocio.


El marco de riesgos de TI es utilizado para ayudar a implementar el gobierno de TI, y las organizaciones que han adoptado (o  están planeando adoptar) COBIT como marco de su gobierno de TI pueden utilizar RISK IT para mejorar la gestión de sus riesgos.








jueves, 16 de diciembre de 2010

Introducción a TOGAF

The Open Group Architecture Framework (TOGAF)  es un marco de trabajo de Arquitectura Empresarial que proporciona un enfoque para el diseño, planificación, implementación y gobierno de una arquitectura empresarial de información. Esta arquitectura es modelada por lo general con cuatro niveles o dimensiones: Negocios, Tecnología (TI), Datos y Aplicaciones. Cuenta con un conjunto de arquitecturas base que buscan facilitarle al equipo de arquitectos definir el estado actual y futuro de la arquitectura.


TOGAF tiene una definición propia de lo que es una arquitectura, que en resumen es "una descripción formal de un sistema, o un plan detallado del sistema a nivel de sus componentes que guía su implementación", o "la estructura de componentes, sus interrelaciones, y los principios y guías que gobiernan su diseño y evolución a lo largo del tiempo."

Un marco de trabajo de arquitectura es un conjunto de herramientas que puede ser utilizado para desarrollar un amplio espectro de diversas arquitecturas. Este esquema debe:

  • Describir una metodología para la definición de un sistema de información en términos de un conjunto de bloques constitutivos (building blocks, en inglés) que encajen entre sí adecuadamente.
  • Contener un conjunto de herramientas
  • Proveer un vocabulario común
  • Incluir una lista de estándares recomendados
  • Incluir una lista de productos que son idóneos para la implementación de los bloques constituitivos

TOGAF cumple estos requisitos.


TOGAF se basa en cuatro dimensiones:

  1. Arquitectura de Negocios (o de Procesos de Negocio), la cual define la estrategia de negocios, el gobierno, la estructura y los procesos clave de la organización.
  2. Arquitectura de Aplicaciones, la cual provee un plano para cada uno de los sistemas de aplicación que se requiere implantar, las interacciones entre estos sistemas y sus relaciones con los procesos de negocio centrales de la organización.
  3. Arquitectura de Datos, la cual describe la estructura de los datos físicos y lógicos de la organización , y los recursos de gestión de estos datos
  4. Arquitectura Tecnológica, la cual describe la estructura de hardware, software y redes requerida para dar soporte a la implantación de las aplicaciones principales, de misión crítica, de la organización.
El Metodo de Desarrollo de Arquitectura, ADM por sus siglas en inglés de "Architecture Development Method", es el método definido por TOGAF para el desarrollo de una arquitectura empresarial que cumpla con las necesidades empresariales y de tecnología de la información de una organización. Puede ser ajustado y personalizado según las necesidades propias de la organización y una vez definido se utiliza para gestionar la ejecución de las actividades de desarrollo de la arquitectura.

El flujo del proceso puede ser visto en: Architecture Development Cycle



El proceso es iterativo y cíclico. Cada paso inicia con la verificación de los requerimientos. La fase C involucra una combinación de Arquitectura de Datos y Arquitectura de Aplicaciones.
Cualquier información adicional relevante que se pueda recopilar entre los pasos B y C ayudarán a perfeccionar la Arquitectura de Información.

Las prácticas de Ingeniería del Desempeño se utilizan en la fase de requerimientos, lo mismo que en las fases de Arquitectura de Negocios, de Arquitectura de Sistemas de Información y Arquitectura Tecnológica. Al interior de la Arquitectura de Sistemas de Información se utiliza tanto la Arquitectura de Datos como la de Aplicaciones.

Referencia: The Open Group

viernes, 3 de diciembre de 2010

Joomla! : Herramienta para Gestión de Contenidos NO-Técnica

Es un sistema de Gestión de Contenidos (CMS), y entre sus principales virtudes está la de permitir editar el contenido de un sitio web de manera sencilla. Es una aplicación de código abierto programada mayoritariamente en PHP bajo una licencia GPL. Este administrador de contenidos puede trabajar en Internet o Intranets y requiere de una base de datos MySQL, así como, preferentemente, de un servidor HTTP Apache.

Joomla tiene la principal ventaja de ser intuitiva y no requiere un perfil técnico para trabajar con ella.

En Joomla se complementa de características, algunas se mencionan a continuación:

  • Mejorar el rendimiento web.
  • Versiones imprimibles de páginas.
  • Flash con noticias, blogs, foros, polls (encuestas), calendarios, etc.
  • Búsqueda en el sitio web e internacionalización del lenguaje.

Referencias:
JoomlaSpanish
Joomla!

jueves, 2 de diciembre de 2010

Introducción a la Innovación Sistemática - TRIZ

TRIZ es el acrónimo en ruso de Teorija Rezbenija Izobretatelskib Zadach, que significa "Teoría de Solución de Problemas Inventiva". La metodología TRIZ nació en Rusia en los años 40 al final de la 2a Guerra Mundial de la mano de Genrich S. Altshuller. Se conserva la denominación porque ya empieza a ser reconocida bastante extensamente con estas siglas.

La definición gira entorno a estos tres términos Problema, Invención e Innovación. Están muy relacionados y en algunos momentos se puede confundir su significado.

Intuitivamente sabemos lo que es un problema, se presenta fundamentalmente cuando se encuentran contradicciones, esto es cuando “mucho” es malo y “poco” también es malo, entonces, ¿cuál es la solución?, allí hay un problema, por lo general el objetivo del problema es el estado que deseamos alcanzar. Hay problemas sencillos y problemas complejos. Altshuller los clasificó como problemas rutinarios y problemas inventivos o creativos. Estos últimos son aquellos cuya solución no es obvia y obliga a "pensar" al que lo intenta resolver. TRIZ es de aplicación para este tipo de problemas.

Por el contrario, los problemas sencillos o estándar, se resuelven fácilmente con soluciones rutinarias y no dan lugar a la innovación., éstas son: Problema, Invención e Innovación. Están muy relacionados y en algunos momentos se puede confundir su significado.

Una invención no es sino el hallazgo de una solución novedosa o creativa a un problema dado. Es importante destacar que sin problema no hay invención, puesto que no se puede hallar nada si no se está buscando. A veces sin embargo se encuentra algo diferente a lo que se estaba buscando, y encontramos una solución novedosa a otro problema diferente. Pero hasta este momento la invención no deja de ser una idea.

Solamente cuando esta idea se hace realidad a través de su implantación se consigue una innovación. La industria solo está interesada en innovaciones, puesto que aquellas ideas creativas que sean difíciles de realizar quedarán descartadas y morirían en el olvido.

El TRIZ en un principio sólo se ocupó de invenciones. Hoy día se ocupa de invenciones realizables que más tarde sé conviertan en innovaciones.

Beneficios generales de TRIZ:
  • Sinergia del TRIZ en el Proceso de Innovación: La metodología TRIZ puede trabajar con las distintas herramientas conocidas de inventiva. Así, se puede ver que otros métodos y técnicas utilizados en los proceso de Innovación: Fiabilidad, QFD, Diseño robusto, mapas mentales, mapas conceptuales etc, se pueden y deben complementar con el TRIZ para formar un todo único. Para de este modo, ser capaces de dominar todos los aspectos del proceso de innovación.
  • Valor Añadido del TRIZ al Proceso de Innovación: El valor de TRIZ es precisamente ser capaz de hallar soluciones innovadoras, donde el resto de técnicas y herramientas es más débil.

Habitualmente los técnicos en invención tienden a aplicar como posible solución la primera idea que surge. Esto es lógico porque en cualquier proceso de solución de problemas o de generación de alternativas, uno de los factores limitativos más habituales es el tiempo y el otro la carencia de conocimientos y la dificultad de acceso a las fuentes.

En este contexto, el disponer de una Metodología como TRIZ capacita a los técnicos para generar más y mejores soluciones en menos tiempo y como consecuencia:
  • Innovar
  • Acercarse a la solución óptima
  • Mejorar el costo de la solución (y de su proceso de desarrollo)
Referencia recomendada.