Descarga Microsoft SQL Server 2012 (RC0)

Desde el 18 de noviembre de 2011 está disponible el iso del Release Candidate 0 (RC0) de la última versión del motor de bases de datos SQL Server de Microsoft.

RC (Release Candidate) quiere decir que es una versión candidata a ser la versión final, y no es en ningún caso la versión definitiva, sin embargo, la versión final será muy similar pero con mejoras gracias a los reportes de aquellos que bajen el RC para probarlo y reporten bugs, errores y posibles mejoras.

 Sacar un RC tiene beneficios como acercar y familiarizar la nueva versión a los potenciales usuarios, recibir feedback temprano de una comunidad de potenciales clientes más extensa que el equipo de desarrollo y sondear la llegada y uso de la nueva versión.

Los RC son incrementales esta es la versión cero y pueden en el futuro sacar el RC1 y RC2 perfectamente, una vez que la etapa de los RC está completa viene la versión RTM o Ready To Manufacture (Listo Para Fabricar/Manufacturar) que es la versión que irá en las versiones digitales a los clientes finales.

SQL Server se ha caracterizado por ser una solución de principio a fin de Business Intelligence, desde el almacenamiento de los datos (MSSS), integración de datos (SSIS), análisis y modelado de datos (SSAS) y reporting (SSRS) en un mismo entorno de desarrollo; intentando incorporar lo necesario para una gestión de información básica sin exigir muchos conocimientos técnicos para la implementación. La relación costo/beneficio/cobertura es atractiva y se acomoda bien a pequeñas y medianas empresas, sin excluir claro a las micro ni a grandes empresas.

Así es como el proyecto Denali (nombre interno del proyecto) tiene el primer RC, abajo dejo los links de descarga:

- SQL Server 2012 RC0 en inglés.
- SQL Server 2012 RC0 en español.

Si lo descargas me cuentas cómo te fue!

Frase BI 008

What is a Dashboard?

A dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance.

¿Qué es un Dashboard?

Un dashboard es una representación visual de la información más importante requerida para alcanzar uno o más objetivos; consolidada y dispuesta en una sola pantalla para así poder monitorear toda la información en un vistazo.

Stephen Few, "Dashboard Confusion," Intelligent Enterprise, March 20, 2004.

Metología para construir un Data Warehouse

Un Data Warehouse (DWH) es conocido en castellano como un repositorio de datos o almacén de datos, difícilmente puede ser traducido como repositorio o almacén de información, debido a que desde el DWH provienen los datos que son transformados en información para el apoyo a la toma de decisiones. La información que proviene de los datos es un mensaje que provoca un cambio en el conocimiento del que recibe el mensaje.

La decisión de construir un Data Warehouse (DWH) depende de varios factores. Hay muchas variables anexas a esta decisión como:

• madurez de la organización en cuanto a sistemas de información,
  
• cantidad de sistemas de información existentes,
  
• cantidad de fuentes de información existentes,
  
• cantidad de usuarios que consumen información a diferentes niveles (recordemos que en todo nivel de una organización se toman decisiones),
  
• calidad de datos de los sistemas operacionales,
  
• necesidades de información actuales / futuras,
  
• planes de crecimiento de la organización,
• desafíos de análisis y entrega de información,
  
• etc.

Desde luego existen más factores, puedes dejar en los comentarios aquellos que se te ocurran.

Luego de decidir si construir o no un DWH ya sea con enfoque Kimball que recomienda construir data marts para los diferentes procesos de negocio de la organización, sobre una arquitectura tipo bus y dimensiones compartidas, con un modelado altamente dimensional podemos decir que tenemos un DWH en nuestra organización; o con el enfoque de Inmon quien recomienda llevar el modelo de datos de información a tercera forma normal, en un sólo modelo corporativo y desde donde se puedan generar diferentes sub-modelos de datos para satisfacer necesidades específicas a un determinado proceso de negocio de la organización. Resumiendo, Kimbal dice que la suma de los data marts generan el DWH e Inmon dice que el DWH (modelo único de datos en 3NF) genera los diferentes data marts.

