El proceso de escoger un producto OLAP o algún otro componente de una solución de Inteligencia de Negocios no es fácil, menos cuando en el mercado todos los productos parecen similares. Cada producto dice ser el más innovativo, eficiente, y más ampliamente usado. La selección de un producto OLAP debe llevarse a cabo conjuntamente entre usuarios y técnicos evaluando elementos de arquitectura y de interface de usuario; además, debe recordarse que la escojencia del producto adecuado es solo uno de los pasos necesarios para el éxito de un proyecto de inteligencia de negocio.

Muchas veces en la evaluación de herramientas OLAP se termina comparando un grupo de proveedores OLAP sin conocer primero cuales son las verdaderas necesidades del negocio. En particular, los compradores a veces permiten que sean los vendedores quienes los eduquen sobre las tecnologías disponibles en el mercado, lo cual resulta ser una ruta riesgosa porque los vendedores no pueden ser imparciales respecto a los productos que ofrecen. El esfuerzo intelectual debe ser hecho previamente a reunirse con cualquier vendedor de productos OLAP.

Para escojer el producto racionalmente debe primero entenderse para que va ha ser utilizado. Esto parece obvio, pero muchas compañias quieren escojer el mejor producto antes de conocer para que será utilizado; inician reuniendose con vendedores antes de saber si sus productos son apropiados para las necesades de la compañía. Para elaborar la lista de proveedores usted debe :

• Tratar de predecir lo que los usuarios realmente necesitan, no solo lo que ellos dicen que quieren. Esto significa que usted debe entender lo que ellos hacen, que habilidades tienen, y que información y análisis les hara más productivos.
• Involucrar el usuario final en cada etapa, incluyendo definición del proyecto, selección e implementación del producto.
• No espere que lo usuarios sean capaces de listar todos sus requerimientos de antemano.
• Nunca trate de decidir sobre arquitecturas de procesamiento y almacenamiento antes de entender las necesidades del negocio.
• No restrinja sus decisiones a la tecnología disponible en su compañía, o lo que es peor, no trate de utilizar software de anteriores proyectos de inteligencia de negocios que han fracasado.

Si OLAP es nuevo para su organización, puede ser dificil realizar alguna de las anteriores cosas, y probablemente será más valioso iniciar con un proyecto a pequeña escala, usando una herramienta orientada a usuario final, principalmente para ganar experiencia. Los usuarios encuentran mucho más fácil definir sus necesidades después de haber experimentado con una herramienta básica que tratar de hacerlo de la nada.

Cualquier compra de OLAP debe entregar un valor agregado al negocio. Esto es, cada proyecto debe tener un objetivo claro con beneficios especificos, y una aproximada tasa de retorno que pueda ser medida. Simplemente asumir que más información y mejores reportes 'es bueno' no es suficiente justificación para un proyecto. Se deben identificar beneficios cuantificables que puedan ser medidos antes y después del proyecto; si esto no puede ser hecho es dificil decidir quienes deberian usar el sistema, cuales son sus necesidades de información, ó que costos son justificables. Este proceso puede a veces simplificar los proyectos, lo cual no solo reduce costos, sino que incrementa enormemente las posibilidades de exito.

Dentro de los asuntos que deberian ser claramente identificados antes de iniciar la selección de herramientas y arquitectura OLAP, estan:

• Volúmenes de datos de entrada y de salida, ahora y en el futuro
• Volatilidad de los datos.
• Tipo de aplicación que se requiere: análisis de ventas y mercadeo, CRM, presupuesto y planeación, gestión del desempeño, tablero integrado, consolidación financiera, etc.
• Características clave: write-back, funciones de análisis financiero, cálculos con lógica compleja, minería de datos, simulación, análisis what-if?.
• Número de usuarios y su localización. Afecta arquitectura, seguridad y costos.
• Perfíl de los usuarios. Alta gerencia, financiero, mercadeo, producción, etc.
• Habilidades de programación requeridas. VB, Excel, ETL, diseño de cubos, SQL, Scripting.
• Quién se espera que haga la implementación y el mantenimiento. In-house, colsultores externos.
• Plataformas de servidor. NT, Unix, AS/400, Linux.
• Estándares en PCs y navegadores.
• Arquitectura de implementación. Stand-alone, cliente-servidor, intranet, extranet, internet.

