Con frecuencia, la selección y evaluación de un software ERP es un paso que la empresa usuaria acorta y para el cual no se prepara adecuadamente, pero es uno de los más críticos. Para encontrar la solución óptima, y tomar una decisión confiable, debe considerar la mayor cantidad de opciones posibles. Con tantas soluciones disponibles, para el comprador de software es una tentación considerar solamente a los líderes de la industria o las primeras opciones que aparecen en los esfuerzos de búsqueda. Este atajo a menudo resulta en la pérdida de la solución ideal.

Un buen proceso de selección y evaluación de software ERP minimiza los riesgos de un proyecto fallido.

Hay una serie de recomendaciones para que el proceso sea ordenado y eficaz. Entre esas recomendaciones se pueden destacar las siguientes:

• Contar con un proceso formal.
• Definir de mayor a menor:
  • Escribir y consensuar los problemas o brechas de negocios que la empresa planea resolver.
  • Escribir qué procesos resolverán los problemas de negocios.
  • Escribir y consensuar cuál será la funcionalidad para soportar tales procesos.
• Conocer las propias limitaciones de la empresa.
• Asignar presupuesto: asegurar el dinero.
  • Métricas de interés.

A continuación se ampliarán cada una de estas recomendaciones.

Contar con un proceso formal

Un proceso formal es el camino más económico y el que da mejores resultados:

1. Diseñe la documentación que será necesaria para contar con el apoyo de los posibles proveedores.
2. Documente cuáles serán los criterios por los que evaluará y calificará a los proveedores.
3. Haga un plan de trabajo y coloque fechas estimadas.
4. Arme el equipo de colaboradores que trabajarán en el proyecto de evaluación y selección de un software ERP.
5. Revise los artículos de disponibles en internet. Hay mucho material que vale la pena conocer.

Definir de mayor a menor

Escribir y consensuar los problemas o brechas de negocios que la empresa planea resolver

Generalmente los problemas de negocios a resolver son brechas entre la situación actual y la deseada para alcanzar objetivos empresariales. Consensuar estas brechas, además de servir para la evaluación de un software ERP, sirve para sensibilizar a las gerencias sobre las necesidades de negocios de la compañía.

Escribir qué procesos resolverán esos problemas de negocios

Esto es una consecuencia del paso anterior.

Escribir y consensuar cuál será la funcionalidad necesaria para soportar tales procesos de negocios

Este es el máximo detalle al que se llega y es útil para luego puntuar y costear a cada uno los productos de software que ofrecerán los vendedores.

Conocer las propias limitaciones de la empresa

Evalúe si su organización cuenta con los recursos necesarios y suficientes para una implementación. Llegado el momento de la implementación, será necesario contar con las personas que más conocen de la empresa de manera poder implementar el software con la menor cantidad de dificultades. Será necesario reemplazar a esas personas por otras o re asignar tareas para que el trabajo del día a día no se resienta.

Asignar presupuesto: asegurar el dinero

Defina cuál es el presupuesto disponible y establezca cuál será el necesario. Esta definición parece ser una pregunta del tipo ¿Quién está primero, el huevo o la gallina? Sin embargo, a diferencia de la pregunta anterior que puede generar infinitas y bizantinas discusiones, la definición del presupuesto es más fácil. Hay 4 tipos de presupuestos cuyo propósito, tiempo, detalles y precisión pueden verse en el siguiente cuadro:

Algunas métricas de interés

Las siguientes cifras son métricas tomadas de una cantidad importante de casos. Son referencias que deben tomarse como tales y no como valores absolutos. El primer cuadro muestra las métricas por país, en tanto que la segunda tabla exhibe los valores por sector del mercado.

Referencias: ABPU – Average Budget per user: Surge como promedio de presupuesto previsto por usuario del software

Definir prioridades

Como la evaluación es la clave para la selección de un software ERP, es fundamental sacarle toda la subjetividad que sea posible y ejecutar un proceso lo más objetivo posible. Antes de comenzar la interacción con los proveedores, es recomendable tener definidos los criterios con los cuáles se dará por aceptable una propuesta de proyecto. Y observen que no se ha escrito propuesta de software sino propuesta de proyecto. Es conocido que el llamado “proyecto ERP” no se compone sólo de un producto de software. Al menos hay cuatro evaluaciones o ejes que deben considerarse como paso previo a la selección de un ERP: funcional, técnico, empresa proveedora y económico. Estos cuatro ejes se los puede llamar el nivel 1 o nivel mayor de la evaluación de un software ERP.

Si a cada uno de estos ejes se le asigna una puntuación o ponderación de manera tal que la suma de todas las puntuaciones sea 100, se estará definiendo cuál es la importancia que cada uno de esos ejes tiene respecto del otro. Los siguientes ejemplos muestran dos tipos de proyectos diferentes:

