5. SELECCIÓN DE HERRAMIENTAS Y PROVEEDORES

Nos podemos plantear una duda clásica que preocupa a los profesionales de sistemas de información y a los directivos en general: ¿Construir o comprar? Es decir, ¿desarrollamos una aplicación o compramos una herramienta? Se pueden plantear muchos argumentos a favor y en contra de cada una de las opciones, y de hecho tradicionalmente así se ha hecho. Mi opinión personal es que sólo se debe desarrollar software en caso de que no exista en el mercado uno que resulte suficientemente adecuado, y además sea crítico para la organización. Para defender esta opinión me gustaría que el lector pensara en los recursos de que dispone para desarrollar aplicaciones y los plazos que debería invertir para conseguirlo.

¿Son estos plazos razonables, teniendo en cuenta la velocidad a la que evolucionan los mercados? ¿Los responsables de la gestión los pueden soportar? ¿Tenemos los conocimientos y los recursos para hacerlo?, etc. Podría proponer más preguntas, pero considero que no es necesario, y menos en el entorno de Business Intelligence, en el que disponemos de una oferta de productos y de implementadores muy elevada. La alternativa que nos deberíamos plantear, una vez realizado el primer proyecto, es si hemos adquirido de nuestros proveedores los conocimientos necesarios para poder desarrollar los siguientes, contando con su participación en momentos puntuales, en caso de que no hayamos decidido externalizar completamente los proyectos de Business Intelligence.

Manipulador de Alimentos

Escoger aquella herramienta de Business Intelligence que mejor satisfaga las necesidades de los usuarios en cuanto a las funcionalidades, con la mejor arquitectura y al mejor coste, no es una tarea fácil; y mucho menos si tenemos en cuenta la cantidad de herramientas y proveedores disponibles (Ver Nota técnica 3 más adelante).

Un primer paso para elegir las herramientas de Business Intelligence tener en cuenta las características de los usuarios que tenemos en nuestra organización. Tenemos dos grandes perfiles: Los productores de información y los consumidores de información. La mejor manera para seleccionar una herramienta de Business Intelligence, según se afirma, es seguir una metodología e involucrar a las personas adecuadas en las distintas fases a lo largo del proceso. Buscar atajos al proceso raramente funciona. Puesto que las organizaciones invierten importes considerables en licencias, mantenimiento, servidores, formación, soporte y administración, es mejor llevar a cabo una cuidadosa evaluación. Por otro lado, no debemos sucumbir en la parálisis por un exceso de análisis. Los líderes de herramientas de Business Intelligence ofrecen herramientas razonablemente maduras que pueden cubrir las necesidades de las organizaciones.
El proceso para seleccionar la solución de Business Intelligence puede ser un proceso informal106 o formal. J. Wu define los dos procesos de la siguiente manera.

Comúnmente, las organizaciones no establecen un proceso formal de selección de software y, desafortunadamente, en la mayoría de los casos este procedimiento no produce los resultados esperados. Como he tenido ocasión de experimentar a lo largo de mi vida profesional, muchas veces se asigna un responsable de negocio que, aparte de sus obligaciones, debe seleccionar la herramienta; en otros casos, los responsables son miembros de los departamentos de tecnología.

En esta situación, el vendedor que haga la mejor demostración será el que consiga el proyecto. Es posible, por lo tanto, que una organización haya adquirido inapropiadamente un software porque no ha destinado los suficientes recursos en tiempo y dinero para seleccionar la solución. La elección de una solución de Business Intelligence no se puede tomar de cualquier manera: Algunas organizaciones se ven obligadas a cambiar de proveedor al cabo de uno o dos años. Los costes para la organización no son tan sólo los de adquisición de las licencias, sino también los del proyecto de implementación, que incluyen tanto los de formación de los usuarios como los de conseguir el conocimiento necesario por parte de la organización para que la solución sea utilizada. Debemos tener en cuenta el coste, los requerimientos funcionales y la arquitectura tecnológica.

Con un proceso formal de selección de software la probabilidad de seleccionar la mejor herramienta para la organización se incrementa sustancialmente. Su aproximación a la selección de software requiere de distintas tareas, que deben ser tratadas como un proyecto, con las siguientes etapas:

1. Inicio del proyecto:
1.1. Alcance y objetivos.
1.2. Equipo.
1.3. Comunicación del inicio.