El análisis de los puntos anteriores debe dar como resulado una lista de compañias cuyos productos mejor se ajustan a los requeirmientos de su organización.

A pesar de parecer similares (particularmente en la web), los productos OLAP tienen grandes diferencias en arquitectura y funcionalidad y un solo producto no es bueno para todo. Por ejemplo, algunos pueden manejar un gran volumen de datos pero sus herramientas de análisis y visualización no son suficientemente flexibles. Otros productos son optimos en análisis de datos pero solo se desempeñan bien con bajo volumen de datos. Por otro lado, todos los usuarios no tienen las mismas necesidades y aptitudes. Muchos usuarios necesitan solo un poco más que los reportes predefinidos en la web, posiblemente con algunas funcionalidades de drill-down y algunos enlaces. Otros requieren los reportes predefinidos como un punto de inicio para modificarlos significativamente y en forma regular (lo cual significa que una herramienta de análisis flexible y rápida será preferida). Unos pocos usuarios quedrán construir sus propios modelos de análisis y hacer exploración profunda de los datos; ellos posiblemente necesitarán herramientas especializadas en análisis estadístico, minería de datos o análisis financiero. Y puede haber una gran mayoría de usuarios 'pasivos' que solo desean recibir reportes o notificaciones si hay algo interesante ó relevante para ver; ellos nunca consultaran el sistema entre notificaciones.

Con esta amplia posibilidad de usuarios, es dificil encontrar un producto que satisfaga todas las necesidades. Lo más razonable, es seleccionar un grupo de tecnologías que satisfagan los requerimientos de usabilidad en la organización.

Muchos compradores pueden favorecer a los grandes vendedores en la premisa que no hay riesgo de desaparecer en los próximos años. Aunque esto puede ser verdad, no significa que ellos son los mejores proveedores de Inteligencia de Negocios. Frecuentemente los clientes de vendedores de pequeña omediana escala estan más contentos que aquellos que han comprado a grandes compañías, principalmente porque el compromiso mostrado hacia sus clientes por vendedores pequeños y especializados, es mayor y muchas veces son más competentes que las grandes compañías donde hay diversificación de mercado y poseen un gran número de clientes.

Los vendedores bien establecidos pueden decir que tienen varios años de experiencia en soluciones OLAP, pero la mayoría de los técnicos experimentados pueden ya no trabajar en la compañía, y usted probablemente será soportado por ingenieros con poco más de un año de experiencia en soluciones OLAP.

Aunque NT4 puede ser considerado no tan estable y escalable como los mainframes, AS/400 o UNIX, estos últimos generalmente no son adecuados para aplicaciones OLAP. A pesar de sus fortalezas tecnicas los mainframes tienen mínimo soporte de los fabricantes OLAP. Solamente los grandes sistemas de análisis de ventas o instalaciones de acceso internet a gran escala realmente necesitan el poder extra que ofrece un sistema Unix o AS/400. Por otro lado, los sistemas Windows 2000 y 2003 son más escalables y confiables que Windows NT4, y sus características se parecen más a las de los sistemas mainframe. El mercado de productos para windows esta mejor soportado, de tal forma que es fácil encontrar bajos precios y se tiene mayor poder de negocioación en la compra de software OLAP. Se estima que al menos un 70% de las instalaciones OLAP estan en Windows 2K o NT, y la mayoría del restante esta en UNIX.

