Los 05 Eventos Scrum: Evento 4 Revisión del Sprint #scrum

La duración de esta reunión es normalmente de cuatro horas para Sprints de un mes. Si los Sprints son más cortos, la reunión será proporcionalmente más corta.

Al final del Sprint el Equipo Scrum y las otras partes interesadas se reúnen y mantienen una reunión de tiempo limitado en función de la duración del Sprint, para presentar y revisar los artículos “Completos”, el incremento del actual Sprint, y actualizar el Backlog del Producto. El propósito de presentar el incremento en esta reunión, es recabar información y conocer las solicitudes de cambio a la mayor brevedad.

El equipo de desarrollo no presentará un elemento a menos que este completo al 100% en base a la definición acordad de “Completo”. El Dueño del Producto debe asegurarse antes de la Revisión del Sprint, que los elementos que se presentan están “completos”. El Equipo de Desarrollo es responsable de demostrar y explicar los elementos.

El Dueño del Producto examina el estado del Backlog del Producto y las fechas de probables de finalización y los progresos realizados.

Por último, todo el equipo de Scrum participa en la revisión del backlog delproducto en base a los resultados del Sprint y el feedback del cliente.

 

Los 05 Eventos Scrum: Evento 3 Scrum Diario #scrum

El Scrum Diario es una reunión de 15 minutos para que el Equipo de Desarrollo inspeccione el trabajo realizado desde la última reunión, se sincronice, y establezca el plan para las próximas 24 horas. Debe realizarse, como su nombre indica a diario.

Durante el Scrum Diario cada miembro del Equipo de Desarrollo debe responder a estas tres preguntas:

  1. ¿Qué he hecho desde la última reunión?
  2. ¿Qué voy a hacer antes de la próxima reunión?
  3. ¿Qué obstáculos he encontrado en el camino?

El Equipo de Desarrollo debe evaluar el progreso hacia el objetivo del Sprint y pronosticar la probabilidad de completar los artículos antes de que concluya el Sprint.

Para evitar complicaciones el Scrum Diario debería celebrarse siempre en el mismo lugar y a la misma hora durante todo el Sprint. Es una reunión sólo para el Equipo de Desarrollo, no una reunión para todos los grupos de interés.

El Equipo de Desarrollo también debe monitorear el progreso del Sprint cada día y por lo tanto es una buena idea que el tablón del Sprint, que podría ser un mural o un grafico en la pared, este visible durante esta reunión. Podríamos además utilizar un gráfico de avance (burn-down chart) para monitorear el trabajo restante y prever si todos los artículos se completaran antes del final del Sprint. Observa el siguiente tablón de Sprint que incluye un diagrama de avance, para monitorear el progreso del sprint, en base a la cantidad pendiente de trabajo.

El tablón del Sprint anterior incluye una gráfica de avance del Sprint (Sprint Burn-down chart) que nos ofrece información para el seguimiento del Sprint, y que podría actualizarse después de cada reunión de Scrum Diario. Hablaremos sobre las gráficas de avance del Sprint en la próxima sección.
 

Los 05 Eventos Scrum: Evento 2 Planificación del Sprint #scrum

La reunión de planificación del sprint es uno de los eventos de scrum técnico.  Les recomiendo visitar el siguiente link para ver detalles antes de leer este post.

El Equipo de desarrollo no tiene que esperar hasta que el Backlog de Producto esté planificado al 100% para comenzar a desarrollar el proyecto. Tan pronto como el Backlog de Producto esté lo bastante maduro, tenga el número necesario de historias como para proporcionar la información de primer Sprint, el Dueño del Producto y el Equipo de Desarrollo comienzan con el primer Sprint.

El equipo de desarrollo debe estimar la capacidad de trabajo que puede ofrecer en un solo Sprint. Previamente el Dueño del Producto ya ha clasificado y ordenado los elementos del Backlog del Producto en base al valor de los artículos. El Dueño del Producto también es responsable de asegurarse de que los elementos (historias) sean fáciles de entender.

A continuación el equipo de desarrollo selecciona un número de elementos de la parte superior del Backlog del Producto y los pone en el Backlog del Sprint, para completarlos y entregarlos en el Sprint actual. Es el Equipo de Desarrollo el que calcula la cantidad de trabajo que requiere cada artículo. La cantidad total de trabajo de los elementos seleccionados del Backlog del Producto, debería estar cerca de la capacidad de trabajo estimada del Equipo de Desarrollo.