Tener un DWH es requisito para construir un sistema de BI? por supuesto que NO. Sin embargo si estás evaluando o has empezado un proyecto de DWH un poco de ayuda y guía es bienvenido. Por eso quería compartir este valioso recurso que en Dataprix ponen a disposición de quienes quieran acceder a él, hace 2 años posteaba sobre HEFESTO Datawarehousing, hoy está disponible la versión 2.0 y además en formato ePub. Felicitaciones por la difusión y la calidad del material. (Fuente: TGX - HEFESTO.)

Suerte con el proyecto de data warehouse que estás emprendiendo, por supuesto las consultas, dudas y comentarios son bienvenidos en AnalisisBI.

Links:
- Formato on-line.
- Formato ePub.

Base de datos ejemplo de Pentaho en MySQL

Cuando intentaba cargar datos en la base de datos de ejemplo de Pentaho en MySQL en ambiente windows, aparecieron errores en la inserción de ciertos registros en tablas con columnas de tipo timestamp, específicamente con los valores'2003-10-11 00:00:00.000000' y '2004-10-09 00:00:00.000000'.

Luego de pensar un momento (tal como en la foto), se me ocurrió una posible explicación a este fallo debido a la zona horaria de la base de datos y he aquí la explicación...

Primero hay que saber que MySQL tiene soporte de hora por zonas, al instalar el servidor MySQL en windows, por defecto toma la zona horaria de la máquina, con "select @@global.time_zone, @@session.time_zone;" se puede obtener la hora del sistema, si retorna SYSTEM es porque tiene la misma zona horaria de la máquina donde está instalado el servidor, como en mi caso.

Y segundo se debe considerar la fecha y horas locales, si bien las fechas parecen ser correctas en el formato, de acuerdo al país donde vivo (Chile) esas fechas no existen debido a que en Chile se hacen cambios de horario 2 veces al año:

• el segundo sábado del mes de octubre se adelanta 60 minutos la hora y,
  
• el segundo sábado del mes de marzo donde se retrasa 60 minutos la hora.

Al revisar las fechas que arrojan problemas efectivamente corresponden al segundo sábado de octubre de 2003 y 2004. El cambio de horario quiere decir que un segundo después de las '2003-10-10 23:59:59.000000' de esos días fueron las '2003-10-11 01:00:00.000000' por lo que '2003-10-11 00:00:00.000000' nunca existió.

Soluciones a esto puede ser cambiar la zona horaria al inicio del script con "SET time_zone = timezone_value;" pero antes se deben actualizar los datos de las tablas de zonas horarias que están en la base mysql que vienen sin datos en la instalación por defecto o simplemente agregando la siguiente línea al principio del archivo:

"SET time_zone = '+0:00';"

Con lo cual se asegura la correcta inserción de los datos de ejemplo.

Es interesante el manejo de zonas horarias por parte de los motores de bases de datos, y de MySQL en particular ya que mejora la calidad de los datos y simplifica ciertas validaciones en los datos.

PS: Debo agregar que la costumbre local es cambiar la hora el sábado a media noche, es decir, a las 23:59:59 horas del sábado se pasa a las 01:00:00 horas del domingo.

Predicciones BI 2010 - 2012

Como es de costumbre al comenzar el año dejo algunas predicciones e ideas sobre BI para este año y los que vienen:

1. Proyectos pequeños de alto impacto (PPAI): En los ultimos años hemos visto proyectos ambiciosos de BI, implementaciones que se planifican a varios años y que luego se extienden por más años. El énfasis será conseguir proyectos de alcance acotado pero de alto impacto en las organizaciones. Principalmente en áreas donde se busca la reducción de costos, tiempos y esfuerzos. Estos PPAI entregan soluciones a los consumidores de información en forma simple y entendible sin necesidad de realizar análisis, estos proyectos involucran un desarrollo flexible y un diseño ajustado a cada necesidad, no son proyectos genéricos sino a medida. Esto no quiere decir el abandono de proyectos de gran tamaño, por el contrario, los PPAI son la entrada para continuar con implementaciones maduras de BI en las organizaciones. Esto tiene dos consecuencias importantes, primero mantener el apoyo y la confianza de la alta dirección de las organizaciones para implementaciones mayores de BI y segundo es que ajusta las espectativas de los usuarios al conocer los beneficios de una implementación exitosa.