2. Análisis de los procesos de negocio:
2.1. Comprender los procesos actuales y su información asociada.
2.2. Identificar las mejores prácticas que apoyan a los objetivos de negocio.
2.3. Análisis de las diferencias.
2.4. Desarrollar como deberían ser los procesos en el futuro.

3. Definir los requerimientos:
3.1. De negocio:
3.1.1. Presupuesto y plazos.
3.1.2. Requerimientos de información directiva.
3.2. Funcionales:
3.2.1. Estado de las necesidades de negocio.
3.3. Técnicos:
3.3.1. Estándares de sistemas.
3.3.2. Diagramas de fl ujo.
3.3.3. Interfases de sistemas.

4. Punto de decisión: Construir (¿realmente queremos construir la solución en lugar de utilizar uno de los productos disponibles en el mercado?) versus comprar.

5. Gestión de los proveedores:
5.1. Demostraciones.
5.2. Análisis de sus ofertas.
5.3. Ranking de las soluciones de los proveedores.
5.4. Negociación sobre las licencias y la implementación.
5.5. Contrato.

Podemos complementar la metodología propuesta por J. Wu con la propuesta por W. Eckerson y C. Howson:

1. Deberíamos constituir el Comité de Selección de la herramienta de Business Intelligence. Debería estar formado por todos los stakeholders de los distintos departamentos, incluído el de Sistemas de Información. En el Comité debería participar algún directivo que actúe como espónsor del proyecto. Si tenemos usuarios con experiencia deben participar en él. Para que sean efectivos, los comités deben estar compuestos por pocos miembros.

2. Definir los usuarios y los escenarios de uso: muchas organizaciones no se preocupan demasiado por los usuarios. Su foco es crear un Datamart o un informe, y no definir cuál es la información que se necesita y para qué rol y nivel de la organización. Se hace necesario definir quién interactuará con un informe y cómo, ya que los diferentes tipos de usuarios requieren distintas herramientas e interfaces. Comprender los segmentos de usuarios es crítico para gestionar el alcance en la selección y resolver los conflictos de los requerimientos. Siguiendo este proceso, puedes descubrir que distintos grupos de usuarios que tienen los mismos requerimientos quieren soluciones distintas.

3. Refinar los requerimientos de información: Cada herramienta de Business Intelligence soporta modelos y esquemas ligeramente diferentes, lo cual es crítico para incorporar los requerimientos en el proceso de selección. Por ejemplo, los usuarios quizás necesiten analizar las ventas con los inventarios para calcular
“inventarios por días de venta” de varios grupos de productos y periodos de tiempo. Este simple requerimiento se convierte en una serie de características técnicas:
1) multi SQL para consultar dos tablas del datawarehouse; 2) capacidad para agregar los inventarios por grupos de producto, pero no a través de periodos de tiempo; 3) suma automática de filas individuales de información para poder ver los totales del año o por grupos de productos. Las distintas herramientas de BI solventan estos requerimientos de formas absolutamente distintas. El Comité de Selección debe comprender las diferencias y saber qué aproximación será mejor para la organización.

4. Definir los criterios de selección y su peso. Hay varias metodologías para capturar los requerimientos de los usuarios: Entrevistas individuales, análisis de la diferencia o sesiones de tormenta de ideas. La clave, sin embargo, es trasladar los requerimientos a las capacidades de la herramienta de Business Intelligence.

Por ejemplo, es difícil que los usuarios digan: “Queremos una herramienta de BI con una capa de metadata”. Lo que probablemente dirán es que quieren crear sus propios informes sin necesidad de conocer su lenguaje. Los criterios más utilizados son viabilidad del vendedor, estrategia del vendedor, funcionalidades (en consultas, en informes, en entrega de información, integración con hojas de cálculo, cuadros de mando, administración, arquitectura, coste, formación y soporte). Deberemos priorizar cada criterio con un peso. Si se quieren consultar ejemplos de listas de criterios, se pueden consultar en www.BIScorecard.com

5. Solicitudes de información (RFI). Generan mucho trabajo para el vendedor y poco valor para el comprador; muchos vendedores dicen “sí” a todos los requerimientos. Para ser justos, algunos vendedores son más honestos que otros y los requerimientos están sujetos a interpretación. Por ejemplo, si necesitas una arquitectura tecnológica basada en Unix, los vendedores que no soportan Unix pueden ser eliminados. Para aumentar el valor del RFI, se deben incluir aquellos requerimientos que sean decisivos en la selección o en la estandarización: Preguntar cómo las herramientas específicas solucionan los requerimientos de los usuarios. Las preguntas abiertas, al final, pueden mostrar luz sobre la aproximación del vendedor y el interés que tiene por el proyecto. Los vendedores que atienden cuidadosamente las respuestas en lugar de los que utilizan material preparado y empaquetado por marketing son más validos.