Seleccionados los artículos, el Equipo Scrum debería redactar el objetivo del Sprint. El objetivo del Sprint es el objetivo que debería alcanzarse durante el Sprint a través del desarrollo de los elementos seleccionados del Backlog del Producto, y proporciona orientación al Equipo de Desarrollo sobre por qué se está construyendo el incremento.

El Backlog del Producto debería estar ordenado de forma que facilite el establecimiento del objetivo del Sprint. Establecer y redactar el objetivo del Sprint es responsabilidad de todo el equipo Scrum.

El alcance del Sprint, que está compuesto por los distintos elementos seleccionados del Backlog del Producto, podría necesitar un mayor grado de detalle conforme el Sprint vaya evolucionando. Este mayor grado de detalle, deberá estar siempre alineado con el Objetivo del Sprint, y en el caso que fuera necesario negociarse, deberá estar presente el Dueño del Producto. El objetivo del Sprint también se incluye en el Backlog del Sprint.

Una vez seleccionado los elementos a entregar y establecido el objetivo del Sprint, es momento de planificar cómo los distintos artículos del Backlog del Sprint van a “transformarse” en un incremento del producto “Completo”, y como a través de estos se hará realidad el objetivo del Sprint. Esta es la última parte del Backlog del Sprint.

Un plan detallado es un elemento del Backlog de Producto (historias de usuario) descompuesto en tareas que habrá que hacer con el fin crear dicho elemento. Cada tarea puede contener estimaciones, dependencias y cualquier otra información similar necesaria para su seguimiento.

Las notas adhesivas amarillas (post-its) son las tareas que se crean al descomponer cada una de las historias de usuario (azules). Estas tareas (en amarillo) definen lo que el equipo de desarrollo va a hacer para entregar cada elemento, y son responsables de su preparación. Algunas tareas se crean en la reunión de Planificación del Sprint, y otros a lo largo de todo el Sprint.

El Backlog del Sprint está compuesto de:

  1. El Objetivo del Sprint
  2. Los artículos seleccionados del Backlog de Producto, que se entregarán a través de la Sprint (en azul)
  3. Un plan detallado para convertir los elementos seleccionados (historias o historias de usuario) en un Incremento “Completo” del producto y realizar el objetivo del Sprint

Puedes observar en el Tablón del Sprint los tres elementos del Backlog del Sprint: 1) el Objetivo del Sprint, 2) los elementos seleccionados del Backlog del Producto para completar en el Sprint, y 3) el plan detallado. El tablón cuenta además con otras características adicionales que permiten el seguimiento de las tareas en las columnas “Pendiente“, “En Progreso” y “Completado“.

tablero1

También puedes observar que se han añadido tareas adicionales a los elementos situados en la parte baja del cuadro (item # 3 al # 5). Son el resultado de la planificación detallada que se lleva a cabo durante el Sprint.

tablero2

Los elementos del Backlog del Sprint guardan por lo general el mismo orden que tenían en el Backlog del Producto, por lo tanto, el equipo de desarrollo debe trabajar primero en los artículos de la parte alta de la tabla.

Cuando escalamos Scrum, los miembros de cada uno de los equipos de desarrollo se reúnen con el Dueño del producto y seleccione sus elementos. De esta manera, cada equipo forma su propio Backlog del Sprint por separado, pero sobre un único Backlog de Producto.

Te recomiendo visitar:  Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard)

 

Los 05 Eventos Scrum: Evento 01 El Sprint #scrum

Un proyecto que sigue Scrum se gestiona en base a cinco eventos claves:

scrum evento 1

Evento 1: El Sprint

En un proyecto Scrum el producto final se entrega después de un número de iteraciones, que se llaman Sprints. En cada Sprint se desarrolla un incremento, que es una parte potencialmente entregable del producto final. Un incremento es la suma de todos los elementos del Backlog de Producto completados hasta un punto determinado del proyecto, que continuará creciendo tras de cada Sprint hasta que el proyecto concluya.