2. Integración y calidad de datos: Cuando las organizaciones tienen varios motores de bases de datos soportando el ambiente operacional con varios sistemas transaccionales y se embarcan en iniciativas BI de cualquier índole, deben considerar como punto importante la integración de datos, y si se trata de los primeros proyectos BI entonces hay que enfocarse en la calidad de datos. La integración de datos será un punto aparte en los próximos años debido a la necesidad de entregar datos e información confiable y consistente para el negocio. Los vendedores son cada vez más concientes de esto y tienden a ofrecer soluciones integrales de tratamiento de datos, con capacidades de administración de metadata y MDM (Master Data Management).


3. Reduccion de costos de capacitación en soluciones BI comerciales: Una posible estrategia por parte de las soluciones comerciales de BI, es reducir el TCO (Costo Total de Adquisición) de sus soluciones a través de una reducción del costo de capacitación en sus soluciones, sobretodo para no perder clientes principalemente PyMEs. Generalmente la capacitación en una herramienta específica se realiza por partners y consultores externos al vendedor y serían estos actores los que podrían evaluar esta alternativa.


4. Aumento de webinar por parte de soluciones BI comerciales: Para las soluciones Open Source es un recurso conocido organizar webinar sobre tópicos relacionados y uso de sus herramientas, no tanto así para soluciones comerciales, los webinar son un excelente canal para llegar a clientes y potenciales clientes.


5. Soluciones hechas a medida: Los proyectos grandes y de largo alcance son necesarios, pero si se trata de primeros proyectos lo que conviene es resolver el problema con soluciones acotadas y a la medida de las necesidades de información. Para esto creo que las soluciones a medida predominarán por sobre las soluciones por rubro o soluciones genéricas. Por ejemplo si 2 empresas de telecomunicaciones compran el mismo proyecto BI para empresas de telecomunicaciones no significa que obtendrán los mismos beneficios o que tendrán el mismo ROI; el resultado depende del alineamiento a los objetivos estratégicos de la empresa y el ecosistema de información. Por esto las soluciones a medida tienen más valor como primera iniciativa BI en una organización y esto será lo que demandarán los clientes.


6. Cambio en el paradigma de mantención de los ambientes BI: Por el lado de investigación y desarrollo aparte de la visualización de datos y rendimiento (performance) que son grandes puntos y lo que hace atractiva a una suite de BI, la administración de la plataforma ofrecerá adelantos significativos en los próximos años. La tarea es y será en los próximos años de reducir la complejidad del proceso de mantención de las plataformas BI. El resultado será disminuir el tiempo dedicado a mantenciones, hacer el proceso más simple, ofreciendo por ejemplo recomendaciones y alternativas a la configuración, disminuir los riesgos de errores en el proceso por intervención manual (esto también disminuinuye el TCO debido a que no requiere mucha expertiz en estas labores y por menos tiempo). Además es un punto a mejorar en las soluciones on-premise ya que con soluciones tipo SaaS, por lo general, no nos preocuparnos demasiado por la mantención del ambiente, no así con las soluciones instaladas en nuestros servidores. La competencia por quién ofrece una mejor plataforma con buen rendimiento y sin complejos proceso de mantención es un tema para los próximos años.


7. Performance Management y Balanced Scorecard: En un escenario post-crisis las organizaciones demandarán soluciones tecnológicas de acuerdo a su nivel de madurez en BI, su cultura organizacional y a la necesidad de seguimiento y cumplimiento de los objetivos estratégicos. Se puede decir que viene un auge de proyectos relacionados con PM, ya sea de planificación, presupuestación y pronósticos o cuadros de mango integrales pero las necesidades existen y las soluciones no se harán esperar durante los próximos años.


