En el mercado de los ERPs, la mayoría de los vendors ofrecen garantías de 30 a 90 días contados a partir de la fecha de entrega de la licencia. Este lapso de tiempo no alcanza a veces para cubrir el tiempo que dura la implementación de la aplicación.

Considerando que la garantía es el único escudo que tiene el cliente para exigir el cumplimiento del proyecto de acuerdo a lo pactado, nos preguntamos ¿Cómo puede vencer una garantía antes de que el software pueda ser usado o probado? ¿Qué es la garantía de un ERP?

Como es común en este tipo de industria, vencida la garantía, comienza a regir el período de mantenimiento, es decir que el cliente debe tener abonado ya el Fee -que es el Cargo Anual de Mantenimiento- para no quedarse sin cobertura. Entonces, ¿Desde cuando debe comenzar a regir y por cuánto tiempo debería tener vigencia la garantía de un ERP?

A continuación, detallamos las interesantes opiniones arrojadas por especialistas en la temática de la gestión empresarial y la utilización de tecnologías, en un debate on line que se produjo entre integrantes de diversos grupos de profesionales ante estos interrogantes.

Según Ricardo Casella, Gerente Comercial en Sistemas Bianchi S.A., “Es muy importante dejar aclarados todos estos temas en el momento de cerrar una operación y deben ser incluidos en los documentos que respaldan la misma. En ellos, el cliente debe recibir información relevante sobre las particularidades de nuestro negocio, las responsabilidades de las partes y las características salientes de la relación que establecemos con ellos. Si esto no sucede, nos encontramos con un cliente que siente que no le dijimos todo lo que debíamos, justamente en medio de un proceso de implementación, lo que genera desconfianza en el proveedor, y objeción innecesaria que debemos administrar y refutar.

Sin embargo, estimo que las preguntas esconden una pequeña trampita, ya que tal como están planteadas, es difícil llegar a una solución. El dilema es que no podemos obtener un resultado de suma cero, si los componentes de la ecuación no son equivalentes.

Entonces, comencemos a despejar

La garantía que generalmente se ofrece en nuestra industria, es de 90 días. ¿Que cosa cubre esta garantía?: defectos en el producto. ¿Cuál es la responsabilidad del fabricante?: reemplazar el producto si se verifican fallas (siempre y cuando el usuario haya respetado las especificaciones indicadas por el fabricante).

Si quisiéramos poner más foco el alcance de la garantía, podríamos decir que el producto instalado, debe ofrecer la misma funcionalidad que se describe en los manuales de uso.

Otro tema es la implementación

Para que el usuario obtenga una productividad razonable de la aplicación, la misma debe estar debidamente implementada. Si el cliente está dentro del período de implementación del proyecto, no debería tener necesidad de acceder a los servicios de soporte, ya que no puede considerarse un usuario en régimen aún.

Nos queda el Fee de Mantenimiento

Generalmente este servicio no es obligatorio, salvo que así se exprese en el contrato, (modalidades ASP, por ejemplo). Incluso encontramos vendors, que tercerizan los servicios de mantenimiento, razón por la cual, este Fee debe considerarse independiente de los contratos de licencias de uso convencionales.

En conclusión

  1. La garantía de fabricante debe ser por 90 días.
  2.  Durante el proceso de implementación el cliente solo debe interactuar con los consultores asignados al proyecto y el costo del mismo, debe cubrir todos los gastos internos que permitan la rentabilidad del mismo: Por ejemplo en implementaciones prolongadas, el porcentaje de Fee que está relacionado con las actualizaciones de versiones.
  3. Solo cuando finalice el proyecto de implementación y el cliente esté en régimen, debe comenzar a pagar el Fee de Mantenimiento.”

Para Jorge Labate, Director en Solutio IT, “El caso planteado es bastante común en nuestro mercado, ya que estamos ante un producto en el que la puesta en marcha tarda mucho más que los periodos de garantía otorgados y no siempre se aclaran estos asuntos al momento del contrato. Para analizar el problema hay que ver quien es el encargado de implementar el software (si es la software factory o un partner) y quien garantiza el producto. En el caso de que implemente un partner, se debe evaluar el acuerdo marco entre el proveedor del ERP y el partner que se encarga del proyecto.

El periodo establecido es de 90 días corridos a partir de la puesta en marcha -tiempo suficiente para que el cliente use y pruebe el sistema en toda su magnitud- siempre y cuando no se agreguen desarrollos de terceros, cambios de configuraciones, upgrades o cualquier modificación que altere el contexto en el cual fue instalado el producto. En ese caso la garantía expira automáticamente.

