Capítulo 3 - Gestión de Proyectos de Inteligencia de Negocio

1. Introducción a la gestión de Proyectos de BI

La gestión de un proyecto BI posee los lineamientos generales de un proyecto normal de tecnología, pero con ciertas particularidades que debemos tener en cuenta.

Cuando escuchamos el término Gestión de Proyectos lo asociamos a un cronograma (o el famoso Project hecho con la herramienta de Microsoft), sin embargo, el Plan de Proyecto es la guía principal que definirá de qué manera será ejecutado, monitoreado, controlado y cerrado el proyecto, y está conformado principalmente por los Planes Subsidiarios, el Sistema de Administración de la Configuración, el Sistema del Control Integrado de Cambios y la Metodología de Administración de Proyectos Adaptada.

Dentro de los planes subsidiarios a considerar podemos encontrar los siguientes:

1. Plan de Administración del Alcance
2. Plan de Administración de Costos
3. Plan de Mejora de Procesos de Project Management
4. Plan de Comunicaciones
5. Plan de Adquisiciones
6. Plan de Administración del Cronograma
7. Plan de Administración de la Calidad
8. Plan de Administración de Recursos Humanos
9. Plan de Administración de Riesgos

1.1 El Plan de Administración del Alcance

El objetivo del Plan de Administración del Alcance es definir cómo será gestionado el alcance del proyecto y cómo se implementarán los cambios (identificación, gestión e implementación de cambios).

Secciones:

1. Planteamiento General

Se debe especificar: ¿Cómo se controlarán los cambios? ¿De qué manera se utilizará el Sistema del Control Integrado de Cambios? ¿Quiénes conformarán el Comité de Control de Cambios?

2. Estabilidad

Se debe especificar: ¿Qué tanto puede cambiar el alcance original del proyecto? ¿Podría haber muchos cambios? ¿Qué tan grandes podrían ser esos cambios?

3. Control de Cambios

Se debe realizar una identificación y clasificación de cambios estableciendo algún criterio para esta clasificación. Por ejemplo, los cambios pueden clasificarse de acuerdo a su severidad e impacto.

Por cada Solicitud de Cambio se debe llenar el formato correspondiente de Control de Cambios, y el comité de Control de Cambios debe firmar su aceptación, o su rechazo.

1.2 El Plan de Administración de Costos

El objetivo del Plan de Administración de Costos es definir cómo serán gestionados los costos del proyecto, es decir cómo se medirán, reportarán y controlarán los costos a lo largo de todo el ciclo de vida del proyecto.

Secciones

1. Planteamiento General

Se debe especificar: ¿Se utilizará un Sistema de Información para la Gestión del Proyecto? ¿A qué nivel del WBS (Work Breakdown Structure) se manejarán los costos? ¿Qué métricas aplicarán para monitorear las variaciones de costos, y en qué momento se dispararían las alertas? Se recomienda que sea al nivel de Paquete de Trabajo, y a ese mismo nivel se definan Cuentas de Control de costos, y se calcule el Valor Ganado (Earn Value – EA).

2. Medición de los Costos del Proyecto

Se debe especificar cómo se medirán los costos del proyecto, qué herramienta de medición se utilizará, el PMI (Project Management Institute) recomienda ampliamente utilizar la Gestión del Valor Ganado (Earn Value Management). También se debe especificar si se utilizará algún software para tal efecto, cómo se estimarán los costos futuros, y cómo se realizará la revisión del desempeño del costo (respecto al tiempo, paquetes de trabajo, etc.)

3. Comunicación

Se debe especificar de qué manera se reportarán las variables resultantes del cálculo del Valor Ganado, y, derivado de ello, una propuesta de acciones correctivas para aquellas variables que así lo ameriten, con su respectivo control de cambios.

4. Plan de acción para Varianza de Costos

Aquí se deben especificar los umbrales de control para los costos del proyecto. Se debe acordar con el patrocinador del proyecto qué opciones correctivas factibles se tienen en caso de que alguna variable económica del proyecto salga de los límites establecidos.

5. Lineamientos para realizar el Control de Cambios en Costos

Se debe detallar si hay especificaciones particulares para realizar un Control de Cambios derivado de una desviación en los costos autorizados inicialmente. De lo contrario, se seguirá el proceso normal de Control de Cambios del proyecto.

6. Resumen del presupuesto