8. Discusión sobre términos y nomenclatura BI: Desde los inicios de la inteligencia de negocios es común usar terminlogía poco clara, para cada término BI se pueden encontrar varias definiciones; incluso es poco claro el límite de cada concepto, por ejemplo ¿dónde termina BI y comienza PM? y viceversa, o ¿qué quiere decir el término "business analytics"? todo depende de quien tenga o haga la opinión. La terminología se da generalmente por tres actores principales: los vendedores, los analistas de mercado y por los expertos en temas BI. La tendencia es que sigan apareciendo nuevos términos para dar nombre a un conjunto de elementos que antes se nombraban por separado, y también a buscar un mejor definición de cada nomenclatura, creo que falta todavía por trabajar en la metadata de BI.


9. Uso de SaaS por pymes: La alternativa existe, cada vez más empresas pequeñas optan por soluciones tipo SaaS como ERP y CRM. BI no será la excepción en mi opinión, veremos cómo aumenta la oferta y la participación de mercado de este tipo de soluciones, y también el movimiento de las soluciones on-premise a este tipo de servicio.


10. ERP y CRM open source: Las aplicaciones de tipo ERP y CRM Open Source más antiguas son cada vez más estables y con más funcionalidades en cada versión, además de ofrecer integración con soluciones OSBI, son un mercado nuevo en desarrollo y con señales de crecimiento por varios años más.


11. Adopción fuerte de BI en sector financiero: La situación actual y reciente del sector financiero a nivel mundial nos muestran la necesidad de tener información oportuna para tomar decisiones. El interés de las áreas usuarias a todo nivel repercute en un mayor involucramiento de los usuarios mejorando la calidad de los proyectos, y el resultado es poder tomar decisiones con información oportuna. Las organizaciones necesitan tener una administración flexible y ser capaces de reaccionar y saber en todo momento donde se encuentra la organización en el contexto mundial. Las soluciones BI para el sector financiero es una realidad que se mantendrá por años hasta tener empresas guiadas por BI.


12. Crecimiento mercado BI en Brasil y Perú en latinoamérica: La inversión en tecnologías de información fue una de las pocas que no se vio afectada durante la crisis económica mundial y la inversión en BI ha sido prioridad para las organizaciones por varios años consecutivos, podemos asumir que se han aplazado proyectos pero no se han dejado de hacer. Brasil por el tamaño del mercado presenta una demanda creciente para soluciones de sistemas de información y Perú por el crecimiento que ha tenido el último tiempo es otro foco de crecimiento BI.


13. Mejora en la calidad de los proyectos BI por cultura BI: Dicen que la práctica hace al maestro, y es precisamente lo que sucede en organizaciones con varios años de experiencia en proyectos BI, ganan en conocimiento y cada nueva implementación se aplican mejores prácticas y lecciones aprendidas de proyectos anteriores, esto permite que mejore la calidad del desarrollo y de la solución final. Mientras más personas en la organización estén involucradas con el desarrollo de los proyectos más valor adquiere la solución final para esa organización.


14. Adquisiciones: Este tema da para un post por separado, pero se puede adelantar que las adquisiciones apuntarán por el lado de analíticos (motores de decisión en línea) y visualización de información y en segundo lugar mejorar el performance. Las empresas se fortalecerán para ofrecer soluciones analíticas cada vez más simples de usar. Seguirán las asociaciones entre vendedores para ofrecer soluciones conjuntas.

Esperemos que las organizaciones generen valor a partir de sus datos y tengan la habilidad de explotar los sistemas de información con los que cuentan. En cuanto a BusinessAnalytics.cl será un año, espero, con mucho contenido original y difusión de temas relacionados a los Sistemas de Información.