Se debe garantizar el buen funcionamiento de la aplicación, tanto la funcionalidad estándar, como los módulos y reportes implementados a medida. Lo que haya sido aprobado y aceptado por el project leader (por ej. capacitaciones, definiciones, impresiones, etc.) no pueden ser motivo de reclamo en el periodo de garantía.”, explica Jorge.

Daniel Aisemberg, Director de Evaluando ERP, en relación a la respuesta planteada por Ricardo Casella, añade que “Con respecto a que la garantía debe ofrecer la misma funcionalidad que los manuales de uso, creo que es la forma más clara (limpia) de fijar los alcances. Sin embargo, me parece que el desarrollo de los productos va más rápido que la actualización de los manuales. Incluso, en el 80% de los casos, los vendors no tienen un único producto, sino que poseen la versión única con los features de tal o cual cliente (aunque la mayoría lo niegue públicamente). En esos casos ¿De qué documentación se hablaría ¿La del producto estándar o la del cliente? Con relación al Fee, asumiendo que, no es obligatorio, la empresa compradora (el licenciante) estaría perdiendo muchos beneficios por no abonar el Fee. Uno de ellos, la actualización de la versión o el acceso a nuevas versiones o la corrección de BUGS una vez finalizado el período de garantía. Por lo que creo que es casi obligatorio contratar el Fee.

Con respecto al tema de cuándo debería comenzar a abonarse el Fee, esto tiene estrecha relación con el período de garantía. Me parece que una vez vencida la misma el cliente debería comenzar a pagar el Fee. La pregunta del millón es ¿Cuándo vence la garantía? o lo que es lo mismo ¿Desde cuando comienza a correr el período de garantía? Si el inicio de la misma es al momento de finalizar el proyecto de implementación, veo dos problemas:

  1.  Los proyectos en los que la obtención del certificado de conformidad se demora eternamente por razones atribuibles al usuario.
  2. Supongamos que damos por cierta la premisa que la garantía comienza a regir al finalizar el proyecto. Durante el período de implementación (no menos de 3 meses para software empresarial) el cliente no abona Fee (pues está en garantía). Es decir, que está cubierto de fallas o BUGS. Pero mientras se está implementando el software, el vendor libera una actualización. Por ejemplo la versión licenciada por el cliente es la 3.4.0 y el vendor libera la 3.4.1 que corrige algunos BUGS e incorpora nuevas funcionalidades. En teoría, el cliente no tendría acceso a esa actualización, pues no está abonando el Fee.

Para este segundo caso, distinto hubiera sido si la garantía hubiera sido de 3 meses a contar desde la entrega de la licencia, vencida la misma el cliente debe abonarse al Fee. Además, agrega Daniel, “existe otra situación conflictiva: la mayoría conoce la diferencia que hay entre los siguientes términos o actividades de un proyecto:

  • Instalación del software.
  • Capacitación en el uso del software.
  • Implementación del software.
  • Puesta en marcha del software, o puesta en producción o Go Alive.

Las primeras tres son una responsabilidad del vendor (o de la empresa implementadora) y de la empresa, mal llamada, compradora. El software implementado es el software en condiciones de ser puesto en marcha (o en producción).

Mientras que la puesta en marcha es una responsabilidad del cliente, pues es él quien decide en qué momento “baja la palanca” del software viejo y levanta la del software nuevo. ¿Y si por razones de cualquier índole el cliente no decide la puesta en marcha? ¿Qué pasa con la garantía? ¿Que pasa con el Fee? ¿Dónde termina el proyecto? ¿En la implementación o en Go Alive? La respuesta no es un tema menor, pues hay mucho dinero de por medio. Un proyecto sin final y con garantía vigente desde la puesta en marcha, significa que el cliente puede reclamar por tiempo indefinido por los BUGS que aparezcan y, como está en garantía, no paga Fee. Me pregunto, ¿Que clase de servicio podría darle el vendor a un cliente así?

Ricardo vuelve a participar del debate y manifiesta que “Estoy de acuerdo con Daniel en el alto grado de conflictividad de estas situaciones en nuestro negocio. Obviamente que, para nosotros, es fácil establecer la secuencia lógica del start-up de una aplicación, pero para el usuario, no lo es tanto.

Como dice Daniel, el cliente es participe necesario del proceso de implementación de un sistema, razón por la cual, en mi entrada anterior, decía que es necesario establecer con claridad las responsabilidades de cada uno, y si fuera el caso, incluir penalidades por la demora en bajar la palanca.