Se debe describir el monto del presupuesto autorizado para el proyecto detallado por rubros.

1.3 El Plan de Mejora de Procesos

El objetivo del Plan de Mejora de Procesos es seleccionar y analizar procesos de trabajo del proyecto que puedan ser mejorados.

Secciones

1. Planteamiento general

Se debe describir la manera en que se mejorará dicho proceso, qué técnicas, herramientas y conocimientos se emplearán.

2. Descripción del proceso

Una explicación clara y completa del proceso a mejorar con sus entradas, actividades y salidas, el responsable del proceso, y todos los involucrados en su ejecución.

3. Definición de métricas del proceso actual.

Una definición de las métricas del proceso, cómo se encuentra actualmente en todas las unidades necesarias: tiempo, número de personas involucradas, número de errores, etc.

4. Objetivos de mejora del proceso.

Una descripción de las partes a mejorar del proceso y de los objetivos a cumplir de cada métrica en un tiempo determinado.

1.4 El Plan de Gestión de Comunicaciones

El objetivo del Plan de Gestión de Comunicaciones es establecer los requerimientos de comunicación de los Stakeholders del proyecto y cómo será distribuida la información.

Secciones

1. Planteamiento general

Una explicación clara de cómo se realizará efectivamente la comunicación formal e informal que el proyecto requiere.

2. Roles

Se debe definir una matriz para con todos los roles considerados en el proyecto, desde el Patrocinador, el Gerente de Proyecto, el Líder de Proyecto, Clientes, etc.

3. Directorio

Una vez realizada la lista de Roles, se debe incluir a todos los Stakeholders dentro de su rol o roles, con sus datos de contacto físicos y electrónicos para establecer comunicación.

4. Matriz de comunicación

Se debe identificar los tipos de comunicación requeridos para el proyecto, por ejemplo: Juntas de Revisión Semanales, Reuniones de trabajo internas, Informe mensual de avances, etc., agregando el objetivo de cada tipo de comunicación, el medio, la frecuencia de su realización, la audiencia (roles a quien va dirigido), el dueño u organizador, y el entregable que se presentará o enviará, así como el resultado esperado de esa reunión (acuerdos, minutas, contratos firmados, etc.).

5. Lineamientos para juntas

Se debe especificar todas las pautas que se seguirán para la realización de las juntas, como el período en el que deben enviarse las agendas de las reuniones, las minutas resultantes, el registro las acciones por realizar, quién coordinará las reuniones, quien tomará las notas, etc.

1.5 El Plan de Gestión de Adquisiciones

El objetivo del Plan de Gestión de Adquisiciones es establecer los requerimientos de aprovisionamiento para el proyecto y cómo serán gestionados hasta el cierre de los contratos.

Secciones

1. Planteamiento General

Se debe definir claramente los pasos necesarios para gestionar las adquisiciones de principio a fin, así como las responsabilidades de todos los roles involucrados en estos procesos.

2. Definición de las Adquisiciones

Se debe especificar qué productos o servicios serán adquiridos, con qué características y con qué restricciones. También debe especificarse la lista de personas con autoridad para aprobar las compras.

3. Tipos de contratos que se usarán en el proyecto

Se debe especificar el tipo de contrato se puede aceptar para cada tipo de producto o servicio requerido por el proyecto.

Los tipos de contrato pueden ser los siguientes:

• Precio Fijo
• Tiempo y Materiales
• Gastos más porcentaje por honorarios
• Costos más honorarios fijos
• Precio máximo garantizado
• Precio objetivo

4. Proceso de aprobación de contratos

Se debe definir el proceso que se seguirá para aprobar a los proveedores. Independientemente de que tan largo o simple, formal o informal pueda ser, deben quedar perfectamente claras las etapas, entregables, funciones, responsables y tiempos del proceso.

5. Criterios de decisión

Se debe especificar cuál es el criterio que el Comité de Adquisiciones utilizará para definir al ganador del contrato. Y si hubiera más de un criterio, deberá especificarse el orden de prioridad entre ellos, y su ponderación.

6. Roles y Responsabilidades

Se deben definir los roles y responsabilidades de todos los involucrados en el proceso de adquisiciones para asegurar que los proveedores cumplan con los niveles de calidad de los productos y servicios contratados.

7. Gestión de Proveedores

