Una de las decisiones más críticas que toman las empresas desde el punto de vista de IT sucede cuando tienen que afrontar un cambio importante o adoptar una nueva tecnología para mejorar su negocio. En este momento, hay 2 procesos que juegan un papel vital para el éxito del proyecto: RFI (Request for Information) y RFP (Request for Proposal).
Antes de analizar las claves de cada uno de ellos, hay que destacar que mucha gente tiende a asociar estos dos procesos con grandes adquisiciones o cambios, con proyectos muy grandes. Nada más lejos de la realidad. La complejidad de los mismos únicamente tiene que ver con las necesidades del negocio. Simplemente son procesos ordenados que permiten comparar peras con peras y manzanas con manzanas.
RFI (Request for Information)
Se trata de lanzar una solicitud de oferta de alto nivel a diferentes proveedores para obtener una respuesta también de alto nivel. De esta forma este proceso trata de darnos una idea orientativa de 2 conceptos muy importantes hoy en día:
- Fabricantes o proveedores que pueden asumir el proyecto
- Orden de magnitud del coste
Desde luego es totalmente opcional, dependerá de nuestro conocimiento del mercado y si hemos hecho proyectos similares con anterioridad.
Para maximizar la efectividad de esta parte hay que cumplir varios objetivos:
- Detallar los requisitos de alto nivel: no hace falta ir al detalle total del proyecto sino poner mucho énfasis en los objetivos del mismo
- Indicar volumetría: de nuevo no hace falta tener todos los números en detalle sino dar un orden de magnitud, sobre todo de clientes que afectarán al sistema y de usuarios que lo utilizarán
- Destacar la prioridad de cada uno de los requisitos. Detallar qué es clave permitirá centrar mucho más el tiro a los proveedores
Siempre tendremos que mantener en nuestra mente que al final los proveedores saben que detrás de una RFI nunca hay un proyecto directamente. Normalmente detrás de una RFI hay una RFP y ahí tendrán que competir con otros proveedores. De esta forma, tengamos muy en cuenta el objetivo de una RFI cuando la estemos redactando para obtener las respuestas adecuadas.
Pero pongamos un ejemplo que ilustre el caso: imaginemos que queremos ampliar el número de canales de atención que tenemos buscando la omnicanalidad. Pongamos que atendemos el canal de voz y queremos añadir: chat, mail y redes sociales. La primera idea que se nos viene a la cabeza es que lo más barato, y normalmente lo más óptimo, sería ampliar el sistema actual para incluir estos nuevos canales.
En cualquier caso, si tomamos esta decisión sin consultar el mercado, puede que nos estemos perdiendo productos que ya trabajen todos los canales de forma omnicanal, posibilidades de transferencia de clientes intercanal, blending multicanal, etc. Además, créanme, no siempre ampliar una infraestructura existente es más económico que plantear una transición a un nuevo sistema.
RFP (Request for Proposal)
Este proceso consiste en lanzar una solicitud de ofertas a varios proveedores, pero con una estructura muy concreta que nos permita hacer un análisis comparativo de forma sencilla.
El objetivo de esta parte es obtener ofertas similares para poder hacer un análisis lo más objetivo posible. Este punto es el más complicado de una RFP y debemos hacer especial hincapié en ello.
Para llevar a cabo este proceso debemos redactar un documento que cumpla con los siguientes requisitos:
- Debe contener un detalle inicial con los objetivos del proyecto. Es importante hacer un esfuerzo en esta parte ya que será lo primero que vean los proveedores y debe darles un resumen claro y conciso de lo que esperamos con la adopción de la tecnología
- Tenemos que detallar qué entorno tenemos actualmente (As-Is). Dar un detalle del entorno actual dará una idea muy clara al proveedor de la magnitud del salto tecnológico. También le permitirá orientar su oferta para que la gestión del cambio del departamento de operaciones sea lo más sencilla posible
- Debemos detallar al máximo posible cuáles son nuestros requisitos (To-Be). Destacar en este aspecto que es importante relacionar todos y cada uno de los requisitos con el objetivo que cubren total o parcialmente. Esto dará una idea al proveedor de la importancia de cada uno
- Es importante destacar qué requisitos son imprescindibles e incluso si incumplir alguno de ellos es motivo de exclusión. De nuevo esto dará mucha información a los proveedores
- Un detalle imprescindible es detallar el formato de la respuesta esperada (tanto técnico como económico). Esto nos ahorrará muchísimo esfuerzo para realizar el análisis comparativo
Destacar que, si llevamos a cabo la construcción del documento de RFP siguiendo estas directrices, el análisis posterior será muy sencillo. Si hemos conseguido desgranar nuestros requisitos, y todos los proveedores nos presentan la oferta en el mismo formato, será tan fácil como unificar los resultados de cada uno de ellos.
En algunas ocasiones, sobre todo cuando el salto tecnológico es muy importante, podemos solicitar a nuestros proveedores que nos hagan una sesión de defensa de la oferta presentada o una demostración de producto. Destacar que el análisis de esta parte normalmente es bastante subjetivo. Hay que pensar que sintetizar una oferta muy importante en sesiones de 1-2h a veces puede ser complicado. De esta forma normalmente apreciaremos aspectos como cercanía, capacidades del proveedor, conocimiento del sector, experiencias similares, etc.
Es importante separar la parte totalmente objetiva del resto:
- La parte objetiva nos dirá sobre el papel lo cerca que está cada proveedor de cumplir con todos los requisitos planteados
- La parte subjetiva nos dirá la confianza que genera cada uno de los proveedores a la hora de llevar el proyecto a cabo
De nuevo vayamos a un caso práctico. Imaginemos el caso de la RFI anterior donde buscábamos ampliar el número de canales de forma omnicanal, en concreto ya disponíamos de canal de voz y queríamos añadir: mail, chat y redes sociales. Imaginemos también el caso más propicio, que sería: hemos lanzado una RFI y tenemos un esquema tanto técnico como de costes de varios fabricantes o proveedores.
Llegado a este punto alguien podría imaginar que con los datos de la RFI ya podemos seleccionar un proveedor. En la mayoría de los casos no es así. Pensemos que, por ejemplo, la mayoría de los fabricantes disponen de módulos para atender todos esos canales. La cuestión no es esa, la cuestión es el detalle de cómo tratan la omnicanalidad, de cómo queremos tratar el blending multicanal, de cómo queremos tener la posibilidad de hacer transiciones intercanal, etc. Hoy en día a grandes rasgos todas las plataformas van a ser muy similares pero en el detalle… ¡Ahí están las grandes diferencias!
Entonces, ¿qué mejor manera de comparar peras con peras que estructurarlo de tal forma que las respuestas de los proveedores directamente nos den tal comparativa?
En conclusión, no pensemos que un proceso de RFP o RFI+RFP es una cosa complicada o que sólo aplica para proyectos grandes. Es una forma ordenada de lanzar solicitudes de ofertas para que el análisis posterior sea muy sencillo. De esta forma… ¡Os animo a todos a usar este tipo de solicitudes y veréis como la toma de decisión se simplifica enormemente!