Puedes considerar que cada nuevo Incremento al final de un Sprint es una versión actualizada del Incremento anterior, con nuevos características y funcionalidades, y que puede o no entregarse al cliente, pero siempre debe ser potencialmente entregable.

La clave está en que generalmente los clientes solicitan cambios cuando ven el incremento, durante la Revisión del Sprint. Estas nuevas solicitudes se añaden al Backlog de Producto y se desarrollaran en función de su valor (valor de negocio). Recuerda que es el Dueño del Producto el encargado de esta establecer los criterios para determinar el valor de cada uno de los elementos del Backlog de Producto.

Cada elemento del Backlog del Producto (historia de usuario) debería poder completarse en un Sprint, ya que así son mucho más fáciles de gestionar. El Dueño del Producto y el Equipo de Desarrollo seleccionan los artículos de la parte superior del Backlog de Producto, que ya ha sido previamente ordenado por el Dueño del Producto. Su objetivo es conseguir que estos estén “Completo” al 100% cuando el Sprint termine, y generar un incremento. Un incremento es la suma de todos los elementos completados durante el Sprint actual y todos los Sprints anteriores.

Es importante llegar a un acuerdo sobre una definición de “completo” al inicio del proyecto. No diremos que algo está “completo”, a menos que se ajuste a dicha definición. Un elemento hecho al 99.999% no puede ser considerado como “completo”, no sería parte del incremento y por lo tanto no sería mostrado al cliente durante la Revisión del Sprint.

Sprint time box: La mayoría de las organizaciones trabajan con Sprints de entre 2 y 4 semanas. Si trabajamos con Sprints más largos es probable que los cambios no aplicados sean lo suficientemente “grandes” como para generar problemas, aumentando la complejidad y el riesgo. Por lo tanto debemos limitar los Sprints a no más de un mes de calendario. Pero por otro lado, los Sprints tampoco deben ser demasiado cortos porque entonces no seremos capaces de producir artículos completos durante los mismos. Recuerda que nuestro objetivo es ofrecer al cliente el producto, o solución final, artículo por artículo, dentro de los límites de los Sprints; no queremos dividir la realización de un artículo del Backlog de Producto entre varios Sprints.

¿Puede cancelarse un sprint? A pesar de que como ya sabemos los Sprint son “bloques de tiempo” que no cambian, el Dueño del Producto tiene la autoridad para cancelar un Sprint. Esto puede suceder cuando el Objetivo de Sprint ha quedado obsoleto, bien por cambios en el Backlog de Producto, en la estrategia, en el enfoque, etc. Cuando se cancela un Sprint, los elementos que están “completos” son revisados y aceptados, y el resto de los artículos (aquellos que no se han iniciado o están parcialmente completos) se añaden de nuevo al Backlog del Producto para completarse en el futuro, en caso de que fuera necesario.

 

Scrum – Metodología Agil #Scrum

scrum1

En esta oportunidad quiero presentarles algunas nociones básicas de Scrum como marco de trabajo que nos permite encontrar prácticas emergentes en dominios complejos, como la gestión de proyectos de innovación.

Scrum es un proceso agil que nos permite centrarnos en entregas de valor para el negocio en tiempos cortos. Es decir, manejamos proyectos basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del mismo. Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo.

Trabajar con este esquema permite una inspección rápida y continua del software en proceso de desarrollo en intervalos de tiempo cortos.  El negocio establece prioridades y el equipo se auto organiza para encontrar la forma de entregar las funcionalidades con mayor prioridad.  Cada dos o cuatro semanas cualquiera puede ver el trabajo real realizado, decidiendo así mismo si se puede liberar el producto o se debe continuar mejorando.

Veamos a continuación como nos organizamos para trabajar con Scrum.

scrum2.png

Lo primero que debemos definir es el o los equipos de trabajo, es decir tener  uno o más equipos de trabajo, con al menos 3 tres roles básicos dentro del equipo los cuales son:

1.dueño del producto,  Product Owner

Tiene la visión del negocio y conoce a detalle requerimientos del producto que se debe construir, lo que conlleva a ser el líder en cuanto a la toma de decisiones del desarrollo del producto.

2 ScrumMaster

El ScrumMaster es el responsable de que todos los involucrados entiendan y adopten los valores, principios y prácticas de SCRUM.

3 el equipo de desarrollo.

Responsables del diseño construcción y prueba del producto