Los comentarios y críticas serán bien recibidas. Si quieres proponer algún tema para tratarlo en BusinessAnalytics.cl puedes enviarlo en la sección de Contacto.

Sistemas ETL

De acuerdo a Kimball, podemos encontrar 4 componentes principales para definir un sistema de BI o componentes en un sistema de información:

1. Los sistemas fuentes, o fuentes de datos

2. Los sistemas ETL

3. Las áreas de datos (de Stagging y de Presentación)

4. Aplicaciones de acceso a los datos

Este post se enfoca en el punto número 2 que son los sistemas ETL, en post futuros se desarrollarán con más detalle los otros 3 puntos.

ETL significa Extraer, Transformar y Cargar (Load por su sigla en inglés) los datos, una variante puede ser ELT que propone traspasar los datos primero y luego realizar todas las transformaciones en el destino.

En términos simples ¿qué es ETL? (definición personal y genérica): "son todas las actividades necesarias relacionadas a la administración de datos y metadatos para satisfacer las necesidades de información".

A ver si se entiende... entonces de acuerdo a esta definición ¿el traspaso de datos es parte del proceso ETL? R: Sí. ¿Y las transformaciones de datos, la agregación de nombres a los códigos inentendibles, y las consolidaciones de los números por cliente? R: También es parte de ETL. ¿Y cuando se requiere enviar los reportes corporativos para el quinto día del mes con la información de cada sucursal en cada región? R: También es parte de ETL ya que requiere el traspaso de los datos de las bases de datos locales de cada región a un repositorio para así procesar los datos y enviar los reportes; es misión del proceso ETL cumplir en tiempo y precisión la carga de los datos.

Imaginemos nuestro plan de BI como un gran reloj, en donde en los procesos ETL encontramos la mayor cantidad de engranajes grandes y pequeños que se encargan de que todo lo planificado funcione precisa y eficientemente. Cualquier desperfecto propaga el error.

La arquitectura ETL debiera pensarse como un servicio independiente a la presentación y consulta de datos, es decir, dedicar hardware y software para esto y en la implementación seguir las mejores prácticas recomendadas por cada vendedor y aquellas que la experiencia indican.

El proceso de ETL, desde el punto de vista tecnológico es un FCE (Factor Crítico de Éxito) de una solución BI, permite automatizar y simplificar procesos muchas veces complejos o demandantes en tiempo, sobre todo de mantención de las soluciones. La mayoría de los proyectos de data warehousing incorporan procesos de ETL, es común ver en más del 80% de estos proyectos un ítem para ETL; no así los sistemas operacionales los cuales aun prevalece el movimiento de datos por código o a través de las mismas aplicaciones.

El proceso ETL no es percibido desde el punto de vista usuario final de los sistemas de información (salvo en determinados casos de minería de datos o análisis específico), sin embargo, los usuarios tienen una participación importante en la concepción y el desarrollo de éstos procesos. Es el negocio el que plantea sus necesidades de información y los requerimientos iniciales del sistema. Esto plantea dos requisitos importantes en los datos que deben ser cumplidos por el proceso ETL:

- el primero, las necesidades de información determinan las fuentes de los datos y dicen dónde se deben buscar, recolectar, transformar e integrar los datos.

- y segundo, las necesidades de información determinan el diseño de la base de datos analítica, es decir, el repositorio de los datos que el proceso de ETL se encargará de integrar y traspasar los datos para lograr el objetivo de la solución final.

Para cumplir con estos objetivos se indica lo que se espera cuando el sistema esté terminado (alcance), las expectativas (funcionalidades), lo que existe y cómo se genera actualmente y esto sirve de input para la definición de las fuentes y destinos de datos.

Lógicamente el diseño de una base de datos analítica no se debe acotar a una necesidad particular, se diseño de tal forma de hacerla flexible de incorporar nuevos elementos al modelo, para eso se diseñan dimensiones que permiten analizar diversas problemáticas de negocio.