6. Demostraciones: El Comité debe ver las distintas demostraciones de los proveedores y debe prepararse un orden del día para cada vendedor. En el orden del día debe disponerse de tiempo para hablar de las consideraciones estratégicas, así como de las capacidades del producto. Se debe invitar a usuarios que no participan en el Comité a las demostraciones para poder obtener su opinión y asegurar que han participado en el proceso de decisión, preguntándoles cuál es su valoración de la habilidad de los vendedores en cubrir sus requerimientos específicos.
Las demostraciones se pueden basar en los datos del vendedor o en los propios de la organización: El uso de los de la organización puede ayudar a comprender mejor las diferencias entre herramientas, aunque requiere una inversión en tiempo mayor para el vendedor y la propia organización. Esta alternativa vale
la pena si tenemos pocas alternativas, ya que si el número de productos es muy elevado no es demasiado práctica.

7. Determinar cuál es la herramienta que se ajusta más: Usando los requerimientos definidos en el punto 4, puntuar los criterios y las demostraciones; incorporar consideraciones estratégicas, información cualitativa e información de clientes de la herramienta para saber cuál de ellas y qué proveedor se ajusta mejor a corto y largo plazo a nuestra organización. Si la elección está clara, no se deben abandonar las segundas alternativas completamente: Debemos todavía probar el concepto, negociar el contrato o poner a prueba si nuestra primera elección tiene problemas insuperables.

8. Probar el concepto: Sólo deberíamos tener uno o dos proveedores posibles al llegar a esta fase. Es la oportunidad de probar la herramienta en nuestro entorno. Únicamente es una prueba, aunque en este punto es importante conseguir que el Comité esté centrado en los requerimientos críticos más que en jugar interminablemente con la herramienta o intentando crear informes. La prueba del concepto sirve para elegir entre las alternativas, su propósito es confirmar que el producto funciona como se espera. Para ello deberemos escoger un grupo de informes, limitando el alcance, para probar el concepto. Los informes de ejemplo pueden basarse en los requerimientos definidos en el punto 3 y que sean moderadamente complejos (se trata de que no sean simples listados, pero tampoco tan complejos que un programador experimentado tenga que destinar un mes completo para crearlos). La prueba del concepto nos dará la idea de cómo debemos adaptar el resto de nuestra arquitectura de BI, pero no es la clave definitiva para resolver los problemas de implementación.

Las dos metodologías planteadas tienen algunos puntos en común, pero tienen otros que se complementan perfectamente. Mi recomendación es que las adaptemos siempre a nuestras necesidades y entorno, ya que somos quienes mejor los conocemos. Una vez evidenciado que necesitamos una metodología para seleccionar una herramienta, debemos profundizar en los criterios de selección de las herramientas y de los proveedores. Para desarrollarlos voy a partir del material de un seminario que impartió Cindi Howson y Wayne Eckerson, en la conferencia mundial The datawarehouse Institute, en Boston (MA, EE.UU.) en agosto de 2003. Aunque en el seminario comparaban productos concretos, voy obviar los productos y a proponer el marco de análisis general. El primer componente a tener en cuenta sobre la selección de las herramientas es a quién van dirigidas: A los usuarios de Business Intelligence. ¿Cuáles son las funcionalidades que necesitan? Poder lanzar consultas, OLAP, informes dinámicos, informes estáticos, etc.

Los criterios que nos proponen son:

– Evaluar datos fi nancieros sobre del proveedor:

o Total de ingresos de productos de Business Intelligence /total de sus ventas.
o Ratio entre ingresos por servicios y licencias.
o Evolución de la venta de licencias.
o Resultado económico.
o Evolución de las acciones.
o Recursos destinados a Investigación y desarrollo.
o Estrategia de ventas.
o Fusiones, adquisiciones, etc.

– La estrategia del proveedor:

o Si tiene otros productos (por ejemplo de ETL, base de
datos propia, etc.).
o Cuando venden, ¿qué venden?
o Cuáles son sus principales competidores.
o Cuál es su origen y hacia donde van.
o Cuáles son sus diferencias respecto a los otros proveedores.
o Posibles evoluciones de la herramienta.