Obsérvese que en el proyecto A, la empresa que ha decidido las prioridades, definió que el eje funcional es el más importante. Es decir, esa compañía está diciendo “nuestra prioridad es solucionar los problemas de negocios que nos aquejan y estamos dispuestos a pagar por ello”. Este mensaje surge al leer la importancia relativa de los ejes funcional (40%) y económico (30%). En cambio en el proyecto B, la compañía está diciendo “estamos dispuestos a hacer ciertas concesiones en el aspecto funcional pues tenemos un presupuesto acotado y debemos respetarlo”. Esto se ve claramente al comparar la importancia relativa de lo funcional (30%) y lo económico (45%).

Relación a las empresas proveedoras

Si bien en la mayor parte de los proyectos de evaluación y selección a la evaluación de la empresa proveedora se le asigna la tercera o cuarta importancia relativa, es necesario saber que la selección de un proyecto de software implica convivir con un proveedor 5, 7 o tal vez 10 años. Por eso, se incluyen algunas guías para evaluar a la firma que será proveedora.

Antes de tener a mano una “lista de corta” haga una lista larga de posibles proveedores e invítalos a responder una serie de preguntas para que usted pueda recabar información sobre ellos.

• Solidez del proveedor. La compañía que le ofrece el producto debe tener una posición financiera sólida.
• Tecnología implícita. Algunos productos conocidos llevan muchos años en el mercado y parecen una buena elección. Sin embargo, análisis detallados revelan que están basados en tecnología antigua y limitada.
• Amplio número de clientes. Una base de datos de clientes pequeña no proporciona los suficientes ingresos para depurar el producto y mantenerlo.
• Código estable. Los proveedores en la lista deben tener una reputación de código limpio y estable.
• Canal de distribución bien desarrollado. Los distribuidores deben tener un conocimiento completo del producto.
• Buenas posibilidades de personalización.
• Amplia gama de módulos. Enriquecer los productos con una gama variada de módulos para evitar tener que sustituir el sistema cuando la empresa crezca.
• Fácil de utilizar. La formación es un costo de implementación muy elevado.

Hay instancias en los que se puede convocar a la lista larga de proveedores para luego pre seleccionar un grupo más pequeños. Estas instancias se asocian a dos documentos que se verán en el siguiente punto.

Preparar los documentos necesarios antes de comenzar

RFI (Request for Information)

Una solicitud de información RFI (Request For Information) es una propuesta solicitada a un vendedor, potencial proveedor para determinar qué productos y servicios están potencialmente disponibles en el mercado para satisfacer las necesidades de un comprador y conocer la capacidad de un vendedor en términos de oferta y fortalezas. Las RFI son de uso común en las principales adquisiciones, cuando este requisito podría potencialmente ser satisfecho a través de varios medios alternativos. Una RFI, sin embargo, no es una invitación a presentar ofertas, no es vinculante para el comprador o el vendedor, y puede o no conducir a una RFP o RFQ.

Las respuestas de los proveedores al RFI, deberían contener datos de la empresa proveedora, del implementador, de clientes, de experiencia en el rubro o industria de su compañía y si es posible que el proyecto que el proveedor planteará se encuentre en el rango de presupuesto que usted definió.

RFP (Request for proposal)

Como en otros órdenes de la vida, usar el sentido común es un buen punto de partida para decidir el uso de una FRP. Por ejemplo, la emisión de un documento para la compra de lápices y otros suministros de oficina es innecesario. Las RFP se emiten con más frecuencia para los productos y servicios complejos, altamente personalizados. Un ejemplo de este tipo es un rediseño página web en la que el proyecto que cuenta con numerosos requisitos e implica varios tipos de conocimientos . Para los productos y servicios más simples, las organizaciones distribuyen una Solicitud de Cotizaciones (RFQ). Se trata de una petición de oferta que es más corta y que requiere menos mano de obra que una RFP.

Evalúe y compare la información dada por los proveedores. Utilice un primer filtro para dejar en carrera entre 4 y 6 proveedores. Las respuestas al RFI le ayudarán a hacer un primer filtro y pre seleccionar un grupo de compañías con las cuáles profundizará el trabajo. Distribuya documentación específica del proyecto entre esos 4 a 6 proveedores, con preguntas y tareas específicas. Utilice un método de evaluación y puntuación objetivo para calificar las propuestas de los proveedores. Siga su plan formal de trabajo. Las respuestas de los proveedores al RFP serán la base para la preparación de la demostración y comparación de propuestas.

Qué no debe faltar en una RFP

• Especificaciones de producto o servicio requerido, con el mayor detalle posible.
• Información que se requiere del oferente. Por ejemplo: precio, personas que liderarán el proyecto, responsabilidades, cronograma, antecedentes.
• Criterios para selección o descalificación de los proveedores.
• Fechas claves. Por ejemplo, apertura/ cierre del proceso, visitas a instalaciones, demostraciones, reuniones.
• Requerimientos de confidencialidad.
• Modelo de contrato con el que se efectuará la contratación.

Por la División consultoría de Evaluando ERP