Para entenderlo mejor veamos las características principales de cada rol.

scrum3

El Product Owner tiene la visión del negocio,  es quien tiene claro los requerimientos del desarrollo del software, siendo este quien tiene definido cada funcionalidad que debe desarrollarse es quien fija orden y prioridades en el product backlog; decide que debe construirse y que no.  En caso de hacer una modificación sobre alguna funcionalidad del software, es el product owner  quien fija las características minimas viables del software.

El Product Owner no da ordenes al equipo de desarrollo, solo debe asegurarse de hacer de conocimiento a cada integrante del equipo el product backlog, debe estar disponible y accesible al equipo para explicar las funcionalidades requeridas cada vez que sea necesario, participar en las reuniones diarias de avance , en los sprint de planificación, revisión y retrospectiva.

El Product Owner debe conocer la velocidad del equipo, para poder realizar las estimaciones de cuando estarán implementadas las necesidades en el producto.

En caso de que se requiera cancelar un Sprint por algún imprevisto externo, es el único responsable de  comunicar la cancelación.

El Product Owner es quien valida las entregas del equipo de desarrollo.

Es indiferente si el producto es una aplicación interna o un producto externo; el dueño del producto tiene la obligación de entregar el mayor valor posible, que incluye el foco en el desarrollo técnico.

scrum4

El Scrum master se encarga de que todo el equipo entienda scrum y lo aplique correctamente, es como un instructor, ayuda al equipo scrum y al resto de la organización a desarrollar la metodología dentro de la organización.  Implementar scrum es un proceso de cambio, el Scrum master apoya a todo el equipo en la adopción de la metodología

El ScrumMaster no tiene autoridad sobre el equipo de desarrollo, este rol no es similar al del jefe de proyecto de desarrollo. El ScrumMaster actúa como un líder, no como un jefe.

Las características más resaltantes del scrummaster:

1.Planifica la Implementación de scrum en conjunto con la organización

2.Ayuda al Product Owner que es quien tiene la visión del negocio a entender la agilidad.

3.Como instructor enseña al product owner a gestionar la planificación, elaboración del product backlog

4.Ayuda al equipo de desarrollo a convertirse en auto-organizado y multifuniocnal

5.Participa en las resuniones y se asegura que cumplan tiempo y objetivos establecidos.

6.Junto al equipo de desarrollo actualiza el progreso del trabajo

7.Promueve las buenas practicas de programación

8.Organiza y ejecuta cursos de aprender scrum si es necesario

scrum5

Equipo de desarrollo

Scrum define el rol de Equipo de Desarrollo, como una colección de diferentes actores, responsables de diseño, construcción o pruebas.

El equipo de desarrollo se debe auto organizar para presentar la mejor manera de cumplir con los requerimientos del usuario.

El equipo de desarrollo por lo general es de 5 a 9 personas; en forma colectiva tienen todas las habilidades necesarias para producir software de calidad.

Si el proyecto requiere de muchas más personas, digamos unas 35 personas, estas deben ser organizadas en equipos de desarrollo de máximo nueve personas.

scrum6

Los procesos de Scrum corresponden a todas aquellas actividades y al flujo de las mismas dentro de un proyecto Scrum.

En total la metodología desarrolla 19 procesos que se agrupan en 5 fases. Cada fases describe cada proceso en detalle, incluyendo sus entradas, herramientas y salidas asociadas. En cada proceso, algunas entradas, herramientas y salidas son obligatorias, y existen otras que son opcionales, cuyo uso dependerá de la naturaleza del proyecto.

Conozcamos un poco las fases y los procesos que incluyen cada una:

  1. Iniciación (6 procesos) 

En esta fase se crea la Visión del Proyecto que sirve de enfoque y dirección del mismo. Se crean e identifican roles claves del proyecto como el Scrum Master, Product Owner, interesados, equipo del proyecto. Así mismo, se define la lista de prioridades o el Product Backlog la cual sirve de base para la elaboración del plan de lanzamiento y tamaño de cada Sprit.

Procesos

Crear la visión del proyecto (Create Project Vision)

Identificar al Scrum Master y a los interesados o socios del proyecto (Identify Scrum Master and Stakeholder(s))

Formación del equipo Scrum (Form Equipo Scrum)

