Acceso

NOTICIAS

5 Consejos para una buena licitación de servicios SAP


Como proveedores de servicios SAP nos toca enfrentar muchos procesos de licitación. Nuestras experiencias en estos procesos son muy variadas, dependiendo de los términos en que se establecen las bases técnicas del requerimiento. Así, si bien en algunos casos es muy fácil elaborar una propuesta de valor que se ajusta a las necesidades del cliente, en muchos otros casos esto resulta sumamente difícil, e incluso, en casos extremos, es sencillamente imposible, y preferimos no participar del proceso.

A partir del cúmulo de experiencias acumuladas durante años, hemos ido extrayendo algunas conclusiones, sobre cuya base hacemos sugerencias que pueden ayudar a simplificar estos procesos, y a obtener mejores resultados. Aquí van algunas de ellas.

1. Exponga el problema, no la solución.

Si un cliente busca que su proveedor sea un socio tecnológico, que le aporte conocimiento, experiencia y valor, entonces debe exponer su problema y sus objetivos, y dejar que el proveedor proponga la solución. El cliente es el experto en su necesidad, y el proveedor debe ser el experto en la solución. De hecho, el proveedor debe ser evaluado a partir de la calidad de la solución propuesta.

Cuando el cliente expone una solución que definió que era la mejor para su problema, deja sin espacio al proveedor para aportar valor, y no permite que este conozca en detalle el problema. En estos casos es el propio cliente quien debe hacer el mayor esfuerzo para detallar los términos de la solución, y especificar una multitud de detalles. Muchas veces debe incluso contratar asesorías especializadas para este propósito. Esto introduce complejidad en el proceso.

Como resultado, tenemos un requerimiento con tal detalle, que el mismo cliente atrae a su proceso a todo tipo de proveedores, puesto que ya no es necesaria la experiencia ni el conocimiento. Así, el proceso se convierte en una compra de commodities, donde casi cualquiera puede participar, y el cliente obtiene muchas propuestas similares, sin poder discriminar entre un proveedor especializado, con productos o servicios de calidad, y un proveedor genérico.

Este es tal vez el principal obstáculo para obtener un aporte de valor del proveedor. Y además introduce complejidad innecesaria en el requerimiento y en el proceso mismo.

2. Compre servicios, no objetos.

Cuando se considera el problema del cliente, siempre la mejor solución será un servicio, y no un objeto (infraestructura o personas). En TI conocemos de sobra la filosofía ITIL, la que nos recomienda de entrada gestionar servicios hacia nuestros clientes finales.

Los servicios se pueden traducir directamente en resultados, no así los objetos. Por ejemplo, si mi objetivo es asegurar la continuidad de un proceso de negocio, puedo lograrlo por medio de un servicio de hosting de una solución, o por medio de un servicio de gestión de incidentes, ambos medidos según un SLA de disponibilidad, el cual refleja directamente el resultado que quiero obtener. En cambio, si defino que necesito una configuración de servidores en cluster tipo X, o que necesito tres consultores certificados en el módulo Y, ninguna de estas supuestas “soluciones” garantiza el resultado final.

Con esta filosofía, es el proveedor quien debe preocuparse de los detalles de la solución. Por ejemplo, cuál es la mejor configuración de hardware que cumple con el objetivo, al menor costo. O cuál es la mejor asignación de personas para lograr resolver los incidentes en el tiempo adecuado, con el costo óptimo.

Al comprar objetos, el cliente asume el riesgo de no obtener los resultados deseados. Al comprar servicios este riesgo queda del lado del proveedor, quien es (o debiera ser) el especialista en la materia.

3. Mida resultados finales, no acciones intermedias.

Si vamos a contratar servicios, es muy importante definir la calidad del mismo. Para esto se acuerda un SLA (Service Level Agreement). Este acuerdo debe establecer cuáles son los parámetros a medir para definir si el servicio está logrando los objetivos deseados. Los parámetros de calidad, o KPIs, deben ser simples (fáciles de medir), pocos (fáciles de gestionar) y deben reflejar lo más fielmente posible los resultados finales deseados.

Por ejemplo, si buscamos un servicio que asegure el rendimiento de un sistema transaccional, el mejor indicador es el tiempo de respuesta promedio, ya que expresa directamente el objetivo buscado. Pero si, en cambio, establecemos que vamos a medir el uso de CPU, el uso de memoria, el tiempo de lectura a discos, etc., estamos midiendo resultados intermedios, que no garantizan el objetivo final. Además estamos introduciendo complejidad, ya que pueden ser muchos indicadores, y supone mayores costos en la gestión de las mediciones, los reportes, los análisis, etc.

En varias licitaciones de servicios de administración SAP hemos visto una propuesta de SLA que consiste en una lista de cerca de 50 actividades de administración, cada una con su KPI de cumplimiento. Imaginemos el costo que supondrá gestionar ese servicio, para  que además toda esa gestión no garantice el resultado deseado.

4.No ponga incentivos para obtener servicios baratos y de mala calidad.

Cuando el cliente define la solución que desea, en vez de plantear el problema, normalmente establece sus requerimientos en términos de objetos muy específicos, con mucho detalle, y sin espacio a la creatividad (compra de commodities). De este modo, la única variable de la oferta es el precio.

Si al mismo tiempo el producto no está especificado en términos de resultados, se produce la combinación mortal y el cliente obtiene una oferta de la peor calidad al menor precio.

Por ejemplo, un cliente requiere un servicio de mejoras funcionales para su solución SAP. En su requerimiento establece que necesita 200 horas mensuales (en realidad está comprando objetos, no servicios). Si no establece ninguna métrica de calidad o de rendimiento, y solamente busca la oferta con las menores tarifas, estará seleccionando al proveedor de peor calidad y menor precio, o bien estará incentivando a sus proveedores a entregar un servicio basado en los consultores más baratos, con menor experiencia. Estos consultores demorarán más horas en hacer el mismo trabajo y, probablemente, entreguen un resultado de menor calidad.

5. Colabore con su proveedor.

Unas bases de licitación, por muy buenas que sean, nunca reemplazarán un ciclo de sesiones de trabajo cara a cara, entre el cliente y los proveedores.

Cuando las regulaciones impiden un proceso más informal y directo, aún es posible establecer mejores formas de conducir una licitación formal. Por ejemplo:

  • No haga sólo una ronda de preguntas y respuestas. Muchas veces la respuesta a una pregunta levanta mayores dudas, y ya no es posible volver a preguntar. La solución es hacer varias rondas de preguntas y respuestas, o bien establecer un foro donde las preguntas se vayan respondiendo de inmediato.
  • No responda en forma evasiva: “Remítase a las bases de licitación”. Se supone que las aclaraciones mejoran el proceso, conducen a una mejor solución y bajan los precios. Ante la incertidumbre, el proveedor sólo puede traducir los riesgos en mayores costos.
  • Permita que el proveedor sugiera cambios. El proveedor experto puede ayudar a corregir problemas o errores en las bases de licitación.

El mismo proceso de preguntas y respuestas permite al cliente evaluar las competencias de los proveedores participantes.

Más información de nuestros servicios en http://www.novis.cl.

Feedback/discusión con el autor: Glen Canessa - glen.canessa@noviscorp.com

 

 

imagenes boletines
Ver Boletines

SUSCRÍBETE A NUESTRO BOLETÍN

Suscríbete a nuestro boletín mensual para que estés enterado de todas nuestras noticias y nuevas tecnologías.

Suscríbete a nuestro Boletín Mensual diseñado para la comunidad SAP de Latinoamérica
Revisa las ediciones anteriores desde aquí