– La arquitectura tecnológica del proveedor.

o Arquitetura orientada a servicios (SOA112).
o Estructura común a través de todos los productos.
o Procesamiento en el servidor (o en cliente).
o Desarrollo por capas.
o Conectividad con terceros.
o Solidez del sistema.
o Escalabilidad y rendimiento.
o Alta disponibilidad.
o Que soporte estándar.

– Las funcionalidades de consultas:

o Proteger a los usuarios de las complejidades del motor de base de datos.
o Consultas ad hoc.
o Consultas totalizadas y detalladas.
o Seleccionar de listas.
o Acceder a distintas fuentes de datos.
o Impacto de las consultas en la base de datos.
o Complejidad del lenguaje de las consultas.
o Acceso desde cliente servidor o vía web.

– Las funcionalidades de informes:

o Estructura de los documentos y flexibilidad.
o Complejidad del documento (distintas fuentes de datos, tablas combinadas, gráfi cos).
o Formatos de tablas.
o Tipos de gráficos.
o Cálculos basados en el informe.
o Diseño del informe, formato rápido.
o Control de impresión.
o Formato contextual.
o Capacidades de navegación.
o Formato WYSIWYG113.
o Entrega de información:

• Planifi cada (tiempo, eventos, versiones, etc.).
• Formatos (Excel, PDF, HTML, etc.).
• Dispositivos (correo electrónico, PDA, impresora).
• Integración en portales.

– Las funcionalidades OLAP:

o Tipo de arquitectura114: MOLAP, ROLAP, HOLAP, DOLAP.
o Uso de particiones.
o Proceso de construcción de los cubos.
o Cálculos.
o Jerarquías alternativas.
o Análisis de atributos.
o Soporta otras fuentes OLAP.
o Valores en un momento del tiempo o agregados en un periodo.
o Navegar a detalle.
o Deshacer en análisis que pasaría si (What if).
o Posibilidad de crear funciones.
o Número de usuarios, dimensiones, etc.
o Pivotar cubos, arrastrar y soltar.
o Tiempo de respuesta.
o Cálculos a nivel de usuario.
o Utilizar jerarquías defi nidas y caminos de navegación.
o Ranking.
o Alertas y semáforos.
o Formatos de impresión.

– Las funcionalidades de administración:

o Autentifi cación de usuarios (LDAP, roles, basados en web).
o Construcción y mantenimiento del Metadata.
o Administración del servidor.
o Información y monitorización del uso.
o Entornos de desarrollo.
o Control de cambios.

– Los precios:

o Licencias (nominales, concurrentes, por servidor, por CPU).
o Mantenimiento (importe, actualizaciones y soporte).
o Soporte (niveles, importe, base de datos de incidencias).
o Importe para el proyecto concreto.
o Coste total de propiedad (TCO, “Total Cost of ownership”).

Hasta ahora hemos definido los criterios para la selección del producto de Business Intelligence, pero en todo proyecto de sistemas de información es tan importante la selección del producto como la del implementador. Tradicionalmente, en la evaluación de proveedores deberíamos tener en cuenta:

– Historia.
– Estabilidad y viabilidad financiera.
– Recursos humanos y de gestión.
– Cobertura geográfica.
– Servicios ofertados.
– Experiencia con el producto y en el sector.
– Experiencia con clientes afines.
– Metodología y herramientas de desarrollo.
– Productos y metodologías implementadas.
– Grado de confianza.

A estos criterios deberían añadirse algunos de los que propone Forrester Research:

• Especialización vertical.
• Facilitar la colaboración con otros proveedores.
• Flexibilidad para cambiar las necesidades del cliente.
• Soporte para la aparición de nuevas tecnologías o la innovación en los negocios.
• Casar los servicios ofrecidos con las necesidades de los clientes.

En este apartado vamos a relacionar, sin intención de ser exhaustivos, distintos fabricantes de soluciones de software que se pueden utilizar en proyectos de Business Intelligence y se han prestado a colaborar con la presente obra. Primero los productos comerciales y al final del capítulo herramientas Open Source.
También podemos referirnos a consultores independientes, como Gartner, para seleccionar las distintas herramientas de Business Intelligence. A continuación mostramos el Magic Quadrant de plataformas de Business Intelligence de Gartner117, en el que se clasifican las distintas soluciones.