Desarrollo de épica(s) (Develop Epic(s))

Creación de la lista priorizada de pendientes del producto (Create Prioritized Product Backlog)

Realizar el plan de lanzamiento (Conduct Release Planning)

2. Planificación y Estimación (5 procesos):

Aquí se definen y aterrizan en los Sprints las historias de usuarios, se alinean a todo lo que genera valor a la organización y se hacen las estimaciones de tiempo y esfuerzo para cumplirlas, los cuales se traducen en listas de tareas cuyos tiempos de desarrollo se definen en reuniones de equipo correspondientes, así como el proceso de definición del Sprint Backlog que contiene todas las tareas que deben completarse en el Sprint.

Procesos

Elaborar historias de usuario (Create User Stories)

Aprobar, estimar y asignar historias de usuarios (Approve, Estimate, and Commit User Stories).

Elaboración de tareas (Create Tasks)

Estimar tareas (Estimate Tasks)

Elaboración de la lista de pendientes del Sprint (Create Sprint Backlog)

3. Implementación (3 procesos):

En esta fase se trabaja en las tareas del Sprint Backlog para crear Sprint Deliverables, para ello se utiliza a menudo un Scrumboard para realizar el seguimiento del trabajo y de actividades que se llevan a cabo. También,los inconvenientes o problemas que enfrenta el Equipo Scrum se actualizan en un Impediment Log. Durante esta fase se realizan las llamadas Daily Standup Meeting que son reuniones cortas y eficientes en tiempo donde el equipo da el estatus de sus actividades diarias y manifiesta cualquier inconveniente que pueda tener. Igualmente se actualiza o revisa la lista de prioridades de pendientes del producto.

Procesos

Crear entregables (Create Deliverables),

Llevar a cabo el standup diario (Conduct Daily Standup)

Mantenimiento de la lista priorizada de pendientes del producto (Groom Prioritized Product Backlog)

4. Revisión y Retrospectiva (3 procesos):

Para proyectos grandes que involucran varios equipos Scrum, se realiza en esta etapa, reuniones que permitan juntar a estos equipos y discutir y revisar avances, dependencias e impedimentos en el desarrollo del proyecto. También en esta etapa se lleva a cabo el proceso donde el Equipo Scrum le demuestra el Sprint Deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting. Igualmente, el Scrum Master y el Equipo Scrum se reúnen para discutir las lecciones aprendidas a lo largo del Sprint, información que se documenta como las lecciones aprendidas que pueden aplicarse a los futuros Sprints.

Procesos

Convocar Scrum de Scrums (Convene Scrum of Scrums)

Demostración y validación del Sprint (Demonstrate and Validate Sprint)

Retrospectiva de Sprint (Retrospect Sprint)

5. Lanzamiento (2 procesos):

Finalmente, esta es la fase más esperada por los interesados o socios del proyecto así como del Scrum Master y Equipo Scrum. En esta fase se presentan los entregables y se les entregan a los Socios relevantes. Un acuerdo formal llamado Aceptación de Entregables, documenta la finalización con éxito del Sprint. Del mismo modo, se realizan actividades de restrospectiva que permite identificar mejoras y lecciones aprendidas del proyecto.

Envío de entregables (Ship Deliverables)

Retrospectiva del proyecto (Retrospect Project)

scrum7

Con Scrum El desarrollo se realiza de forma iterativa e incremental. El corazón de Scrum es un Sprint, es un intervalo prefijado durante el cual se crea un incremento de producto “Hecho o Terminado” utilizable, potencialmente entregable. A lo largo del desarrollo hay Sprints consecutivos de duración constante

Cada iteración, denominada Sprint, tiene una duración preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versión del software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se añaden nuevas prestaciones priorizándose siempre aquellas que aporten mayor valor de negocio.

Veamos otros conceptos….

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no técnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversión considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.

Sprint Planning: Reunión durante la cual  el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reunión, decidir y organizar cómo lo va a conseguir.

Sprint: Iteración de duración prefijada durante la cual el equipo trabaja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versión del software totalmente operativo.

Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: Reunión diaria de cómo máximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el día anterior, que hará hoy y si hay impedimentos.