El líder de proyecto será el encargado de coordinar las actividades para revisar el desempeño de los proveedores, de acuerdo a las métricas pre-definidas para tal efecto. Por lo que es necesario la inclusión de Acuerdos de Niveles de Servicio (SLA – Service Level Agreements) en los contratos.

1.6 El Plan de Gestión del Cronograma

El objetivo del Plan de Gestión del Cronograma es establecer los lineamientos para garantizar que el proyecto se cumplirá exitosamente con las restricciones de tiempo existentes.

Secciones

1. Planteamiento General

Se debe definir un marco de trabajo para la creación del cronograma, la utilización de un software para la gestión del cronograma, los hitos (milestones) del proyecto, y los roles y responsabilidades de las personas involucradas.

2. Control del Cronograma

Se debe definir cómo se controlará el programa a lo largo del ciclo de vida del proyecto, los roles y responsabilidades de las personas involucradas, y la frecuencia con que se revisará, comunicará y actualizará el cronograma y su progreso.

3. Cambios en el Cronograma y Umbrales permitidos

Se deben definir los límites permitidos del cronograma bajo los cuales puede realizarse el proyecto. Cualquier evento que pueda cambiar un cambio en el cronograma debe cumplir con un proceso de control de cambios que el patrocinador debe autorizar antes de que el cambio al cronograma se realice.

4. Cambios en el Alcance

Generalmente, cuando se autoriza un cambio en el alcance del proyecto, debe efectuarse un cambio en el cronograma para incluir los entregables que no habían sido considerados originalmente, lo que originará una solicitud de cambio en el cronograma, que deberá autorizarse para poder generar una nueva línea base del cronograma.

1.7 El Plan de Administración de la Calidad

El objetivo del Plan de Gestión de la Calidad es establecer los lineamientos para medir la calidad de los procesos y garantizar que se cumpla con las restricciones de calidad del proyecto.

Secciones

1. Planteamiento General

Se debe describir a detalle los procesos de Aseguramiento de Calidad (QA – Quality Assurence) que se utilizarán y cuándo se utilizarán. Para cada punto de control deberá especificarse un resumen de quiénes están involucrados, el criterio de evaluación y quiénes revisarán y autorizarán los resultados.

2. Roles y Responsabilidades

Se debe especificar quiénes formarán parte del equipo de QA, sus responsabilidades, y los conocimientos y habilidades requeridas para realizar dichas actividades.

3. Revisiones

Se deben especificar qué metodologías, estándares, evaluaciones y revisiones se utilizarán para verificar la calidad así como los criterios de éxito aplicables.

4. Hitos para el Aseguramiento de Calidad

Se deben especificar los entregables resultantes de la Gestión de Calidad y el tiempo de entrega correspondiente.

5. Recursos estimados

Se deben especificar los costos asociados estimados para el control posterior.

1.8 El Plan de Administración de Recursos Humanos

El objetivo del Plan de Administración de Recursos Humanos es garantizar el éxito del proyecto mediante la correcta adquisición de recursos humanos con los conocimientos y experiencia necesaria, y con la disponibilidad en el tiempo que son requeridos.

Secciones

1. Planteamiento General

Resumen la relación de personal necesario para la ejecución del proyecto, contemplando un análisis de perfiles y descripción de puestos de trabajo, la definición de sus competencias, carga laboral y posición dentro del organigrama de la empresa.

2. Roles y responsabilidades

Se debe especificar quiénes formarán parte del equipo de trabajo, además del resto de los stakeholders, sus responsabilidades, y los conocimientos y habilidades requeridas para realizar dichas actividades, así como la cantidad de posiciones requeridas para cada rol.

3. Organigrama del proyecto

Basado en los roles del punto anterior, se debe crear un organigrama donde se muestre una relación de jerarquía entre los miembros del equipo. Adicionalmente, se debe crear una matriz RACI donde se muestre la relación entre los miembros del equipo y las tareas a realizar. Las relaciones pueden ser:

• R – Responsable de realizar la tarea
• A – Aprueba el trabajo realizado
• C – Consultado antes de realizarse cualquier decisión
• I – Informado cuando una acción se realiza o una decisión ha sido tomada.

4. Gestión del personal

Se debe especificar el origen de todo el personal requerido para el desarrollo del proyecto, quiénes serán necesitados, cuándo serán necesitados y liberados del proyecto, qué capacitación recibirán, cómo será evaluado e informado su desempeño, qué sistema de reconocimientos será utilizado.

