25/05/2006
7 comentarios - Envía el tuyo
En muchas compañías, es habitual emplear a expertos exteriores para que ayuden en un proyecto importante de DW o Business Intelligence en ejecuciónn, tal como una migración del Datawarehouse o del sistema transaccional. Esto se hace a menudo porque tales proyectos son relativamente a "corto plazo," durando 1-2 años, y emplear contratistas exteriores evita el costo a largo plazo de un empleado a tiempo completo. También ayuda a conseguir un proyecto exitoso traer consultores que son expertos en su materia, entrenados, que pueden conseguir que el proyecto avance rápidamente, y producir así resultados en un tiempo-marco lo más corto que sea posible. Esto siempre será más rápido que entrenando al personal existente de la empresa. Además, los trabajadores existentes tienen típicamente responsabilidades existentes que deban manejar mientras que el proyecto está en curso.
¿Suena bastante bien hasta ahora, eh?
El problema viene, no porque contratemos a consultores externos; ya que eso se puede considerar como útil. El problema viene cuando el negocio desarrolla demasiada confianza en los consultores o los contratistas y no deja la maestría necesaria "en casa." Se debe recordar que cerca de 20% del coste de un proyecto de DW es sólo en la puesta en práctica inicial, y que el resto del coste viene de su gerencia en curso sobre la vida del proyecto.
Es vital importante que los encargados de DW comiencen, desde el principio del proyecto, a tomar la propiedad del producto final. Incluso si el desarrollo entero es de outsourcing como contrato a "precio fijo".
Si no se hace, se terminará por pagar los nuevos chalets de vacaciones de los consultores durante los siguientes años, en vez de cosechar para la propia empresa las recompensas del proyecto de DW.
servido por Emilio
7 comentarios
16/05/2006
8 comentarios - Envía el tuyo
BPM (Business Performance Management), es uno de los términos que más estan sonando ultimamente en el mundo de la gestión empresarial y del Business Intelligence.
Básicamente, se trata de controlar el funcionamiento del negocio a través de una suite de productos diferentes. Es como un 'paraguas' que recoge herramientas de diverso tipo: reporting, análisis, planificación, presupuestación, modelización, dashboards, scorecards, etc...
Digamos que, en este caso, lo más importante es el objetivo funcional o de negocio a conseguir y tratar de integrar todas estas herramientas de forma coherente.
BPM es una herramienta para los managers, no como un ERP, y es muy importante definir e integrar los procesos de negocio.
Por ello, lo más importante será elegir una solución BPM única, en lugar de comprar por separado. Pero cómo esto es dificil, desde el punto de vista del gasto y reutilización de los sistemas existentes, habrá que poner el foco también en integrar y homogeneizar las soluciones actuales.
Los 10 factores clave para el éxito en una implementación de un sistema BPM serían:
1) Tenemos que obtener información relevante para nuestro negocio. No el día a día como un CRM o ERP. Además se tiene que hacer con un acceso rápido, con información exacta, actualizada y con la posibilidad de establecer alertas.
2) Poder hacer análisis predictivo. Se trata de ser proactivo en la toma de decisiones, para poder detectar anomalías, hacer forecasts, lanzar nuevos prodcutos, cambair procesos actuales...
3) Establecer procedimientos de control, mediante la implementación de reglas de negocio, sistemas de monitorización en un sistema separado y controlable diferente al ERP y CRM.
4) Unificación e integración. Quizás sea uno de los elementos claves. Poder tener un entorno homogéneo, con datos reales, de presupuesto y de forecasts combinados, con un sólo sistema de cálculo y un repositorio com´çun.
5) Facilidad de uso. Debido a quienes son los usuarios potenciales, será necesario llevar la facilidad de uso a todos los ámbitos: facilidad de implementación, facilidad en la entrada de datos, facilidad de análisis y reporting, integración con excel, web interface...
6) Cumplimiento de las normativas vigentes. Estos sistemas BPM deben adecuarse a las normativas contables, legales, financieras vigentes en cada país, en cada momento.
7) Grandes posibilidades de workflow, controlando los procesos de planificación y presupuestación, estableciendo prioridades, consolidaciones, 'scheduled' de tareas...
8) Debe ser un sistema ágil, que detecte rápidamente los problemas y errores, y sea capaz deimplementar las mejoras y novedades en poco tiempo.
9) Autonomía en cada nivel. Para mejorar el sistema BPM es necesario dar autonomía en la forma de gestión y manejo a cada área dentro del proceso: IT, usuarios, servicios centrales, delegaciones...
10) Establecer un entorno colaborativo, es decir, poder compartir documentos y entrada de datos entre usuarios. Muy importante en el proceso de elaboración/aprobación de presupuestos, establecer relaciones jerárquicas, etc...
Fuente: Cartesis
Mas info:
Best Practices in Business Performance Management: Business and Technical Strategies--Excerpt from the Full Report
BPM Pulse: BPM Healthy, Vendors … OK
The Myths of BPM: TDWI
Business Performance Management
The Consultancy Approach to Business Process Management
servido por Emilio
8 comentarios
27/04/2006
9 comentarios - Envía el tuyo
Coincidiendo con el año del lanzamiento del Portal Todo BI, se ofrece a los lectores un estupendo regalo: un Informe muy completo que os podéis bajar sin ningún tipo de registro, ni cuota, ni nada.
Un informe de más de 200 páginas que contiene toda la información esencial que hay que conocer sobre el estado del Business Intelligence. Todo ello, siguiendo nuestra costumbre, está en castellano; para que os podáis guardar el informe y utilizarlo como herramienta de consulta en cualquier momento.
Bajar el Informe (puede tardar un instante, un minuto, según conexiones)
Os reseño el Indice del Informe, en dónde veréis el gran abanico de temas de interés que se abordan y que creo os serán de utilidad:
1. Introducción
2. La inteligencia de negocio como estrategia competitiva
3. Los mejores artículos de "Todo BI"
4. Estudios de Mercado
5. Listado de Fabricantes
6. Listado de Consultoras
7. Éxito en la implementación de sistemas BI
8. Identificación de los Indicadores Clave de Negocio, KPIs
9. El Open Source en Business Intelligence
Pero, por supuesto hay que agradecer expresamente a los sponsors de este Informe: XLCubed, Business Objects, Stratebi, Denodo, Hyperion, Iteva Solutions y Symtrax, que gracias a su colaboración ha sido posible.
servido por Emilio
9 comentarios
06/04/2006
15 comentarios - Envía el tuyo
En muchos de los artículos que aquí comentamos aparece el término OLAP. Aunque otras veces hablemos de multidimensional, de cubos... nos referimos a lo mismo.
Dado que es uno de los temas que más me interesan voy a intentar explicar que significa, que características tiene y, sobre todo, para que nos puede ser útil.
OLAP significa ‘On-Line Analytical Processing’, que se contrapone con el término OLTP ‘On-Line Transactional Processing’. Término más habitual, que define los sistemas de bases de datos relacionales usadas ampliamente en el mundo empresarial.
En estos últimos sistemas lo importante es el registro de los datos, y en OLAP, lo importante es el análisis. Esta es la diferencia más general que os puedo dar. Pero existe mucho más.
Es importante saber ésto, por que muchos vendedores dicen que tienen productos con capaciadad OLAP, cuando ésto no es cierto del todo.
Desde el punto de vista teórico un sistema OLAP debe cumplir las reglas del Dr. Codd, recientemente fallecido, y 'padre' del concepto:
Se tiene que tener una visión multidimensional de los datos. Pensar en dimensiones y métricas de Negocio. No en tablas y en campos.
La manipulación de los datos tiene que ser intuitiva y sencilla. Son los análistas y altos ejecutivos los que manejan estas herramientas, y hay que pensar en ello.
El motor OLAP debe ser un organizador intermedio para que las aplicaciones finales: Cuadros de mando, Scorecard, aplicaciones de análiticas financieras, etc... provean de datos al usuario.
Posibilidad de acceder a datos almacenados directamente o en procesos batch, desde el relacional. Es decir, posibilidad de tener un sitema híbrido. Algo más parecido a un sistema HOLAP.
Creación de modelos basados en OLAP. Este requerimiento es muy subjetivo y depende de la complejidad de los modelos. Cuantos más tipos de modelo, mejor OLAP será.
Arquitectura Cliente/Servidor, pensado como la posibilidad de que los usuarios interactuen y colaboren en la aplicación.
Transparente para los usuarios. Se debe ocultar la capa de complejidad, de procesos batch, de cargas ETL... dejando sólo una capa de abstracción de negocio.
Acceso multiusuario a las aplicaciones, de forma concurrente, con posibilidad de modificaciones, estableciendo colas de trabajo, etc...
Integracion de datos no normalizados en el cubo OLAP, que garanticen que las modificaciones en datos no origen no afectan a los datos finales.
Mantener los cálculos y resultados de queries OLAP separados y almacenados en una ubicación diferente del sistema fuente.
DIferenciación de los valores vacíos de los valores 0. Muy importante a la hora de realizar cálculos matemáticos.
Posibilidad de ignorar todos los valores vacíos, las celdas del cubo sin datos.
Flexibilidad en la creación de informes.
Rendimiento uniforme de todos los informes, es otra forma de hacer 'transparente' la aplicación.
El sistema OLAP debe adaptar automáticamente su estructura según sean las dimensiones, métricas, etc... ésto no es fácil y, generalmente, requiere intervención manual.
Posibilidad de crear dimensiones de cualquier tipo.
Sin límite de dimensiones, niveles de agregación, jerarquías, etc... Debe ser la complejidad del negocio la que marque el límite.
No establecer restricciones a las operaciones que crucen cualquier dimensión o elementos de la dimensión.
Desde un punto de vista práctico me gustaría añadir algunas otras características:
- Debe ser rápido. No debe transcurrir mucho tiempo entre la necesidad de información y el resultado.
- Debe tener un lenguaje funcional y de negocio.
- Debe ser de manejo sencillo, con wizards y templates.
- Debe poder integrar API.
- Debe tener potentes posibilidades gráficas.
- Debe utilizar mapas de forma habitual.
- Posibilidad de almacenar y compartir los informes y cálculos creados por los usuarios.
- La administración la deben llevar los usuarios, no IT.
- El tiempo de implementación (proyecto) debe ser muy corto.
- Deber generar respuestas medibles para la toma de decisiones.
- Tenemos que ser capaces de obtner ROI con las aplicaciones OLAP.
servido por Emilio
15 comentarios