Por eso es bueno hablar de la Estrategia ETL que debe tomar en cuenta fuentes y destinos de datos; ventanas de disponibilidad de las bases de datos; rendimiento de los motores operacionales de información y motor del servidor ETL para elegir dónde realizar las operaciones y sacar el máximo provecho al rendimiento.

Cuando se analizan las necesidades de información que serán cubiertas por la solución BI se debe evaluar la factibilidad (¿tengo lo necesario para cumplir lo requerido?), materialidad (¿vale la pena el esfuerzo en hacerlo de esta manera?) y costos (recursos, tiempo y esfuerzo) de éstas. A su vez, inmediatamente podemos identificar requerimientos para el sub-proyecto de ETL (dentro del proyecto global de la solución completa) los cuales en una etapa siguiente deben definirse de mejor forma; como por ejemplo:

• Fuentes de los datos: Tablas de bases de datos operacionales, archivos externos, identificar dónde se encuentran físicamente los datos que quiero mostrar en la solución final.
• Validación y aprobación de los datos a cargar: Alguien se hace responsable de certificar que la data a ser cargada al sistema es válida y precisa y no contiene errores que lleven a tomar decisiones basadas en datos malos.
• Disponibilidad de la fuente de datos: Cuando los datos fuente se encuentran en sistemas operacionales que soportan el día a día de las empresas se tienen ciertas restricciones, sólo accesibles durante la noche ya que en el día no puede sobrecargar el día a día, conocer los horarios de respaldo de los datos para no consultar o programar traspasos mientras la base de datos está abajo, o rechaza las conexiones.
• Destino de los datos: Considerar que el modelo final será un modelo analítico especialmente diseñado para la solución de BI (punto 3 que detallaremos más adelante), considerar también la zona de stagging o zona intermedia donde antes de cargar el modelo final dejo los datos para realizar las transformaciones necesarias.
• Transformaciones necesarias a los datos: el 99,9% de las veces no será un simple extraer e insertar (copiar y pegar) los datos desde los sistemas operacionales hasta los sistemas de información, se definen las transformaciones necesarias, como los pasos de limpieza de datos, corrección de mala calidad de datos, traspasar datos consolidados en vez de datos en detalle, etc.
• Frecuencia de acceso a los datos fuentes: Es importante conocer las "ventanas de tiempo" disponible para acceder a los datos fuentes en los sistemas operacionales.
• Frecuencia de acceso a los datos finales: Debido a la demanda de información resultaría contraproducente realizar la actualización de los sistemas cuando tiene mayor demanda por parte de los usuarios. Se debe planificar la actualización en tiempos en que el sistema es poco usado como por ejemplo durante las noches, o primeras horas del día, etc.
• Periodicidad de carga: Dependiendo del uso y la finalidad de las soluciones se definen periodos específicos de carga acotados a un rango de tiempo, definido por la disponibilidad. Se establecen acuerdos para la actualización de datos de acuerdo a las necesidades, para algunos sistemas puede ser mensual, semanal, diario, o incluso menos.
  

El diseño de la estrategia ETL debe tener siempre en consideración estos factores. Hay que tener en cuenta las transformaciones de los datos en el diseño del proceso completo debido al factor de rendimiento y aplicar las mejores prácticas en el traspaso de datos.

Los comentarios y aportes son siempre bienvenidos.

BI después de la crisis

La palabra "crisis" ha estado en muchos de los blogs y sitios de BI para tratar el tema contingente de la economía mundial, si bien se dice que la inversión en TI es de las menos afectadas, el recorte en BI se ha notado menos y esto presupone un buen augurio para el esperado término de la crisis; este post resume mi opinión de lo que sucederá una vez que la densa niebla de la crisis comience a despejar.

Consideremos que las PyMEs, por lo menos en América latina, durante el primer semetre (H1) invirtieron en hardware, mientras que las empresas grandes recortaron este gasto con repecto al año pasado, esto quiere decir que las PyMEs se han estado preparando para el término de la crisis potenciando su infraestructura tecnológica, potenciando el corazón que bombea información a cada área para la toma de decisiones.