1.9 El Plan de Administración de Riesgos

El objetivo del Plan de Administración de Riesgos es definir la manera en que se identificarán, analizarán, revisarán y controlarán los riesgos del proyecto.

Secciones

1. Planteamiento General

Resumen del alcance de riesgos que permitirá mitigar y conocer las acciones a tomar en caso los riesgos suceda.

2. Roles y responsabilidades

Se debe especificar quiénes formarán parte del equipo de gestión de riesgos, sus responsabilidades, y los conocimientos y habilidades requeridas para realizar dichas actividades. Entre los roles pueden definirse: Administrador de Riesgos (de todos los riesgos del proyecto), y Responsable de Riesgo (responsable de evaluar la probabilidad de ocurrencia de un riesgo, y de comunicarlo al Administrador de Riesgos. Posteriormente, será responsable de ejecutar el plan de mitigación e informar los resultados).

3. Documentación de riesgos

Se deben listar todos los riesgos en la medida en que se van identificando a lo largo del proyecto, con un Identificador, Descripción, Clasificación, Probabilidad de ocurrencia, Grado de impacto, Plan de mitigación, Responsable, Fecha límite para la mitigación, Estatus actual, Plan de contingencia, y el Criterio que debe cumplir para considerarse un riesgo cerrado.

4. Actividades

Se deben especificar las tareas a realizar para gestionar los riesgos del proyecto, así como los participantes. Los principales grupos de tareas son las siguientes:

•  Identificación de riesgos
•  Análisis Cualitativo de riesgos
•  Análisis Cuantitativo de riesgos
•  Priorización de riesgos
•  Planeación de la respuesta a riesgos
•  Monitoreo de riesgos
•  Ejecución de planes de mitigación
•  Registro de lecciones aprendidas

5. Cronograma para las actividades de gestión de riesgos

Se debe especificar en qué fechas se realizarán las actividades principales de la gestión de riesgos (aquellas que puedan planearse).

6. Presupuesto para la gestión de riesgos

Describir el presupuesto autorizado para la gestión de riesgos.

7. Herramientas para la gestión de riesgos

Describir todas las herramientas que se utilizarán en cada actividad de la gestión de riesgos.

1.10 El Sistema de Administración de la Configuración

Es una colección de procedimientos formales documentados utilizados para aplicar la dirección técnica, administrativa y de vigilancia para identificar y documentar las características funcionales y físicas de un producto, resultado, servicio o componente, controlar cualquier cambio en sus características, registrar y reportar cada cambio y su estado de implementación, y apoyará la auditoría de los productos, resultados o componentes para verificar la conformidad de los requisitos.

Incluye la documentación, sistemas de seguimiento, y los niveles de aprobación definidos necesarios para autorizar y controlar los cambios..

Es decir, el objetivo del Sistema de Administración de la Configuración es mantener al final de cada etapa una versión válida y estable del producto y de los elementos que lo conforman.

Por ejemplo, en un proyecto de BI pudiéramos tener los siguientes sub-productos:

• Modelo Relacional
• Procesos ETL
• Modelo Multi-dimensional
• Cubos
• Dimensiones
• Reglas de negocio o Fórmulas
• Cuadro de Mando

Al terminar un producto, o subproducto, este tiene asignado un número de versión.

Digamos que en una primera etapa tenemos las siguientes versiones:

• La versión 1 del cubo de Ventas: Ventas_v1.0
• Dimensiones:
• Empleados: Empleados_v1.0
• Productos: Productos_v1.0
• …
• Almacenes: Almacenes_v1.0
• Reglas de Negocio
• Indicadores de ventas: IndVtas_v1.0
• …
• Indicadores de desempeño: IndDes_v1.0

En este momento podemos decir que tenemos la versión 1.0 del Modelo Multidimensional: MultiDim_v1.0. Esta es una Línea Base del Modelo Multi-dimensional, que considera todos sus sub-productos.

Si fuera necesaria una mejora o corrección a cualquiera de los sub-productos, o si fuera necesaria la inclusión de un nuevo sub-producto, el Sistema de Administración de la Configuración deberá autorizar, registrar, controlar y reportar cada cambio y su situación final, de tal manera que dé origen a una nueva Línea Base del producto en cuestión, es decir, una nueva versión.