Demo y retrospectiva: Reunión que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una demonstración del producto. Posteriormente, en la retrospectiva, el equipo analiza qué se hizo bien, qué procesos serían mejorables y discute acerca de cómo perfeccionarlos.

¿Que debe contemplar una Plan de Tecnología para su empresa?

Todo departamento de Tecnología es una unidad de servicio cuyo objetivo es garantizar soporte de operaciones financieras, operativas y de información del negocio.  Bajo esta condición es importante tomar en cuenta:

  1. Metas de la Organización. El negocio debe presentar en resumen la estrategia compuesta por su visión (motores de alcance que se quiere ser y hacer); su misión (Motores de ejecución quien soy y que hago) y los valores de la Organización.
  2. Influencia del ambiente externo, por ejemplo, industria, gobierno, organismos reguladores y supervisores, clientes, proveedores, etc. Cómo afecta cada uno de esos ambientes en sí mismos, o sus disposiciones, regulaciones, normas y directrices.
  3. Limitaciones y restricciones organizacionales, por ejemplo, la filosofía administrativa (estilo), la gestión individual y la manera de tomar decisiones.
  4. Supuestos sobre riesgos de los negocios y consecuencias potenciales. Debe partir de un análisis de riesgos de cada una de las áreas, en especial las que se considere como críticas en la actividad del negocio.

Si tenemos claros los 4 puntos expuestos en las líneas anteriores, comenzamos a evaluar las metas y objetivos globales de la Unidad de Tecnología dividido en dos grandes áreas: Infraestructura (Redes, Telecom, Servidores, Soporte Técnico) y Sistemas (ERP, CRM, BI, etc).

Cada área debe contar con una descripción  de perfil y como contribuye  en el proceso productivo y financiero del negocio,  en la toma de decisiones en los diferentes  niveles jerárquicos, así como su aporte en los controles sobre los procesos operacionales y financieros.

Es importante presentar un Análisis FODA (Fortalezas, Oportunidades, Debilidades, Amenazas) de todas las áreas y aspectos que afecten la Tecnología de Información.

De igual forma se deben considerar las capacidades actuales que comprende  clasificar e identificar el estado actual de todos los equipos,  sistemas y recursos humanos del área y según las necesidades actuales y futuras de la organización en cuanto a mejoras de procesos, comunicaciones, controles cuales deben ser nuestras capacidades futuras.

Recaudada toda la información requerida se presenta un Plan de TI con:

  1. Roadmap de inversión en implementaciones en equipos, comunicaciones, licenciamiento, sistemas y personal
  2. Resumen de análisis de inversiones, donde cada proyecto u inversión debe reflejar fecha de ejecución, responsables, monto.

Es importante resaltar predicciones que afectan el plan  Tecnología actual y futura: se refiere al estudio de la tecnología que exista en el momento de redactar el plan, así como las perspectivas de la misma en el mediano y largo plazo; su consideración es de suma relevancia, debido a que los planes de las diferentes áreas, se verán afectados por este elemento.

Los planes de TI deben contar con la evaluación y aprobación de la Dirección General del Negocio además deben existir políticas, estándares y procedimientos de respaldo y la organización en general debe preocuparse por darle mantenimiento de forma periódica.

Finalmente   un buen plan de TI debe estar orientado hacia el logro de los siguientes objetivos:

  • Evitar la duplicación de sistemas de aplicación.
  • Fomentar el trabajo conjunto de todas las áreas de negocio y servicio de la organización para No generar “islas” de información
  • Basar los proyectos en estudios de factibilidad.
  • Integrar los proyectos de Tecnología de Información con los planes generales de la organización.
  • Asegurar un desarrollo evolutivo del área de TI para el apoyo del Negocio
  • Conocer si las áreas usuarias requieren de la tecnología y si los elementos solicitados se utilizan de manera económica y razonable.

 

Herramientas de Inteligencia de Negocios #BI #InteligenciadeNegocios

Uno de los retos actuales para los directivos y gerentes de las compañías es darle buen uso a los grandes volumenes de información que a diario se están generando en los sistemas transaccionales que soportan los procesos del negocio.

Esto nos lleva a buscar estrategias y soluciones para convertir todos estos datos en información que apoye a la toma de decisiones para lograr incrementar su ventaja competitiva y su diferenciación en el mercado