Estos nuevos servidores y servicios son destinados principalmente para los sistemas operacionales que son los encargados de llevar el día a día de una empresa. Sin embargo, al tener mayor capacidad instalada aumenta la oportunidad de implantar y evaluar nuevas tecnologías e ideas, por lo que una alternativa bastante plausible será evaluar distintas soluciones tendientes a optimizar y mejorar los resultados del negocio, es por esto que preveo un crecimiento sostenido en la "evaluación" de soluciones de BI para el primer semestre de 2010 y en adelante.

Lo que crecerá será la evaluación de soluciones, debido a que cada empresa podrá evaluar entre 3 a 5 soluciones para decidirse por una sola, la implementación también crecerá pero en menor medida, y la elección de una herramienta BI no dependerá solamente de la calidad del vendedor (SAP Business Objects, IBM Cognos, Oracle, Pentaho, etc.) sino de las necesidades de cada empresa, de la integración con los sistemas actuales, usabilidad, dependencia con el implementador (solución de problemas, capacitación, implementación in-house / outsourced, etc.), contexto y etapa de crecimiento de la empresa entre otros factores relevantes.

Las PyMEs se inclinarán principalmente por la evaluación de soluciones de bajo costo, o bajo TCO (Total Cost of Ownership), dando chance a las soluciones de tipo Open Source y SaaS (Software as a Services) pero también a aquellas que puedan cubrir la mayor cantidad de necesidades como es la propuesta de Microsoft, con el proyecto Gemini ya establecido junto a SQL Server que ofrece una solución integral en una misma licencia con diferentes ediciones.

Por su parte los proveedores luego de la continua ola de adquisiciones en el mercado BI, pasan por un período de transición en el cual asimilan y potencian las soluciones adquiridas, después de eso buscarán asociaciones con otros proveedores de soluciones para potenciar su oferta, como es el caso de Sun + Infobright + Pentaho, o también Panorama Software + Microsoft, o RightScale + Talend + Vertica + Jaspersoft y así la lista sigue.

Percibo una ligera saturación en la oferta actual de SAP, en cuanto a implementadores y a clientes que ya cuentan con la solución, dejando pocas oportunidades para crecer. Por parte de la empresa alemana pretende crecer fuertemente focalizados en su producto SAP Business Objects, adquirido en 2007 y que por primera vez es presentado como un producto estrella como simpre debió haber sido. Esto da pie para que Oracle, de rivalidad directa con SAP, aparezca en el juego y pueda anotar algunos puntos extras a pesar del alza de sus licencias.

El crecimiento en BI será fuerte en las instituciones financieras. Que, a mi parecer, por lo menos en Chile actualmente subutilizan sus plataformas de BI. La aplicación de estándares internacionales para el manejo de información será un ítem específico que los implementadores BI con experiencia en este nicho podrán aprovechar. El rol más protagónico de la plataforma BI en este tipo de instituciones es desde lejos la moda que los CEO y CFO están llamados a apoyar como iniciativa corporativa y como principal objetivo para para el CIO.

La región con el crecimiento más fuerte post-crisis en BI será Brasil, y sobretodo el sector PyMEs. Se percibe un importante potenciamiento en la oferta, ya sea de parte de vendedores e implementadores que buscan obtener un posicionamiento llegando a esa región.

Y para terminar tres ideas que, en mi opinión, se darán durante la segunda parte de la recuperación de la crisis, pensando en un 2012-14. Habrá un auge por los desarrollos servicios en la nube (cloud computing). La búsqueda de implementar bajo estándares, tanto técnicos como metodológicos, que permitan la intercomunicación y compatibilidad entre herramientas. Y la evolución de las interfaces gráficas para el análisis de datos, lo cual por debajo conlleva un salto en tecnologías de software (aplicaciones analíticas puras) y hardware (superficies táctiles y reconocimiento de voz).

Este artículo fue publicado primero en: BusinessAnalytics.cl