Por ejemplo, si la dimensión Productos cambiara su estructura, y diera origen a la dimensión Productos_v1.1, la Línea Base del modelo Multi-dimensional cambiaría, y daría origen al Modelo Multi-dimensional_v1.1, por ejemplo. Incluso, si el resto de los sub-productos se mantienen sin cambio.

1.11 El Sistema de Control Integrado de Cambios

El Sistema de Control Integrado de Cambios es la herramienta que permitirá gestionar todas las solicitudes de cambio y nos permitirá asegurar que se realizarán de manera consciente, analizada, controlada y finalmente autorizada por el responsable. Este sistema comprende todas las fases desde la recepción de la solicitud de cambio, su priorización, análisis costo/beneficio y de posibles impactos a otros sistemas o procesos, y finalmente, la decisión de profundizar el análisis, implementar, aplazar o cancelar el cambio.

El sistema también debe gestionar qué se debe hacer, cuándo se hará y quién lo hará, a través del diseño, desarrollo, pruebas e implementación del cambio, manteniendo la integridad de las líneas base de medición del desempeño y coordinando el cambio a través de todas las áreas de conocimiento.

1.12 Metodología de Administración de Proyectos Adaptada

La Metodología de Administración de Proyectos Adaptada permite especificar cuáles de todos los procesos definidos en el PMBOK serán utilizados para nuestro proyecto particular. Es importante mencionar que si vamos a prescindir de un proceso, no se debe simplemente omitir de la metodología, sino que debe listarse el proceso y mencionarse el por qué no se utilizará para el proyecto.

2. Tu empresa está preparada para un proyecto de BI

Business Intelligence se ha convertido en la palabra de “moda” en el mundo de los negocios, estrategias y tecnología. Una tendencia que la mayoría de los proveedores, líderes de tecnología, están desarrollando.

Este concepto es entendido como la utilización, manipulación y aprovechamiento de grandes volúmenes de información estructurada y no estructurada, para entender el valor de la información que tiene y maneja una empresa y convertirla en una ventaja competitiva. Sin embargo, ¿está su empresa preparada para adoptar y aprovechar las ventajas de esta tendencia?

Inicialmente, determine si su organización maneja fuentes de datos diferentes a las tradicionales. Esta se denomina información no estructurada y, por ejemplo, podría originarse en redes sociales para empresas de consumo masivo o en sensores de las máquinas en industrias.

En el caso de las redes sociales con el manejo adecuado más la incorporación de otras fuentes de información estructurada, se pueden tomar decisiones para medir los efectos de una campaña de publicidad e identificar los patrones de comportamiento de los clientes, algo que un humano no podría recolectar y analizar, pero que se puede lograr con una plataforma adecuada de inteligencia de negocios.

El resultado final debe verse representando en desarrollar una acción específica de negocio: Comprar, vender, realizar una actividad de comunicación o de mercadeo, entre otras. Ahora bien, si su empresa solo maneja información de fuentes tradicionales, como bases de datos relacionales, y no tiene o no está interesado en manejar fuentes de información no estructurada, también existen en el mercado varias técnicas de inteligencia de negocio lo suficientemente maduras que las empresas pueden adoptar, para manejar, entender y aprovechar esta información.

2.1 ¿Qué debe tener en cuenta para acercarse a “Business Intelligence”?

1. Educarse para entender a fondo en qué consiste esta tendencia, qué beneficios podría tener en la organización y qué esperar de los resultados.
2. Acompañarse de alguna firma consultora seria y experta en el tema de inteligencia de negocios, para revisar si la promesa de ‘Business Intelligence’ aplica para su empresa.
3. Antes de planear la adquisición de sistemas especializados, desarrollar el caso de negocio, identificando si los requerimientos de negocio se pueden solucionar con ‘Business Intelligence’ y el impacto que tendría sobre el negocio. Además de la justificación de la inversión en recursos de tiempo y personal para dedicarlos a este proyecto, con la plataforma tecnológica adecuada.
4. Identificar si la empresa tiene el grado de madurez en el ambiente de análisis de información para adoptar técnicas más sofisticadas.

Consejos básicos para entrar en el tema de Business Intelligence:

• Estar dispuesto a experimentar y desarrollar una inversión de tiempo y de personal.
• Los proyectos de Business Intelligence se pueden comparar con los proyectos de explotación petrolera, en los que se hace una inversión importante de recursos buscando en millares de hectáreas de terreno el petróleo. Cuando este se encuentra, la ganancia es total y se multiplica el valor de la inversión.
• En el mundo, también hay empresas que han desarrollado este tema y fueron pioneras en el mercado
• Vale la pena hacer el ejercicio de analizar si su empresa está lista para el Business Intelligence, y lanzarse a la búsqueda de hallazgos, pues puede encontrar información muy valiosa que puede convertirse en la mejor ventaja competitiva de su negocio en el mercado

3. Negocio vs Tecnología

Business intelligence (BI) es el resultado de aprovechar, mediante la inteligencia humana, las capacidades de la tecnología para el beneficio de la empresa. No es un software mágico que resuelve problemas por sí solo, tampoco una computadora que sustituye a la dirección general. Gracias al BI los equipos de trabajo responden a la creciente necesidad de sus empresas por ‘hacer más con menos’, o en otras palabras, por lograr la eficiencia, que su máxima expresión, se traduce en excelencia.

Pero, aprovechar esta sinergia entre Negocio y Tecnología implica medir y analizar todos los procesos de la empresa porque mejorar resulta más difícil cuando se carece de métricas.

Medir los procesos aporta valiosos datos a directores y gerentes para fijar objetivos y metas financieras, de calidad, de producción, de operaciones y de todas las áreas de trabajo. Al final, el fruto de la medición de procesos, del análisis de datos y del trazado de metas se expresa en el plan estratégico de crecimiento, la brújula que guía a la empresa y a todos sus departamentos.

Las soluciones de BI son muy variadas, existen algunas enfocadas en mejorar la comunicación entre empleados, por ejemplo, a través de sistemas de e-mail, chat o videoconferencias. Otras, como en el caso de los servicios médicos, se centran en facilitar el acceso a información relevante.

Las posibilidades de aplicar BI a los procesos de trabajo no tienen límite y en muchos casos el cliente es quien debe explicar al proveedor de servicios tecnológicos sus necesidades particulares y, con base en ellas encontrar o incluso desarrollar una solución ad hoc.

“Medir la temperatura a los procesos detrás de toneladas de información, tener información a la mano y en cualquier momento, redes sociales que ayuden a tomar decisiones, son los desafíos de las empresas hoy en día”. Para el Negocio, el BI tiene tres retos principales a corto y medio plazo, y estos son los siguientes:

1. El procesamiento de grandes volúmenes de información
2. Tener información a la mano y en cualquier momento
3. Las redes sociales

Los expertos señalan que para poder enfrentar esos desafíos es necesario presentar a los clientes soluciones accesibles, que los empleados puedan manejar con facilidad desde cualquier gadget 24/7. Para ello es importante, también, contar con una seguridad y protección de la información sensible que las empresas guarden sobre sus clientes, proveedores y otros colaboradores.

Además, señalan que las redes sociales deben ser explotadas para extraer de ellas información realmente valiosa. Muchas veces, una simple plática por chat entre dos empleados puede ayudar a los demás a resolver problemas y ser más eficientes. La posibilidad de que la dirección general reciba feedback de todos y cada uno de los empleados, sin importar su nivel jerárquico, es solo otro ejemplo de lo que se puede conseguir con una red social interna de empresa. En los últimos años, varios casos de éxito empresarial han surgido, precisamente, de la adopción de redes sociales empresariales.

4. Riesgos de los proyectos de BI

4.1 Desconocimientos de las capacidades del BI

La toma de decisiones en las empresas, se realiza basándose en información, es por eso, que en muchos casos el desconocimiento de la tecnología emergente, cómo actúa esta sobre la información, sus implicaciones, sus riesgos, y sus costos entre otros, hacen dudar al dueño de la información en implementar o no las soluciones que le ofrece la nueva tecnología a pesar de las grandes ventajas que promete brindar.

En el caso de sistemas inteligentes y particularizando en inteligencia de negocio (BI), existe un enorme desconocimiento en el área, aún entre las personas que trabajan en TI. Los usuarios finales no se encuentran familiarizados con la terminología, las herramientas, las técnicas, y algoritmos alrededor de BI, y no solamente los usuarios finales, la TI el día de hoy es tan grande y especializada que muchas veces técnicos en TI, o telecomunicaciones, desarrolladores, etc. desconocen también el ambiente de BI.

