Uno de los mayores problemas de la implementación de Business Central tiene que ver más con la metodología de implementación que con la complejidad del ERP o del negocio.
Esto afecta en gran manera el resultado ya que en ocasiones se crean expectativas en el cliente las cuales no se cumplen en su totalidad.
Se debe entender que la metodología incluye los procesos desde el inicio de la venta, muchos olvidan eso o no lo saben por lo que no se integran procesos super necesarios al momento de evaluar el tamaño y modelo de la solución. En gran parte de los partners, el criterio comercial prima sobre el criterio técnico y el resultado son proyectos con una gran cantidad de cambios en el alcance o con un alcance tan abierto que todo puede ser modificado; es importante aclarar que eso no es malo, pero si debiera estar puesto por escrito y el monto del proyecto debe ser equiparable al tamaño de requerimientos y riesgo incluido.
Un ejemplo son las ventas donde el cliente pide un sistema de “control de envíos”, o la “integración de un punto de ventas web”; el deber ser seria analizar a fondo la petición (dado que sabemos que Business Central no tiene un control de la mercancía una vez que esta ha sido facturada) y definir desde el principio cual será el alcance, que operaciones estarán cubiertas, como se realizara el desarrollo además de tiempo y el costo de ese desarrollo claro está. La solución normalmente es “agrega una bolsa de horas” por parte de la dirección comercial (“se tiene que vender para alcanzar las metas”).
En la metodología se cuenta con una fase de diagnostico que incluye un proceso de revisión de requerimientos y procesos, a eso, sumémosle que también el Fit Gap está en esta fase
La pregunta es:
¿Por qué siendo parte de una metodología probada, los partners no siguen estas recomendaciones?
El propósito de la revisión de procesos y requerimientos es claro:
“Identificar y/o revisar los requisitos de alto nivel y los procesos empresariales seleccionados que deberían estar dentro del alcance de la implementación de la planificación de recursos empresariales (ERP)/gestión de relaciones con clientes (CRM) del cliente. El objetivo de esta actividad es identificar y documentar la mayor cantidad posible de requisitos del cliente, especialmente funcionales y no funcionales (es decir, técnicos), y cualquier requisito de integración e interfaz que será un factor importante a considerar para la evaluación y la decisión del cliente sobre la solución ERP/CRM.”
La definición del Fit Gap también está bastante bien definido:
“Determinar el “grado de adecuación” entre los requisitos empresariales del Cliente y los sistemas existentes y su nuevo producto Microsoft Dynamics, configurando y personalizando así el producto para satisfacer las necesidades específicas del Cliente. Los resultados que se entregan al final de este compromiso son una estimación del “grado de adecuación” y un informe de brecha de adecuación y plan de solución que describe en una terminología empresarial fácil de entender cómo se puede utilizar el producto Microsoft Dynamics para satisfacer mejor las necesidades definidas.”
Entonces, estos dos procesos deben ser los principales en una venta, pero generan mucho roce interno en los partners cuando se realizan de manera correcta dado que implica invertir tiempos y limitar alcances lo que causa que el área comercial piense que se esta limitando su capacidad de vender lo que sea, que se encarece la venta y que se “espanta” al posible cliente con tanta restricción y limitación que puede perderse la venta.
Otro punto importante es quien realiza la venta.
Normalmente, en cualquier partner tenemos al vendedor y un consultor que presta operaciones para realizar la preventa (demo) así como un cuestionario que se envía al cliente para que lo responda.
Algunos otros partners (los menos) pueden contar con arquitectos de solución o preventas que realicen la demo (no siempre) y que efectúen una serie de preguntas para tratar de determinar que se requerirá en el proyecto.
Con la información que se recaba, se trata de definir lo que se deberá realizar, que cosas se incluirán y en la gran mayoría de los casos, el grado de incertidumbre por el desconocimiento del cliente y/o los procesos del negocio del cliente el cual se pone como bolsa de horas para desarrollos (entre mas grande la bolsa, mayor el desconocimiento).
Finalmente, se debe realizar una cotización o propuesta al cliente donde normalmente el enfoque es la parte bonita para tratar de minimizar los precios, esto implica poner lo que se ofrece y la gran mayoría de los vendedores prefieren lo que se hará a grandes rasgos sin poner lo que no se incluirá para que el cliente no sienta que se le está limitando.
Y justo ese es el gran error.
La venta de la implementación de un ERP es un contrato entre dos partes donde una empresa requiere un servicio y la otra se compromete a dar ese servicio, por lo tanto, como en cualquier contrato, lo que no esta expresamente negado está aceptado y basándose en este principio de legalidad, si no hay algo en el contrato entre las partes que establezca un limite al alcance de los trabajos, estos deberían ser realizados a total satisfacción de la parte contratante.
Por eso, la propuesta debe incluir tanto lo que esta incluido en el alcance como lo no incluido, se deben detallar los desarrollos y su alcance, así como las interfaces con otros sistemas si los hubiese, delimitando tanto lo que se podrá integrar como el flujo de integración.
Lógicamente, para que el partner pueda cubrir estos puntos, además de utilizar parte de la metodología de SureStep, también deberá tener el personal con el conocimiento necesario para poder efectuar tanto el análisis, como la propuesta de solución y darse el tiempo suficiente para analizar las necesidades del cliente
Leave a Reply
You must be logged in to post a comment.