Otro aspecto de la arquitectura técnica es el modelo OLAP utilizado. Es fácil confundirse con el argot técnico de modelos ROLAP, HOLAP, y MOLAP. Aunque en ROLAP puede manejarse un mayor volumen de datos, es alto el precio que se paga en terminos de reducción de funcionalidad, costos de implementación y desempeño. Cualquier decisión que prefiera el modelo ROLAP debe basarse en un conocimiento pleno de las necesidades técnicas y del negocio, por ejemplo, conocer muy bien cual es el volumen real de datos que se espera que la aplicación maneje. En general, quizas un cinco porciento de aplicaciones OLAP realmente necesitan de una solución ROLAP, y para el restante 95% es más apropiado un sistema MOLAP o HOLAP.

Para la arquitectura MOLAP debe considerarse el efecto de la explosión de datos (crecimiento del volumen de datos por la generación de resumenes precalculados). Un producto MOLAP puede desempeñarse muy bien con un volumén bajo de datos pero cuando tiene que lidiar con un volumen grande, el desempeño en consultas de usuario puede verse disminuido significativamente, o puede requerir de recursos adicionales de memoria y procesador en el hardware.

No se deberia asumir que un producto de precio alto es necesariamente mejor que uno de precio bajo. Los vendedores OLAP y las estatregias de mercadeo pueden tarificar un producto muy por encima de lo que realmente valen. Hay productos económicos en el mercado que pueden hacerlo igual o mejor que un producto costoso. Al menos en las primeras etapas de evaluación de producto el precio no deberia ser considerado.

Cuando se calcule el TCO (Costo Total de Propiedad) tenga en cuenta los siguientes factores:

• Cuáles son las habilidades y conocimiento técnico requerido para construir, mantener, y usar la aplicación?
• Cuántos recursos internos/externos se van a requerir para hacer mantenimiento de la aplicación?
• Cuánto de la plataforma técnica de la empresa puede ser utilizado?
• El método de licenciamiento es usuario concurrente, ó usuario nombrado?
• Cuál es el costo de la licencia de un usuario adicional?
• Cuál es el licencimiento para usuario Web?
• Cuál es el método de licenciamiento de cada componente en la solución OLAP?

Las evaluaciones generalmente se enfocan más en funcionalidades del producto, sin embargo se ha encontrado que los usuarios encuentran dos veces más problemas con el desempeño pobre de sus consultas que con la falta de funcionalidades del producto. El hecho es que los productos bien establecidos en el mercado tienen funcionalidades similares, sin embargo demuestran perfiles de desempeño muy diferentes.

Una prueba de concepto es la mejor manera de revisar el comportamiento de un producto OLAP en un escenario similar al de su empresa, con volumen de datos, usuarios concurrentes, ancho de banda de red, equipos servidores y cliente. Una prueba de concepto deberia construirse en menos de dos semanas, y quedar en evaluación por varias semanas para permitir a usuarios y técnicos de la companía conocer las funcionalidades del producto y el desempeño en un ambiente similar al real. El uso de prototipos tambien aproxima al usuario a los beneficios de un sistema OLAP y lo motiva a elaborar sus propios requerimientos. Algunas veces, el prototipo puede subsecuentemente ser extendido y llegar a ser el sistema de producción definitivo.

La implementación de soluciones OLAP se ha venido incrementando, y a planteado a muchas personas dentro de las empresas el reto de seleccionar una herramienta OLAP sin tener la experiencia previa en su uso o construcción. Las habilidades adquiridas en evaluacion de otros productos de software no siempre puede aplicarse bien para un sistema OLAP. Seleccionar el producto incorrecto puede ser un error costoso, y tambien seleccionar el producto correcto e implementarlo en forma equivocada puede resultar en proyectos largos y resultados ineficientes. Son varias las historias de empresas que han decidido desmontar sus soluciones OLAP porque no encuentran el retorno de la inversión esperado o definitivamente nunca llegaron a implementarlo con éxito.

Este documento ha identificado algunos de los factores que deben ser tomados en cuenta para identificar rápidamente la alternativa OLAP más adecuada y confiable; además, plantea la importancia de una prueba de concepto como un método para evaluar las soluciones en un ambiente real y dentro de los requerimientos particulares de la organización.