Al implementar soluciones complejas, particularmente en el área de business intelligence, los clientes a menudo se topan con el problema de la ‘suposición de herramienta’. Aunque por lo general no se discuten en estos términos, los productos avanzados de BI se pueden ver como herramientas de desarrollo rápido que minimizan la necesidad de conocimientos técnicos. Trabajan al limitarse a un tipo específico de aplicación. Esto implica hacer suposiciones sobre qué tipo de datos se procesarán y cómo se procesarán.
La dificultad que surge es que las suposiciones hechas por el diseñador del producto apuntan a un mercado bastante general, lo que significa que los productos pueden hacer muchas cosas impresionantes muy bien, pero no necesariamente cumplen los requisitos específicos de cada cliente individual.
Desafortunadamente, las mismas características que hacen que este tipo de producto sea tan conveniente de usar de la manera en que fue diseñado para ser utilizado, tienden a dificultar su uso de cualquier otra manera. En otras palabras, cuando el vendedor dice en su presentación “Todo lo que necesita hacer para definir este tipo de informe es presionar este botón”, a menudo implica que no hay una manera conveniente de definir informes que son algo diferentes.
El software de business intelligence ha recorrido un largo camino, pero la compensación entre conveniencia y flexibilidad aún existe. Un escenario típico es que un cliente ve una presentación de un producto y compra el producto porque está convencido de que básicamente cumple con sus requisitos. Y en el proyecto, resulta que el producto realmente cumple con casi todos los requisitos. Pero a medida que avanza el proyecto, se descubre un detalle tras otro donde el producto no funciona del modo que el cliente esperaba.
Además del rendimiento, la mayoría de los problemas de calidad y los excesos de precios en los proyectos de business intelligence son el resultado de problemas aparentemente pequeños que la plataforma de software no puede abordar, y tienen que tratarse con soluciones complejas. El cliente deberá aceptar estos sobrecostos o comprometer sus requisitos.
Para evitar este problema, es aconsejable llevar a cabo un taller formal de prueba de concepto. Aquí, una breve lista de proveedores recibe un conjunto de escenarios basados en datos reales y se les pide que implementen un proyecto pequeño.
Una prueba de concepto debe incluir lo siguiente:
- Una lista de requisitos para los vendedores.
- Un conjunto de escenarios que los proveedores pueden implementar en un día o dos, que debe incluir los requisitos.
- Una presentación final de los proveedores a los usuarios finales.
- Un cuestionario para los usuarios finales que les permita dar su opinión de los resultados.
Al realizar una prueba de concepto, no olvide lo básico. Por ejemplo:
- Aproximadamente dos tercios del tiempo dedicado a un proyecto típico de BI se gasta en la importación de datos. Asegúrese de que los proveedores puedan importar sus datos.
- Los proyectos de BI a menudo tienen dificultades porque el producto se encuentra con problemas técnicos o de seguridad en el sitio del cliente que el proveedor no anticipa. Permita medio día o más para la instalación.
Si el proveedor u otros implementadores externos llevarán a cabo el proyecto, también tiene sentido verificar sus habilidades técnicas y de comunicación. Esto es vital para el éxito del proyecto.
Lo más importante es asegurarse de que la prueba de concepto le ofrezca algún tipo de cierre: cuando termine, sin importar cuáles sean los resultados, debe estar en una mejor posición para tomar una decisión final sobre qué proveedores eliminar de la lista y cuáles mantener.
Fuente: BARC-Research.
Traducido y adaptado por la División consultoría de EvaluandoSoftware.com