Lo primero que nos preguntan a los lideres de TI es que herramientas utilizar para implementar una estrategia de inteligencia de negocio en la organización. Existen muchas herramientas en el mercado, les invito a visitar las 20 herramientas de inteligencia de negocios que debes conocer

Ahora bien, la situación económica de un país afecta las posibilidades de inversión en un negocio, este es un reto mayor para quienes laboramos como es en mi caso en Venezuela.  Me parece interesante  compartir mi experiencia laboral en la implementación de Dashboard, reportes de indicadores, cubos de datos con la herramienta OpenBizview, que entre sus características se encuentra:

  • Software libre
  • Acceso Web
  • Generador de reportes BIRT
  • Cubo de datos
  • Desarrollado en Java (Multiplataforma)
  • Envio de informes por correo
  • Conexion a multiples bases de datos
  • Pistas de auditoría
  • Manejo de roles y permisologia de acceso
  • Dashboard
  • Sin costo de licenciamiento

Les invito a visitar la pagina,  OpenBizview

Inteligencia de Negocios #InteligenciaNegocio #BI

En la actualidad las organizaciones cuentan con sistemas de información que soportan gran parte de las actividades diarias propias del sector de negocios en donde se esté desempeñando, este sistema puede ser sencillo o robusto todo depende de las exigencias del negocio, con el transcurso del tiempo estas aplicaciones llegan a tener la historia de la organización, los datos almacenados en las bases de datos, pueden ser utilizados para argumentar la decisión que se quiera tomar.