Con respecto a la garantía, lo que digo es que la misma debe estar referida al producto y debe tener un plazo (por ejemplo, 90 días). Si extendemos la garantía a la satisfacción del cliente relacionada con la implementación de la herramienta, estamos en un problema. El cliente no sabe (y probablemente no tiene como saberlo), cuando se debe dar por finalizado un proyecto de implementación. No tiene forma de medir la productividad de su aplicación y solamente con la intervención del proyect leader, quien le demostrará que se han alcanzado los objetivos, se logra la conformidad del cliente y se da por terminada nuestra tarea.

Es un tema muy difícil de abordar ya que las diferentes características de los productos que ofrece el mercado, obligan a distintas soluciones, orientadas a no perder rentabilidad en las operaciones. En aquellas aplicaciones que requieren periodos largos de modelización, que dan como resultado sistemas muy personalizados, las fronteras entre los temas que tratamos, se hacen algo difusas y requieren un seguimiento muy estricto de los cronogramas, en términos temporales y de objetivos. En cambio, en las soluciones más estandarizadas, es un poco más fácil.

La capacidad de estandarizar soluciones, posibilita también empaquetar los servicios relacionados con la puesta en marcha de los sistemas, lo que viabiliza el cumplimiento de los plazos previstos en cada proyecto y garantiza la satisfacción del cliente, -que se ve reflejada en los porcentajes de adhesión al Fee de mantenimiento en un 96%- que nos permite recibir, como muy bien lo pregunta Daniel, recursos para ofrecer servicios con un buen estándar de calidad”, concluye.

Veamos ahora la mirada de un consultor. Juan Navarro, Consultor de IT en Delphin, opina que “Si eres un revendedor de software, la garantía viene dada por el fabricante del software, al igual q las condiciones. Si, por el contrario, la licencia es sobre un software propietario, la defines en función de una estrategia. A partir de ahí, hay varias combinaciones con los servicios de mantenimiento.

Por otro lado, y para citar el ejemplo de una legislación diferente, si bien desconozco la legislación al respecto, una simple reparación tiene establecida por ley en España 6 meses de garantía, por lo que creo que no debe ser inferior la garantía para la venta (o reventa) de software. Independientemente de lo que se haya firmado, siempre se aplica la ley si ésta es favorable al cliente.

A parte, el error en este caso ha sido durante el seguimiento y la planificación del proyecto. Cualquier implantación, por pequeña que sea, necesita 6 meses de incorporación y otros 6 meses de asentamiento. Una de las premisas de éxito es que el cliente no se sienta abandonado durante ese primer año.

Y como corolario, me gustaría decir una frase que alguien me dijo una vez:
Un contrato solo es últil si lo dejas en una estantería y no lo necesitas en el resto de la implantación, sintetiza Juan.

Xavier Mauricio, Director de TIC en SAP Universidad BCN nos comparte otra frase y nos cuenta que “Una vez, uno de mis primeros jefes, director de proyecto, me dijo: solo existe un proyecto que nunca dura más de 9 meses: el embarazo. Dicho esto, creo que, la garantía debería empezar a computar justo después de la aprobación por parte del equipo de proyecto, y la validación por parte de los User Keys del cliente.

Se debe tener en cuenta que algunos procesos de las compañías no se explotan hasta mucho tiempo después de la implantación o, en algunos casos, pueden ser procesos cíclicos que, para el periodo de arranque y/o por calendario, no se ejecutan en modo explotación.

Por este motivo se deberían realizar pruebas de estrés y validación, no tanto por parte del implantador si no por parte del cliente y, repitiendo lo ya dicho, tanto el cliente como el implantador deben dar el ok a la implementación, por supuesto, dentro de unas metas/objetivos ya definidas y acordadas en el contrato firmado.

En cualquier caso, el comprador debería –siempre- saber en detalle los puntos del contrato, de la licencia, así como el del proyecto. Y en el caso de que no se expongan las garantías u otros condicionantes, como el marco y alcance de la garantía, debería exigirlo.

Y, reafirmando lo dicho por Juan, “el mejor contrato, es aquel que se queda para siempre en el archivador”.

Por la División consultoría de Evaluando ERP.

 
Share This
Suscríbase a nuestras novedades

Suscríbase a nuestras novedades

¿está interesado en nuestros contenidos de ERP? Suscríbase para nuestros newsletter y no deje de estar informado.

¡Listo, ya está suscripto!