1. Guía para evitar que las demostraciones
de software sean un concurso de belleza
Si bien planificar el proceso de evaluación y selección es importante, las “demos” son la
oportunidad de ver un poco más allá del análisis del RFP (Request for Proposal). Si
no se hacen correctamente, la evaluación será más costosa, tomará mucho más tiempo, y
probablemente se transforme en algo similar a un concurso de belleza. Cuando
interviene la subjetividad y las promesas del proveedor influyen en la decisión final del
equipo de evaluación, prepárese una us para elegir a la más bonita pieza de software,
coronarla como reina y gastar el dinero en viaje, tratamientos de belleza, peinados y
maquillaje.
Es bien sabido que la selección del paquete de software incorrecto puede hundir a un
ERP, CRM o cualquier otra aplicación de software antes de estar en régimen de
producción. Puede minimizarse este riesgo realizando un proceso de evaluación
profesional y a conciencia. Existen una amplia variedad de herramientas y recursos para
ayudar a seleccionar software y proveedor/ implementador. Cómo seleccionar el mejor
software ERP para su empresa y no morir en el intento es parte de nuestro trabajo
de divulgación. Las demostraciones son una parte del proceso que, por falta de
preparación y gestión, pueden derivar fácilmente en la compra de un paquete malo o en
la elección de una empresa poco responsable.
Tal vez se haya preguntado: Las demostraciones de productos ERP’s ¿Para qué
sirven? y ¿Cómo aprovecharlas? Este artículo es una guía para manejar las
demostraciones con el fin de evitar que la seducción de los vendedores influyan en la
evaluación
Las demostraciones de software formales deben hacerse con una lista corta de dos o tres
productos. Como requisitos previos para iniciar las demos, se debe contar al menos con
una lista detallada de requisitos y claridad en cuanto a cómo analizar el ERP de un
proveedor.
Para complementar la lectura de este artículo, le recomendamos inscribirse al webinar
"8 claves para la selección de software ERP para una empresa". Para más información
pulse aquí.

2. Inscribirse aquí.
12 recomendaciones para manejar las demostraciones
de software.
1.
Hacer un plan de dos rondas de demostraciones de
software.
Esto debería ser tiempo suficiente para completar la evaluación
de la funcionalidad y atar cabos sueltos. Dependiendo de la
complejidad del proyecto y de su empresa, puede ser una
demostración integral, una demostración módulo a módulo o
solo de las partes claves del negocio.
2.
Establecer una agenda clara para cada sesión
(incluido un calendario para cada tema).
Trabaje con los vendedores para establecer el orden del día, pero
no deje que ellos establezcan las prioridades. Por lo menos en la
primera ronda de demostraciones, la agenda del día deberá ser
idéntica para cada proveedor, cualquiera sea el tipo de

3. demostración,. Además, es importante focalizarse primero en los
requisitos importantes que conducen a la decisión. Estos
incluyen requerimientos específicos y los que en las matrices de
evaluación tienen la más alta prioridad.
3.
Ofrecer al vendedor una actividad introductoria para
que le explique la navegación básica del software.
Esta actividad inicial permite al vendedor descargar su discurso
de ventas mientras demuestra la navegabilidad del producto,
despejando el camino para profundizar los aspectos que a usted
le interesa evaluar.
4.
Fomentar un ambiente de equidad.
Durante una ronda de demostraciones, el lugar de reunión y el
método de hacerlas, en la oficina de la empresa vendedora o
remota, debe ser el mismo para cada proveedor. Se trata de
nivelar el campo de juego. Si un vendedor realiza una
demostración en la oficina y otro hace lo mismo a distancia,
¿Quién cree que tiene la oportunidad de dejar la mejor
impresión? Esta impresión puede tener poco que ver con el
software. Aliente a todos los proveedores a ser anfitriones a la
hora de hacer sus demostraciones.
5.
Solicitar que los demostradores sean del equipo
titular.
Se trata de personas que realmente entienden el negocio,
conocen el software y, cómo mostrarlo. Si el demostrador no
está familiarizado con el software, el resultado puede ser que
buen paquete parezca insuficiente. Esto no necesariamente es un
problema del vendedor, ya que puede convertirse en el suyo si
se selecciona el software erróneo.

4. 6.
Educar al equipo sobre la forma de aplicar el método
de puntuación.
Hay una amplia variedad de criterios para la selección de
software empresarial y formas para hacerlo. La mayoría de los
métodos para evaluar la funcionalidad del software incluyen un
sistema de puntuación que cuantifica la medida en que el
software responde a una necesidad de negocio en particular. El
equipo tiene que saber cómo usar el método para calificar
adecuadamente lo que ven en el software y las respuestas del
proveedor a preguntas específicas. Independientemente del
método de calificación, si el vendedor prometió que cierta
funcionalidad estará disponible en futuros raleases o versiones,
pida ver la documentación de diseño para probarlo. Si esa
documentación no existe, no dé crédito a lo que el proveedor le
diga. Y si existe, dele un crédito limitado.
7.
Equiparar el juego de datos que se usan.
Si un vendedor utiliza para la demostración una muestra
representativa de datos de su negocio, asegúrese que el otro
proveedor haga lo mismo. De lo contrario, estará desatendiendo
la recomendación 4 y le dará a un vendedor una ventaja injusta.
Todos los vendedores saben que el uso de los datos de su
empresa para una demostración hace que su software sea
"menos extraño" o más atractivo para el equipo de evaluación.
Recuerde, esto no tiene nada que ver con lo que el software
realmente puede hacer.
8.
Asegurar que todos los vendedores realizan
demostraciones con la versión de producción del
software y en las tecnologías que normalmente lo
implementan.
Lo que se debe evitar son demos con el software, bases de datos
y otras tecnologías que no son representativos del producto real.
Aunque no es común, algunos vendedores modifican pantallas y

5. programas antes de las demostraciones para que parezca que el
software cumple con un requisito específico.
9.
Requerir al proveedor que demuestre la versión de
software a implementar (por lo general la versión
actual).
Cuando un vendedor quiere mostrar una versión anterior, podría
significar que la versión actual no está lista aún para trabajar
adecuadamente.
10.
Concientizar al responsable del proyecto de
evaluación sobre su rol como intérprete.
Aunque el vendedor y el equipo están hablando el uno al otro
durante la demo, esto no significa que se están comunicando.
Los vendedores y los usuarios provienen de mundos diferentes,
utilizan diferentes terminologías, y las palabras se pierden en la
conversación. Es el trabajo del responsable del proyecto de
evaluación garantizar la comunicación y el entendimiento.
11.
Otorgar el rol de árbitro al responsable proyecto de
evaluación.
Esto incluye garantizar la ejecución de la agenda del día, la
participación de todos los miembros del equipo de evaluación,
que el vendedor responda a las preguntas y demostrar el
software, no sólo hablar de lo que el producto hace.
12.
Realizar una reunión con todo el equipo presente,
inmediatamente después de cada demostración.

6. Deje tiempo al final de cada demostración para el equipo para
discutir lo que aprendieron, calificar el paquete, elaborar un
documento de preguntas cuando las capacidades del software no
están claras. Por supuesto, este segmento de la reunión no
incluye el vendedor. Cuando esto no se lleva a cabo
inmediatamente después de cada demostración, el equipo tendrá
inconvenientes para recordar lo que vieron. Además, dos
personas que asistieron a la misma demostración puede irse con
percepciones muy diferentes.
¿Tiene experiencia en demostraciones? ¿Se sintió engañado por la demostración de
software? lea lo que le pasó a Enrique y sepa como evitarlo.