Gartner Group publicó (http://www.gartner.com/technology/home.jsp) que la información en las organizaciones está aumentando rápidamente, así como, las decisiones críticas del negocio; el problema es la actitud de las empresas para utilizar estos datos.

Sin lugar a dudas, la información es el activo más valioso de las empresas, el problema es cada área funcional maneja sus propias fuentes de datos, lo que genera necesidad de integración de todos los sistemas de información de una compañía.  No solo para procesar esa información eficientemente, sino también para crear inteligencia empresarial que sirva para todas las actividades.

Necesitamos entender no solo que está pasando, sino cuando, donde, quien y porque.  Queremos oportunidad en la evaluación de la información y es vital escalar, contribuir y compartir con los diversos usuarios de la organización de los indicadores que mueven a la organización; esto debido a que en la actualidad para las organizaciones explotar los datos y la información existente con la finalidad de convertirla en conocimiento es de vital apoyo para la toma de decisiones sobre el negocio

La utilización de la información para generar conocimiento, produce mejoras en los procesos de negocios y guían a las organizaciones a tener operaciones mucho más efectivas y en algunos casos optimizadas.  Esto se logra ya que el acceso e interpretación de la información es un elemento diferenciador, productivo y rentable para las organizaciones

El diseño de sistemas de información que procesen esa información de forma inteligente y aporten conocimiento a la empresa es el objetivo de la Inteligencia de Negocio BI (Business Intelligence) es una herramienta bajo la cual diferentes tipos de organizaciones, pueden soportar la toma de decisiones  basadas en información precisa y oportuna; garantizando la generación del conocimiento necesario que permita escoger la alternativa que sea más conveniente para el éxito de la empresa.

Ahora bien, ¿cómo saber si la organización está preparada para implementar inteligencia de negocios como herramienta de estrategia gerencial?; la respuesta es sencilla la compañía debe tener cultura de uso de indicadores.  Es muy común leer que si no se mide lo que se hace, no se puede controlar y si no se puede controlar, no se puede dirigir y si no se puede dirigir no se puede mejorar.  Para que una compañía este en constante mejora de procesos y efectividad de operaciones debe tener indicadores vitales que muestren el estado del negocio.

Para que un indicador de gestión sea útil y efectivo, tiene que cumplir con una serie de características, entre las que destacan: Relevante (que tenga que ver con los objetivos estratégicos de la organización), Claramente Definido (que asegure su correcta recopilación y justa comparación), Fácil de Comprender y Usar, Comparable (se pueda comparar sus valores entre organizaciones, y en la misma organización a lo largo del tiempo), Verificable y Costo-Efectivo (que no haya que incurrir en costos excesivos para obtenerlo).

La selección de los indicadores y la herramienta más adecuada para implementar Inteligencia de Negocios en una organización son los aspectos vitales para que un proyecto de este tipo sea exitoso.  Esta selección debe estar en función de multiples aspectos a considerar, tales como:

  1. Que información se necesita. Es importante no complicarse, sobre todo en un inicio con indicadores y modelos complejos. Los indicadores selectivos, sencillos, admitidos por todos los usuarios, etc. son una buena fórmula en las primeras etapas de la BI
  2. Para que se quiere la información. Bajo el concepto general “apoyo a la toma de decisiones” se esconden multiples necesidades particulares tales como constrastar que todo va bien, analizar diferentes aspectos de la evolución de la compañía, presentar información de manera más intuitiva, comparar información en diferentes períodos, comparar resultados con previsiones, identificar comportamientos y evaluaiones execpcionales, confirmar o descubrir tendencias e interrelaciones, entre otras
  3. A quien va dirigido. La organización en general, gestión, dirección estratégica, son algunas de las áreas finales donde se debe dirigir el desarrollo de BI
  4. Aspectos Técnicos: Son importantes también los tiempos de respuesta, la integración, seguridad, aspectos funcionales tales como navegación, entorno gráfico y el esquema de funcionamiento de las herramientas.

Fase III.  Medidas preventivas Plan de Continuidad de Negocio

El propósito de esta fase consiste en aplicar medidas de seguridad que eviten en la medida de lo posible que se produzcan incidentes de seguridad que, al no ser gestionados adecuadamente, hagan necesaria la activación del plan de continuidad de negocio.

Tareas

1. Identificación y Aplicación de Medidas de Seguridad

Tomando como base los resultados del BIA y del análisis de riesgos, la organización debe identificar y aplicar controles o medidas de seguridad que:

  • Reduzcan la probabilidad de que las actividades críticas sufran interrupciones.
  • Disminuyan el tiempo de una eventual interrupción.
  • Limiten el impacto que una paralización de las actividades críticas pueda provocar en la organización.
  • Incrementen la fortaleza del negocio mediante la eliminación de puntos de fallo únicos (accesos, procesos, clientes, etc.)

De esta forma se elabora un plan de acción que contempla las acciones que la compañía pretende adoptar para prevenir y evitar en la medida de lo posible los riesgos que impactan en la disponibilidad de las operaciones. El hecho de abordar estas acciones de implantación de medidas de seguridad preventivas puede llegar a convertirse en un ahorro de costes al disminuir la posibilidad de tener que enfrentarse a males mayores que supondrían un gasto extra.

2. Riesgos Asociados al establecimiento de Medidas Preventivas

No todos los riesgos tienen la misma criticidad ni todas las medidas de seguridad el mismo coste de implantación ni redundan en los mismos beneficios para la organización. En este sentido, cabe la posibilidad de que la organización adopte un modelo de gestión ambicioso al abordar la implantación de medidas de seguridad costosas de aplicar, engorrosas de mantener y que hacen frente a riesgos que no son críticos.

Adicionalmente la selección de medidas de seguridad inadecuadas que no atajan debidamente los riesgos a los que está expuesta la organización puede conllevar un gasto económico inútil que no contribuye al desarrollo de la estrategia de continuidad.

Recomendaciones

El proceso de identificar e implantar medidas de seguridad debe estar basado en un equilibrio entre los siguientes factores:

  • Riesgo que está siendo mitigado o impacto que estaría siendo reducido.
  • Costo de implantar la/s medida/s de seguridad (económico y humano).
  • Beneficios que la implantación de la/s medida/s de seguridad aporta a la empresa.

Por tanto, en vez de esperar a que un desastre golpee a la organización para ver cómo esta se recupera, las medidas preventivas (en ocasiones denominadas contramedidas) deben ser aplicadas con el objetivo de incrementar la fortaleza de sus actividades frente a posibles impactos previamente identificados en el BIA.Algunos ejemplos de medidas preventivas son:

  • Empleo de materiales de construcción robustos.
  • Redundancia de sistemas informáticos y líneas de comunicación.
  • Adquisición de seguros con diferentes grados de cobertura.
  • Copias de seguridad de información que soporta una actividad crítica de la organización.
  • Sistemas de detección y extinción de incendios.
  • Sistemas de prevención de intrusiones y control de accesos.
  • Sistemas de alarma y vigilancia.