En otros campos de TI, no pasa lo mismo, en las empresas es común hablar de sistemas contables, ERP, CRM, etc., pero no es común hablar de sistemas inteligentes o sistemas que apliquen técnicas o herramientas inteligentes para brindar soluciones.

Los sistemas inteligentes no son nuevos, las técnicas de procesamiento de lenguaje natural empleadas ahora tan comúnmente, datan de los años 50’s, no fue hasta que las técnicas de búsqueda con modelos como el SML (Statistical Models Lenguajes) se profundizaron en los 80’s y se empezó a difundir su uso enormemente en el WEB, su evolución permitió incorporar nuevas técnicas en el rastreo de redes sociales, reconocimiento de voz y minería de texto, entre otros. Por otro lado, las técnicas de minería de datos, análisis avanzados, técnicas predictivas también tienen un periodo de maduración de décadas.

4.2 Riesgos en los proyectos de BI

Si las técnicas empleadas no son nuevas, entonces ¿Por qué el riesgo es alto? ¿Por qué existe tanto desconocimiento?

Las empresas se han detenido en la década de los 90’s, cuando el desarrollo de proyectos de inteligencia de negocio giraban solamente alrededor de almacenes de información y análisis OLAP, se siguen empleando las mismas antiguas técnicas de modelaje, construcción, administración y planeación de proyectos de TI aplicadas a proyectos de BI. Eso es por un desconocimiento del área e implica un gran riesgo en el desarrollo de este tipo de proyectos.

Por desconocimiento, nos referimos principalmente al desconocimiento de la tecnología, metodologías, y mejores prácticas. Los costos refieren impactos económicos en la empresa por tecnología o capacitación.

De los riesgos comunes a todos los proyectos de TI como lo son la mala planeación, el contar con recursos adecuados, el constante cambio en los requerimientos, son también puntos a tener en cuenta dentro de los riesgos.

Empecemos por emplear una metodología distinta y no una tradicional para proyectos de TI, usemos metodologías ágiles, alcances cortos, objetivos crecientes (incrementales), resultados controlados y mucha, mucha interacción entre las fases.

Es necesario controlar los cambios, los recursos, los costos, y las expectativas durante el desarrollo del proyecto, el aprovechamiento de herramientas de BI gratuitas. La construcción de un prototipo puede aclarar muchas dudas tanto a los usuarios como al equipo de desarrollo, sobre todo si no conocen lo que esta tecnología ofrece, si el resultado del prototipo es positivo, pude incurrir en la compra de una herramienta o el desarrollo de su proyecto con alcances y objetivos más realistas.

4.3 Cinco reglas para minimizar los riesgos en un proyecto de BI

• Comenzar con la estrategia adecuada: Con una estrategia integral y detallada, y un plan basado en los resultados de negocio que su organización espera alcanzar.
• Invierta en experiencia: Para implementar proyectos de BI grandes y complejos es necesaria una combinación única de administración de proyectos, conocimiento técnico y administración de la gestión del cambio. Complejidad de la empresa.
• Entender la madurez de BI: Entender dónde está parada su organización en términos de madurez de BI le dará una perspectiva clara de donde se encuentra actualmente su proyecto de BI, hacia donde necesita ir, y cómo llegar allí.
• Comenzar de apoco: Asegúrese que los hitos de su proyecto sean alcanzables. Tratar de hacer mucho en poco tiempo pondrá su proyecto en riesgo y perderá credibilidad en corto plazo. Establezca y cumpla con los objetivos de su proyecto para mostrar la integridad y capacidad de su equipo, de esta forma, la gente comenzará a confiar en usted desde una etapa temprana del ciclo de vida.
• Entregue a la empresa lo que ella necesita: de ofrecer lo que el negocio necesita en vez de enfocarse en la tecnología, Haga prototipos en todas las etapas para asegurarse que el usuario obtendrá lo que quiere.

VIDEO RELACIONADO:
https://vimeo.com/111191463

LECTURAS COMPLEMENTARIAS:

1. Gestión de Proyectos BI
http://inteligenciadenegocio.mx/blog/category/gestion-de-proyectos

2. Guía de éxito para El Director proyectos de Business Intelligence.
http://www.beyenetwork.es/view/7644

3. Implementación de inteligencia de Negocios paso a paso
http://es.slideshare.net/danielventura353/proyecto-bi-implementacion-slide