No te pierdas esta valiosa guía que te ayudará a sobresalir en el proceso de respuesta a RFP. Aumenta tus posibilidades de éxito y establece relaciones sólidas con organizaciones que buscan tus servicios. ¡Descarga el libro y mejora tus habilidades hoy mismo!
Request for
Proposal
Una guía desde el otro lado
José María Flores Zazo
1
Licencia CC0 1.0 Universal (CC0 1.0)
2
Request for Proposal (Solicitud de Propuesta)
Una guía desde el otro lado
A mis padres, quienes con su esfuerzo y dedicación hicieron posible que aquel Amstrad CPC 464
llegara a mis manos y despertara mi pasión por la informática.
Este libro es el fruto de su valioso regalo y del amor incondicional que siempre me han brindado.
Gracias por creer en mí y por impulsarme a seguir mis sueños. Sin vosotros, estas páginas estarían
en blanco. Con todo mi amor y gratitud, este libro es un tributo a su inmenso amor y sacrificio.
3
CONTENIDO
1 INTRODUCCIÓN .................................................................... 6
1.1 Request for Information (RFI) y Request for Proposal (RFP) .............................................. 11
2 LLEGA UNA RPF ................................................................... 13
2.1 ¿Por qué llega una RFP? .......................................................................................................... 13
2.2 ¿Cómo deberían llegar las RPF? ............................................................................................. 15
2.2.1 Planificar una RFP ...........................................................................................................18
2.2.2 Anatomía de la RPF ........................................................................................................ 20
2.2.2.1 Visión general e información administrativa ............................................................ 21
2.2.2.2 Requerimientos técnicos ............................................................................................. 21
2.2.2.3 Requerimientos de gestión ........................................................................................ 23
2.2.2.4 Calificaciones y referencias del proveedor ................................................................ 23
2.2.2.5 Sección para proveedores ........................................................................................... 24
2.2.2.6 Sección de precios ....................................................................................................... 25
2.2.2.7 Contratos y licencias ................................................................................................... 26
2.2.2.8 Anexos ......................................................................................................................... 27
2.2.3 Actividades de la RPF ..................................................................................................... 27
2.2.3.1 Actividades Pre-RFP ................................................................................................... 27
2.2.3.2 Actividades de la RFP ................................................................................................. 29
2.2.3.3 Actividades Post-RFP ................................................................................................. 30
2.3 Analizando una RFP: siempre falta algo ............................................................................... 34
3 DESDE EL OTRO LADO: LA RESPUESTA .................................. 35
3.1 ¿Cómo debería ser la RPF que tengo que estudiar? ............................................................. 35
3.2 Guía para responder a una RFP ............................................................................................. 36
3.2.1 Cubierta ........................................................................................................................... 36
3.2.2 Resumen ejecutivo .......................................................................................................... 36
3.2.3 Respuesta a los requerimientos administrativos .......................................................... 38
3.2.3.1 Anatomía de la sección administrativa ..................................................................... 40
3.2.4 Respuesta a los requerimientos técnicos ...................................................................... 43
3.2.4.1 Requisitos .................................................................................................................... 44
4
3.2.4.2 Anatomía de la sección técnica ................................................................................. 58
3.2.4.3 Tablas de resúmenes ................................................................................................... 64
3.2.5 Entregables ...................................................................................................................... 64
3.2.6 El Precio ........................................................................................................................... 66
3.2.6.1 Anatomía de los precios ............................................................................................. 67
3.2.6.2 Tipos de costes ............................................................................................................ 75
3.2.6.3 Precio fijo ..................................................................................................................... 77
3.2.6.4 Time & Materials (recursos dedicados) ..................................................................... 78
3.3 Evaluación de una RFP ........................................................................................................... 79
3.3.1 ¿Ofertar o no ofertar? ......................................................................................................81
3.3.2 Desarrollo preliminar de un punto de venta único/diferenciador. .............................81
3.3.3 Desarrollo del Diseño del Programa ..............................................................................81
3.3.4 Desarrollo de la Portada y el Resumen Ejecutivo ..........................................................81
3.3.5 ¿Cómo debo hacer las preguntas al cliente? ................................................................. 82
3.3.6 ¿Cómo debo hacer asunciones? ..................................................................................... 83
3.3.7 Una serie de cuestionarios que te ayudarán ................................................................. 84
3.3.8 Tipos de estimación y herramientas que ayudan ......................................................... 86
3.3.9 ¿Cómo debería ser el equipo? ........................................................................................ 88
3.3.9.1 ¿Qué espero de quien lidera la propuesta? ............................................................... 90
3.3.9.2 ¿Qué espero de los mánager o gerentes de Áreas Funcionales? ............................. 91
3.3.9.3 5.10.2.3 Miembros del Equipo .................................................................................... 91
3.3.9.4 Acuerdos de Consultoría ............................................................................................ 92
3.3.9.5 Acuerdo de Colaboración ........................................................................................... 92
3.3.9.6 Especialista en Desarrollo de Propuestas .................................................................. 93
4 ANEXOS .............................................................................. 94
4.1 Cliente: cronograma inverso de ejemplo para planificar una RFP...................................... 94
4.2 Cliente: ejemplo de la organización del equipo ................................................................... 95
4.3 Cliente: ejemplo de información administrativa.................................................................. 96
4.4 Cliente: instrucciones para responder a la RFP .................................................................... 97
5
“Si conoces al enemigo y te conoces a ti mismo, no debes temer el
resultado de cien batallas. Si te conoces a ti mismo, pero no al enemigo,
por cada victoria obtenida también sufrirás una derrota. Si no sabes
nada ni del enemigo ni de ti mismo, sucumbirás en todas las batallas.”
― Sun Tzu, The Art of War
Notas:
Punto en el que debes prestar especial atención.
Consejos basados en la experiencia.
Exención de responsabilidad:
• Las marcas registradas mencionadas en este documento son propiedad de sus
respectivos propietarios.
• El autor se exonera de cualquier responsabilidad por el uso de las marcas
registradas mencionadas en este documento.
• El lector asume toda responsabilidad por el uso y aplicación del contenido del
libro.
• El autor no asume ninguna responsabilidad por los posibles perjuicios derivados
del uso del contenido del libro.
6
1 INTRODUCCIÓN
¿Para quién va dirigido este libro?
Para todas aquellas personas que se dedican a responder RFP (Request for
Proposal), pero también deberían leerlo aquellas otras que se dedican a
escribirlas para que vean como entre ambas partes podemos ayudarnos.
Estoy seguro de que aquellas personas que se dedican a escribir la respuesta
a una RPF han vivido situaciones similares, incluso peores:
1. A veces, como arquitecto, leyendo una RFP me siento que estoy
descifrando un antiguo manuscrito en arameo esperando encontrar el
tesoro escondido del presupuesto.
2. Otras veces me encuentro en el juego de '¿Dónde está Wally?' cuando
intento localizar los requisitos clave entre las páginas interminables de
jerga técnica y cláusulas legales. ¿Quién necesita un pasatiempo cuando
tienes una RFP?
3. También espero ansiosamente la sección de 'criterios de evaluación',
porque aquí es donde me convierto en el Sherlock Holmes de la
arquitectura. Busco cada pista oculta y pistas secretas que me ayuden a
descifrar lo que realmente están buscando.
4. Y como no, al leer una RFP la sensación es de estar en una montaña rusa
de emociones. Pasar de la emoción de encontrar una oportunidad
interesante a la confusión extrema cuando me encuentro con un
requisito absurdo.
¿Por qué ocurre esto?
Siendo conciso y respondiendo a las situaciones anteriores de forma
concreta:
1. Complejidad del lenguaje: Las RFP suelen contener terminología
técnica y legal específica que puede resultar difícil de comprender para
alguien que no está familiarizado con ella.
2. Extensión y estructura: Las RFP suelen ser documentos extensos con
secciones y subsecciones que contienen información detallada.
7
Navegar a través de estas páginas interminables en busca de los
requisitos clave.
3. Interpretación de los criterios de evaluación: La sección de criterios de
evaluación es fundamental para comprender qué aspectos son
prioritarios para los evaluadores. Los licitadores deben actuar como
detectives, buscando pistas y pistas ocultas para descifrar lo que
realmente se busca en la propuesta.
4. Contraste de emociones: La lectura de una RFP puede generar
diferentes emociones. Por un lado, la emoción de encontrar una
oportunidad interesante y lucrativa puede ser emocionante. Sin
embargo, también puede ser frustrante cuando se encuentran
requisitos absurdos o contradictorios.
Pero este coctel viene dado por la falta de un guion, un orden de las ideas o
simplemente por falta de interés de quien la escribe. Si fuera solo una
variable la que entra en juego, sería todo más sencillo, pero lo habitual es
que exista una mezcla de variables (si no, todas) que de nuestro trabajo una
tarea compleja y extenuante.
Siendo formales, los puntos que habitualmente nos vamos a encontrar son:
1. Complejidad de los requisitos: Si los requisitos de la RFP son complejos
y detallados, puede llevar mucho tiempo comprenderlos
completamente y determinar la mejor manera de abordarlos. Esto
puede requerir un análisis exhaustivo y la consulta de múltiples
recursos, lo que puede resultar extenuante.
2. Ambigüedad o falta de claridad: Si la RFP no está redactada de manera
clara y concisa, puede generar confusión y ambigüedad en cuanto a lo
que realmente se espera en la propuesta. Esto puede llevar a la
necesidad de hacer suposiciones o solicitar aclaraciones adicionales, lo
que añade complejidad y retrasa el proceso de respuesta.
3. Volumen de trabajo y plazos ajustados: Si hay una gran cantidad de
trabajo involucrado en la preparación de la propuesta y los plazos son
ajustados, el arquitecto de soluciones puede sentirse abrumado y
presionado. Esto puede requerir una gestión eficiente del tiempo y de
8
los recursos disponibles para cumplir con los requisitos en el tiempo
establecido.
4. Requerimientos técnicos desafiantes: Si la RFP incluye requerimientos
técnicos altamente desafiantes o novedosos, el arquitecto de
soluciones puede enfrentarse a problemas complejos que requieren
una cuidadosa planificación y diseño. Esto puede llevar a
investigaciones exhaustivas, pruebas y experimentación, lo que puede
ser agotador.
5. Competencia y expectativas altas: Si hay una fuerte competencia entre
los licitadores y las expectativas de calidad y experiencia son altas, el
arquitecto de soluciones puede sentir la presión de destacarse entre los
demás. Esto puede generar un estrés adicional y un mayor esfuerzo
para asegurar que la propuesta sea competitiva y cumpla con los
estándares requeridos.
¿Por qué escribo este libro?
El proceso de RFP es fundamental en el mundo empresarial y
gubernamental, ya que proporciona una oportunidad para que las
organizaciones busquen soluciones, productos o servicios externos que
satisfagan sus necesidades específicas. Si bien existen numerosos recursos
que se centran en cómo redactar RFP, hay un espacio notablemente limitado
en la literatura que se dedica a ayudar a los proveedores a abordar estos
documentos de manera efectiva.
Gracias a este libro tengo la oportunidad de compartir mi experiencia y
conocimientos como alguien que está del otro lado de la mesa, respondiendo
a RFP. Espero que sea un recurso valioso para aquellas personas que tienen
poca o nada de experiencia y quizá para a aquellas otras que es su trabajo
diario.
En este libro os guiaré a través de los desafíos y obstáculos comunes a los que
nos enfrentamos los proveedores, al tiempo que intentaré ofreceros consejos
prácticos sobre cómo superarlos:
9
• Exploraremos las mejores prácticas para analizar cuidadosamente los
requisitos del RFP, evaluar los riesgos asociados y determinar si una
propuesta es una buena oportunidad de negocio.
• Se abordarán estrategias efectivas para investigar a la organización que
emite la RFP, comprender sus objetivos y alinear adecuadamente tus
propuestas con sus necesidades y expectativas.
• Compartiré técnicas para desarrollar una propuesta sólida, que
destaque entre la competencia y de valor convincente.
• También examinaremos en detalle cómo estructurar y presentar la
información de manera clara y convincente.
Como es imposible usar casos reales debido a las NDA (Non-Disclosure
Agreement, acuerdo de no divulgación) que tengo firmadas, intentaré
ilustrar el libro con desafíos y éxitos ficticios que en nada tendrá que ver con
la vida real de mi carrera profesional. Estos casos prácticos me brindarán la
oportunidad de mostrar ejemplos concretos que podréis analizar y
comprender en profundidad, de esta forma tendréis una visión más clara de
los conceptos y estrategias que presento.
Al finalizar el libro espero poder aportar una mejora en tus habilidades de
respuesta a RFP, aumentar tus posibilidades de éxito y establecer relaciones
comerciales sólidas con organizaciones que buscan tus servicios.
Espero que este libro sea una valiosa guía y referencia para aquellos que
desean sobresalir en el competitivo mundo de las propuestas de negocios.
Y ¿quién soy yo?
Soy José María Flores Zazo, tengo más de 26 años de experiencia en el
desarrollo de aplicaciones. He trabajado en diversas tecnologías desde
Frontend hasta Backend, pasando de monolitos a microservicios,
aplicaciones de movilidad, escritorio, IoT, AI, etc.
Durante mi carrera, he estado involucrado en todas las etapas de los
proyectos, desde la pre-venta hasta la implementación. También he
trabajado en prototipos, desarrollo de frameworks internos, certificaciones,
formación e investigación y desarrollo.
10
Actualmente, desempeño roles como arquitecto de soluciones y sí, continúo
desarrollando muchas cosas, me encanta desarrollador y centrarme en el
software; no me gusta escribir cosas de arquitectura que no sea capad de
hacer por mis mismo. También soy evangelista de varias tecnologías de
Microsoft y otros fabricantes, y audito proyectos para garantizar que se sigan
las mejores prácticas.
Algunos de los proyectos que he liderado han recibido reconocimiento
nacional e internacional, como LaundryID, premiado por la Unión Europea,
y el proyecto NeverAlone del Instituto de Robótica para la Dependencia.
Recientemente, fui nombrado Microsoft MVP en Azure para el período 2022-
2023 y soy uno de los 110 Azure Content Hero en el mundo. Además,
colaboro activamente en la comunidad, dando charlas en eventos, creando
documentos como el que tienes entre manso, publicando videos en YouTube
y ofreciendo talleres gratuitos.
Siempre estoy aprendiendo cosas nuevas y estoy disponible para contactar a
través de las redes sociales, especialmente LinkedIn y Twitter.
11
1.1 REQUEST FOR INFORMATION (RFI) Y REQUEST FOR PROPOSAL (RFP)
Es algo habitual que en mi sector usemos muchísimos acrónimos, que iré
desgranando a lo largo del libro. Dos de ellos realmente importantes:
Request for Proposal (RFP) Request for Information (RFI)
Propósito
Obtener propuestas detalladas
de proveedores
Obtener información preliminar
de proveedores
Requisitos Detallados y exhaustivos Generales y menos detallados
Evaluación
Basada en criterios específicos
establecidos
Evaluación preliminar y selección
Nivel de detalle Completa y detallada General y no tan detallada
Etapa del
proceso
Solicitud después de la RFI Solicitud antes de la RFP
Enfoque Solución y propuesta completa Información general y capacidad
Precio Una valoración detallada
Una valoración sobre horquilla
(valor máximo y mínimo)
El flujo de un proceso es:
12
1. Puede o no existir una RFI, la RFI tendrá una serie de reuniones y
preguntas que hacen que el proveedor (nosotros) podamos dar una
buena respuesta.
2. Si hemos tenido una RFI el siguiente es la RFP, lo cual indica que el
cliente ha pasado una criba inicial de proveedores. El cliente ya ha
podido filtrar una serie de proveedores e ideas iniciales del enfoque de
la aplicación.
3. Y finalmente tenemos la RFP, que puede ser el paso siguiente desde la
RFI o directo. Las oportunidades directas suelen recibirse por que ya
nos conoce como proveedor.
A parte de estas dos grandes definiciones de los proyectos de licitación,
existe estas otras que deben sonarte:
• EOI (Expression of Interest): la EOI es un documento mediante el cual
un proveedor manifiesta su interés en ejecutar un proyecto y
demuestra sus capacidades para llevarlo a cabo. Generalmente, este
tipo de documento se solicita por parte de la administración o entidad
contratante al inicio de un proceso de licitación, con el propósito de
recopilar información sobre los proveedores interesados y evaluar su
idoneidad para el proyecto.
• RFQ (Request for Quotations): el término RFQ puede tener dos
significados diferentes en el contexto de procesos de licitación:
▪ Request for Quotations: esta solicitud se utiliza cuando los
productos o servicios ya están definidos, y el factor principal para
seleccionar al adjudicatario es el precio. El objetivo de la RFQ es
obtener cotizaciones o precios detallados de los proveedores, que
luego se utilizarán como referencia en la RFP (Request for
Proposal) para establecer un baremo de precios preciso.
▪ Request for Qualifications: en este caso, la RFQ se utiliza para
recopilar información sobre las capacidades y cualificaciones de
los proveedores para proporcionar un servicio o producto
específico. El objetivo es evaluar las capacidades y habilidades de
los proveedores y establecer un grupo de posibles proveedores
que cumplan con los requisitos establecidos.
13
• RFT (Request for Tender): el término RFT se utiliza principalmente en
el sector público para referirse a la Request for Proposal (RFP) en el
ámbito de las licitaciones. La RFT establece una estructura y formato
específicos para las respuestas de los proveedores, con el objetivo de
garantizar la transparencia y objetividad del proceso de licitación. En
este tipo de solicitud, se proporcionan detalles y requisitos específicos
del proyecto, y los proveedores deben presentar propuestas detalladas
que aborden todos los aspectos de este.
• BAFO (Best and Final Offer): BAFO hace referencia a la etapa de
selección en la que se eligen las mejores ofertas presentadas durante
un proceso de licitación. Después de evaluar las propuestas iniciales, se
solicita a los proveedores seleccionados que presenten su mejor oferta
final, considerando los aspectos técnicos, financieros y cualquier otra
consideración relevante. En esta etapa, los proveedores tienen la
oportunidad de mejorar y ajustar sus ofertas para competir por el
contrato.
2 LLEGA UNA RPF
2.1 ¿POR QUÉ LLEGA UNA RFP?
La RFP es un punto importante entre el inicio del proyecto y la
implementación. La RFP nos proporciona la estructura que nos permite
obtener los requerimientos que vamos a desarrollar en la aplicación. Gracias
a este documento los clientes nos ofrecen una lista de requerimientos que
podamos entender y responder.
La RFP es un punto intermedio, muy importante, del proyecto que nos
facilita una explicación de como se implementará la aplicación. Si no se
platea una RFP sólida el proyecto no llegará a buen término.
La RFP es una unión de los siguientes componentes:
14
Este documento debe llevar información desde el presupuesto manejado por
el cliente (dato que he visto en muy pocas ocasiones), hasta los
requerimientos pasando por una lista de como califican a los proveedores, es
decir, a nosotros. ¿Cuántas veces has visto lo que he puesto? Muy pocas, por
eso una de las cosas que vamos a ver es como se debe crear una buena RFP,
para que al llegar los puntos que faltan se pregunten sin tapujos, incluso
antes que cualquier pregunta técnica debemos saber estos datos ya que son
el marco de juego de nuestra propuesta.
Nunca, como proveedor, vamos a llegar a presentar una buena respuesta al
cliente, si este, no sabe como presentar una RPF con la información
necesaria: “si no sabes a dónde vas, ningún camino te llevará allí”.
Una buena RFP nos evitará de problemas en el futuro:
• Una RFP requiere de un equipo que la estudie bien para encontrar los
problemas y errores antes de enviarla al proveedor.
RFP
Proveedores
Implementación
Requerimientos
Presupuesto
15
• Una RPF nos forzará (proveedor) a ser competitivos y no solo
responder a los requerimientos de la RFP si no más allá, nos pondrá a
prueba para añadir valor adicional a la propuesta del cliente.
• Las reglas las escribe el cliente, por tanto, no deberían favorecer a un
proveedor en detrimento de otro, ya que se supone deberíamos tener
todos los mismo.
• Gracias a una RFP bien definida, todos los proveedores tenemos todas
las reglas y por tanto para el cliente debería ser fácil discernir las
diferencias entre proveedores.
• Extendiendo el punto anterior, también ayuda al cliente a evaluar las
propuestas. Esa es la consecuencia de una RFP bien estructurada por
parte del cliente: la uniformidad a la hora de responder por parte de
los proveedores.
2.2 ¿CÓMO DEBERÍAN LLEGAR LAS RPF?
No voy a salirme del segmento del IT, principalmente por que este
documento está enfocado estos perfiles.
Los productos informáticos habitualmente tienen un usuario final, por tanto,
para escribir la RFP es necesario involucrarlos. Muchas veces ni se les
consulta, es aquí cuando cualquier metodología en mayor o menor medida,
ya sea waterfall o agile, falla.
Mi propuesta es que separemos en tres sectores los perfiles y escojamos una
buena relación entre ellos a la hora de escribir la RFP:
• Operaciones y usuarios:
1. Entendimiento completo de las necesidades: El equipo de operaciones
y los usuarios son quienes tienen un conocimiento profundo de los
desafíos y requisitos operativos diarios. Al involucrarlos en la escritura
de la RFP, pueden proporcionar información crucial sobre las
necesidades específicas del proyecto, los problemas actuales y las
expectativas del producto o servicio que se va a adquirir. Esto garantiza
que la RFP refleje con precisión las necesidades del negocio y las áreas
clave que deben abordarse.
16
2. Identificación de requisitos técnicos y funcionales: El equipo de
operaciones y usuarios puede contribuir en la identificación de los
requisitos técnicos y funcionales que son fundamentales para el éxito
del proyecto. Su experiencia y conocimiento en el campo les permiten
comprender las capacidades y características necesarias para satisfacer
las necesidades operativas y los objetivos comerciales. Incluir sus
perspectivas en la RFP ayuda a definir claramente los requisitos
técnicos y funcionales que los proveedores deben cumplir.
3. Validación de la viabilidad y factibilidad: Al involucrar al equipo de
operaciones y usuarios en la escritura de la RFP, se asegura que los
requisitos establecidos sean viables y factibles desde su perspectiva.
Pueden proporcionar información valiosa sobre las restricciones
operativas, la infraestructura existente, las limitaciones de recursos y
cualquier otro aspecto que pueda afectar la implementación exitosa del
proyecto. Esto ayuda a evitar la inclusión de requisitos irrealizables o
poco prácticos en la RFP.
4. Aumento de la aceptación y adopción del proyecto: Al participar en la
escritura de la RFP, el equipo de operaciones y usuarios se siente
involucrado y escuchado. Esto crea un sentido de propiedad y
compromiso con el proyecto desde el principio. Además, al asegurarse
de que las necesidades y expectativas del equipo sean consideradas, se
aumenta la probabilidad de que el producto o servicio seleccionado sea
aceptado y adoptado de manera más efectiva por el equipo.
• IT:
1. Conocimiento técnico especializado: El equipo de IT posee un
conocimiento profundo de los sistemas, infraestructuras y tecnologías
utilizadas en la organización. Al involucrarlos en la escritura de la RFP,
pueden proporcionar una perspectiva técnica y ayudar a identificar los
requisitos específicos de IT necesarios para el proyecto. Su experiencia
y conocimiento técnico permiten redactar requisitos más precisos y
relevantes relacionados con las soluciones tecnológicas y las
integraciones necesarias.
2. Evaluación de la viabilidad técnica: El equipo de IT puede evaluar la
viabilidad técnica de las propuestas presentadas por los proveedores.
17
Pueden analizar la arquitectura propuesta, la compatibilidad con los
sistemas existentes, la seguridad de la información y otros aspectos
técnicos críticos. Al involucrar al equipo de IT en la escritura de la RFP,
se pueden establecer requisitos y criterios de evaluación que
consideren la capacidad técnica de los proveedores para cumplir con
los estándares y requisitos de la organización.
3. Identificación de riesgos y desafíos técnicos: El equipo de IT puede
ayudar a identificar posibles riesgos y desafíos técnicos asociados con
el proyecto. Pueden señalar problemas de integración, requisitos de
escalabilidad, consideraciones de rendimiento, entre otros aspectos
relevantes. Al tener en cuenta estos factores desde el principio, se
pueden abordar adecuadamente en la RFP y evaluar las propuestas de
los proveedores para mitigar los riesgos técnicos potenciales.
4. Evaluación de la capacidad y experiencia de los proveedores: El equipo
de IT puede aportar una visión crítica en la evaluación de las
capacidades y experiencia de los proveedores. Pueden revisar las
referencias, casos de éxito y competencias técnicas de los proveedores
para determinar su idoneidad. Su experiencia en el campo les permite
identificar señales de alerta y seleccionar a los proveedores que mejor
se ajusten a las necesidades técnicas y estratégicas de la organización.
• Compras:
1. Conocimiento de los procesos de adquisición: El equipo de compras
tiene experiencia y conocimiento en los procesos de adquisición y
contratación de bienes y servicios. Al involucrarlos en la escritura de la
RFP, pueden proporcionar orientación sobre los procedimientos y las
mejores prácticas para asegurar una licitación justa y transparente.
También pueden ayudar a garantizar el cumplimiento de las políticas y
regulaciones internas y externas relacionadas con las compras.
2. Identificación de requisitos contractuales: El equipo de compras puede
contribuir en la identificación de los requisitos contractuales
necesarios para proteger los intereses de la organización. Pueden
incluir cláusulas legales y comerciales relevantes en la RFP, como
condiciones de pago, garantías, términos de entrega, derechos de
propiedad intelectual, entre otros aspectos contractuales. Su
18
experiencia en la redacción de contratos ayuda a asegurar que los
términos y condiciones estén adecuadamente reflejados en la RFP.
3. Evaluación de la capacidad financiera de los proveedores: El equipo de
compras puede evaluar la capacidad financiera de los proveedores
potenciales para cumplir con los requisitos del proyecto. Pueden
solicitar información financiera relevante, como estados financieros,
referencias bancarias u otras garantías financieras, y utilizarla para
evaluar la solidez financiera de los proveedores. Esta evaluación es
esencial para mitigar el riesgo de trabajar con proveedores que puedan
presentar dificultades financieras durante la ejecución del proyecto.
4. Negociación y selección de proveedores: El equipo de compras tiene
habilidades y experiencia en la negociación de contratos y en la
selección de proveedores. Al involucrarlos en la escritura de la RFP,
pueden ayudar a establecer criterios de evaluación claros y objetivos,
así como a diseñar el proceso de selección adecuado. Además, pueden
participar en la evaluación de las propuestas recibidas, realizar
negociaciones con los proveedores y recomendar al adjudicatario final.
Su participación garantiza un proceso de selección imparcial y
eficiente.
Una vez tenemos la lista de perfiles que tenemos que buscar, toca ponerse
manos a la obra para coordinar a estas personas y empezar la fase previa de
la escritura de la RFP.
2.2.1 Planificar una RFP
Como clientes debes planificar, como paso previo para ponerse a escribir la
RFP, sin planificación, la RFP será un caos. Vamos a evitarlo.
1. Crear un proyecto de RPF y organizar al personal.
2. Crear un cronograma de la RFP (Anexo 4.1).
3. Listado de proveedores, según la tecnología y sector.
4. Estimación y definición de los límites económicos del proyecto.
5. Retorno de inversión (ROI) y análisis (si se necesita).
6. Creación propiamente dicha de la RFP.
7. Se evalúan las propuestas.
8. Contratos y adjudicación.
19
9. Actividades post-RFP.
10. Personal del proyecto (Anexo 4.2) y organización para el nuevo
producto.
La parte del cronograma tendrá definidas hasta las fechas de respuestas a
proveedores, así como fechas límites de envío de la propuesta. Debe quedar
muy claro, si no aparece esta información del cronograma en la RFP que
enviemos al proveedor, seguramente se relaje y llegue tarde a la entrega o
bien no la tome en cuenta por qué puede pensar que esto es un tanteo que
no llevará a ningún sitio.
Como cliente cuando recibes una propuesta tienes la misión de evaluarla,
para ello seguir siempre un guion hace el proceso más sencillo y por qué no
industrializado.
Por ejemplo, estas acciones son de lo más común:
1. Revisar los requerimientos técnicos.
2. Revisar los requerimientos de organización y administración del
proyecto.
3. Precio.
4. Referencias.
5. Visitas por parte del equipo de proveedor o presentaciones orales.
6. Si disponen de productos de demo similares.
7. Revisar en global la RPF.
8. Y disponibilidad para acometer el proyecto.
Por ejemplo, la disponibilidad es un tema muy importante, ya que un
proveedor puede formar el equipo que propone en la RFP inmediatamente o
bien tardar mucho siendo el proyecto del cliente, de vital importancia para el
negocio.
Unos puntos son más complicados de medir que otros y aquí entra en juego
la subjetividad de quien evalúa la RFP. Siempre que se pueda intenta
transformar tus medidas cualitativas (son buenos, regulares o malos) a
medidas cualitativas (3 puntos, 1 punto, 0 puntos), te permitirá poner en
valor una suma total de puntos ganados por cada proveedor y reducir la
horquilla de posibles candidatos a la siguiente fase.
20
Presta mucha atención a lo que responden los proveedores sobre los
requerimientos, sobre todo aquellos que son obligatorios. Para que esto sea
algo sencillo te recomiendo que separes los requerimientos en:
• Obligatorios, ya que, si un proveedor no responde a todos, tienes una
razón de peso para descalificarlos.
• Opcionales, nice to have but not essential, lo que nos gustaría tener, pero
que no son esenciales.
Y como proveedor, si no ves la separación entre obligatorios y opcionales,
puedes o bien preguntarlo en rondas de preguntas o bien tomar asunciones
al respecto.
2.2.2 Anatomía de la RPF
La RFP es una herramienta para quien compra y cada tipo de compra,
incluso en IT puede ser diferente os voy a proponer una estructura de una
RFP que puedes tomar como base, quitando o poniendo lo que te interese
como cliente que emite una RFP.
Visión general e
información
administrativa
Requerimientos
técnicos
Requermientos
de gestión
Calificaciones y
referencias del
proveedor
Seccion para
proveedores
Sección para
precios
Contratos y
licencias
Anexos
21
2.2.2.1 Visión general e información administrativa
En esta sección debes proporcionar a los proveedores la información general
sobre tu empresa y una explicación al problema que quieren solucionar con
la RFP.
Detallar lo máximo posible el problema que los proveedores debemos
solucionar evitando cualquier referencia técnica al problema.
En la parte de información administrativa vamos a proporcionar a los
proveedores la siguiente información:
• Dónde y cuándo enviar la propuesta.
• Cuando podrán los proveedores ponerse en contacto con el cliente.
• Fechas importantes en el proceso de licitación.
• Requerimientos para preparar la propuesta (a veces los clientes nos dan
un guion de como desean recibir la respuesta, otras veces hasta acceso a
su plataforma para poder redactarla allí mimos).
• Cómo van a evaluar la propuesta.
• Nombres de los contactos y direcciones de las personas involucradas en la
RFP.
La información administrativa es muy importante ya que como cliente
quieres que los proveedores nos pongamos manos a la obra lo antes posible y
podamos obtener la información que nos hace falta de una forma ordenada
sin impactar en el cliente que nos solicita ayuda.
Sin esta información habrá proveedores que no respondan o presenten la
atención debida a la propuesta.
Nunca he rechazado una propuesta que venga sin parte de esta información,
primero por qué habitualmente llega casi todo y segundo por qué es muy
fácil pedir lo que necesitas de forma educada.
2.2.2.2 Requerimientos técnicos
Esta es la parte más importante de una RFP.
Esta sección debe contener las necesidades que nos permitirá a los
proveedores responder una RFP. En ella habrá un sumario de los problemas,
requerimientos o solicitudes de la RFP. Debe haber una visión general que
22
proporcione la información respecto a requerimientos de negocio,
infraestructura, etc.
Posterior a esta visión general, el cliente debe proporcionar una lista de
requerimientos que el proveedor debe responder en la propuesta, por
ejemplo:
• Objetivos y metas del proyecto.
• Factores críticos para alcanzar el éxito del proyecto.
• Especificaciones funcionales actuales.
• Especificaciones funcionales para el nuevo proyecto.
• Especificaciones de cumplimiento: SLA, rendimiento, etc.
• Cloud / On-Premise.
• Requerimientos del software: herramientas, lenguajes, cumplimiento con
un departamento de arquitectura, herramientas certificadas por el cliente,
latencias, etc.
Esta sección debe estar muy bien documentada y muy completa, cuanto más
completa esté menos respuestas tendrá el proveedor y más fácil será dar una
respuesta clara y concisa a las necesidades del cliente.
Además, si eres el cliente, no te apetecerá estar repitiendo lo mismo a varios
proveedores. Por eso a veces los proveedores sufrimos alguna que otra
encerrona por parte del cliente y nos ponen a todos los proveedores en una
ronda de preguntas conjunta que en muchas ocasiones es incomoda ya que
no se tienen en cuenta el tiempo dedicado por cada proveedor, se ven las
confianzas que tiene el cliente con alguno de ellos, etc. que pueden hacer
que como proveedor no desee continuar con la propuesta por un claro
tratamiento sesgado por parte del cliente. ¿Por qué sesgado? Por que es una
forma tendenciosa de decirnos a los proveedores que llevamos tiempo con
ellos que han puesto la mira en otros más baratos, que responden antes, etc.
Al final es un juego que debería evitarse. Perjudica al cliente que cree que
está haciendo una jugada maestra al confrontar proveedores.
23
2.2.2.3 Requerimientos de gestión
En esta sección el cliente nos debe proporcionar la información necesaria
para desarrollar un plan que cubra la implementación, instalación,
transferencia de conocimiento, mantenimiento y otros aspectos del
proyecto. Al definir el cliente sus requerimientos, nos muestran a los
proveedores que es lo mínimo y suficiente para cumplir y no ser
descalificados, a partir de aquí es misión del proveedor ofrecer más valor a su
propuesta.
Habitualmente debería contener estas secciones:
• Requerimientos funcionales del proyecto.
• Requerimientos de personal (en ingles se usa la palabra staffing, que
posiblemente escucharás mucho cuando hables con consultores).
• Lista de responsabilidades del cliente y del proveedor.
• Plan de entrega (delivery) e implantación.
• Requerimientos de prueba aceptación.
• Requerimientos para la transferencia de conocimiento (en ingles se suele
usar KT que es Knowledge transfer).
• Y requerimientos de documentación.
Que el cliente detalle esto concienzudamente no es habitual, por eso
recomiendo a los proveedores que tomen esta lista como un punto de
partida para completar la RFP que nos ofrece el cliente.
Si yo fuera el cliente, la detallaría por qué se trata de un mecanismo que
podría usar para discernir quien cumple con los mínimos que establece y es
una forma objetiva de descalificación.
2.2.2.4 Calificaciones y referencias del proveedor
Simplemente se trata de pedir al proveedor información de su compañía y su
solvencia. El cliente podría pedir:
• Un breve resumen de la historia de su compañía.
• Qué ofrece su compañía (en ingles se suele llamar offering) y que
capacidades tiene (certificaciones, reconocimientos, etc.).
• Evidencias de que el proveedor tiene las habilidades, el equipo humano y
los recursos financieros para poder acometer un proyecto.
24
• Una lista de casos de éxito similares a la propuesta pedida por el cliente.
Habitualmente llamado referencias.
• Una lista de clientes y que relaciones tiene. Habitualmente la más
importante es ser partner de [Organización] (que puede ser Microsoft,
Amazon, Google, SAP, Salesforce, etc.)
Si esto no es suficiente, lo mejor es que el cliente o el proveedor, contacte
con su departamento legal o administrativo para que realice una
investigación para ver si es necesario investigar. Esto es bidireccional, no es
solo una tarea del cliente al proveedor. Ver si cualifica es algo que se debe
hacer por ambas partes.
2.2.2.5 Sección para proveedores
Aquí el cliente puede poner una serie de cuestiones que pueden ayudar, pero
que no son estrictamente necesarias, ya que no forma parte de la definición
fundamental de la RFP.
El cliente puede desde aportar ideas de como solucionar su problema, puede
que en el pasado se realizara un assessement (evaluación) que incluyera una
serie de recomendaciones hasta por ejemplo una serie de soluciones
aportadas por otros proveedores que optaron a esta RFP en el pasado.
Desde mi punto de vista, esto como cliente yo no lo aportaría, tiene dos
lecturas, que el cliente no me de confianza suficiente por este tipo de juegos
o que el cliente no logra encontrar la solución lo cual indica que es un
proyecto con algo oculto. Mucho cuidado como proveedor cuando veáis este
tipo de acciones. Os comento esto por qué lo he visto, que cada uno que
juzgue la ética como quiera.
Si usáramos esta anatomía desde el punto de vista de un proveedor para
realizar una respuesta. Lo que yo pondría como proveedor sería para poner
temas que yo crea que son relevantes para la RFP pero que no han sido
discutidas en la parte de la respuesta de la RPF propiamente dicha, esta
sección suele verse como un Anexo, pero no soy muy partidario de llevarlo a
la parte de Anexos porque siempre quedan sin leerse y si se está optando por
una tecnología disruptiva que puede ponerte por encima de otros
25
proveedores, no estás haciendo la suficiente fuerza como para que se vea tu
apuesta.
2.2.2.6 Sección de precios
La sección que parece ser la más importante en muchas organizaciones en
detrimento de una buena solución.
Como cliente, lo mejor para que me sea sencillo compararlo, es proporcionar
una tabla al proveedor que contenga:
• Hardware, sí, en la era Cloud. ¿No existen aplicaciones de movilidad que
necesitan Tables robustas (ruggerized)?
• Software de terceros y licencias. Derechos de licencias.
• Desarrollo del producto. Si alguna parte el cliente ve que es un problema
importante, debería pedirlo separado; por ejemplo, si la base de datos
necesita una migración, quizá quite esto dependiendo del precio.
• Mantenimiento.
• Formación.
• Documentación.
• Administración del proyecto.
• Integraciones.
Revisar bien las herramientas SaaS y el cloud que escogen, algunos tienen
costes ocultos. Puede que un competidor escoja entre AWS y Azure, mucho
cuidado.
También tener en cuenta que en la era de Kubernetes cuando se pide ser
agnóstico, ya que habrá quien te plantee sistemas que al final llevarlo de on-
premise a cloud te hace pagar dos licencias que son más mucho más caras que
refactorizar bien tus yaml de deploy para cada entorno.
Y, para terminar, no olvidemos el locking-vendor que es un coste muy oculto,
no es tanto en euros o dólares, si no, en bloqueo que supone moverse de un
sitio a otro y el coste que supone.
26
2.2.2.7 Contratos y licencias
Como arquitecto de soluciones los contratos económicos, acuerdos o
licencias, no es nuestro cometido. Pero si que quiero hablar desde el punto
de vista de un cliente ya que si estas liderando la propuesta te tocará ir
buscando personas que te ayuden con esta sección.
El cliente debería proporcionaros una guía para responder al cliente con los
contratos y acuerdos necesarios. A veces los verás asociado a la sección
anterior de precios o de forma independiente.
Los contratos, clausulas, acuerdos deben ser estudiados por los proveedores.
Pensar que, si nos piden un SLA del 100% con una penalización del 1000% de
un día de media de facturación de su negocio, nos estamos metiendo en una
trampa mortal. Por eso, entre las distintas entidades del proveedor deben dar
respuesta a este tipo de cláusulas. Los clientes que proponen RFP con
personal que trabajó en grandes consultoras pueden llegar a poner unas
clausulas muy duras (no quiero decir abusivas) por qué conocen bien como
funcionan estas grandes consultoras.
Luego están las típicas de pagos a 30-60-90 días o cuanto tiempo tenemos
que dar para que existan respuestas entre el cliente y proveedor cuando
están desarrollando el producto, etc.
Como cliente esto te ayudará a descartar proveedores que no estén
dispuestos a aceptar tus imposiciones o que ni siquiera estén dispuestos a
negociarlas. De esta forma puedes hacer un filtro temprano.
La lista habitual de contratos puede ser:
• Acuerdo de compra.
• Contrato de mantenimiento.
• Período de garantía.
• Acuerdos de licencia de software, cesión de fuentes del proveedor al
cliente, etc.
• Bonificaciones y penalizaciones.
• Formas de pago.
• NDA (acuerdo de no divulgación).
27
2.2.2.8 Anexos
Ya lo hemos visto en el punto 2.2.2.5 Sección para proveedores.
2.2.3 Actividades de la RPF
Continuamos con el punto de vista del cliente. Esta sección nos ayudará a
comprender mejor como proveedor a nuestros clientes, si sabemos como se
realiza el proceso interno de una RFP.
2.2.3.1 Actividades Pre-RFP
El cliente se tiene que hacer preguntas como: ¿Quién lidera la RFP?, ¿Quién
revisará la RFP?, ¿Quién busca a proveedores para la RFP?, ¿Quién redacta la
RFP?, …
Ahora es cuando toca investigar solvencias, otros proyectos, etc. y ¿quiénes
son los mejores perfiles para hacer este tipo de búsqueda?: un perfil
comercial, ya que debe:
• Hacer una presentación de la empresa.
• Buscar la lista de proveedores y personas de contacto a los que hacer
prospección.
• Enviar la RFP.
• Preguntar si están interesados en la RFP los proveedores.
Si el proveedor está interesado en la propuesta todos esos proveedores
tendrán los tiempos que marcan la RFP en el cronograma. Un solo punto de
información y no varios como suele ocurrir cuando el proveedor no da esa
información directamente en la RFP.
2.2.3.1.1 Identificar proveedores
En la actualidad buscar proveedores está a una simple búsqueda en internet
que consultoras existen en tu región con los filtros que más te interesen. Por
ejemplo, busca “consultoras que estén certificadas en Kubernetes”:
28
Aquí es cuando se puede tener un pequeño dialogo, entre el proveedor y
cliente sobre aclaran temas como:
• Precio máximo para el proyecto.
• Tiempo aproximado en empezar el proyecto.
• Fecha límite para que el proyecto esté en producción.
• Que perfiles ayudaran del cliente al proveedor aclarar más dudas
Lógicamente si el cliente tienes un cronograma, estas preguntas se pueden
hacer en la ronda correspondiente.
2.2.3.1.2 Investigar a los proveedores
Unos criterios habituales para investigar al proveedor suelen ser:
• ¿El proveedor presenta los conocimientos técnicos para una aplicación
personalizada? ¿Presenta el producto adecuado usando una
herramienta de mercado?, ¿Subcontrata parte del proyecto a otro
proveedor?, ¿Quiénes son estas subcontratas?, …
• ¿El proveedor tiene la capacidad para gestionar el proyecto?, ¿tiene la
solvencia adecuada para cumplir los SLA?, …
29
• ¿Se construye desde una factoría?, ¿desde un hub local?, ¿cómo se
trabaja con esa factoría o hub?, ¿es necesario viajar para tener las
reuniones en local? (sí os sorprendería lo mal que se puede llegar a
gestionar una externalización en ciertas regiones del planeta, que va
desde una mala conexión hasta la cultura de cada persona).
• Si mi aplicación es internacional, ¿el proveedor da soporte
internacional?,
• ¿El proveedor puede presentar credenciales similares al proyecto que
desea el cliente?, ¿más grandes?, ¿más pequeñas?, …
• ¿Las fuentes será tuyas o serán del proveedor?, ¿a quien le pertenece la
propiedad intelectual?
Estas razones son más que obvias y son objetivas, per existen otras que no lo
son, por eso revisa dos veces y si puede ser con dos personas diferentes la
información de los proveedores.
2.2.3.2 Actividades de la RFP
Ya tienes identificados a los proveedores, has podido tener reuniones
previas, te han dado sus credenciales, los has investigado. Ahora es el
momento de escribir la RFP. ¿por qué no antes? Por que no enviarás una
propuesta en .NET con C# a un proveedor que solo desarrolla en JAVA a no
ser que este punto sea un tema abierto y se pida como requisito en la RFP,
muchas empresas se casan con un fabricante a no ser que exista cambio de
timón en el CTO (que también sucede).
Lo que deberías incluir en la RFP:
1 Cronograma de la RFP con todos los hitos del proyecto. Una
planificación en formato inverso, donde pones primero la fecha de
finalización de tu proyecto y vas moviéndote para atrás. Y te
sorprenderás de la cantidad de tareas que tienes que hacer en el tiempo
que pretendes destinar.
2 Escribe por qué, la causa y todo lo que se ocurra de esta RFP, no solo el
líder, si no, cualquier persona que tenga relación con ella. Revísalo varias
veces y completa los puntos que faltan. Siempre es bueno empezar con
30
“donde estamos y donde queremos llegar”, es un hilo conductor para
explicar bien una RFP.
3 Crea un esquema de alto nivel de tu RFP y que esté todo el personal de
acuerdo, si no, las revisiones serán interminables y frustrantes (todo he
de decirlo).
4 Una vez que el guion este revisado y aprobado por quienes escriban la
propuesta, revisa la planificación con ellos para que se comprometan con
las fechas y se realicen los ajustes pertinentes.
5 Cuando termines de escribir la RFP, detalla bien los criterios de
evaluación y como deben responder los proveedores.
6 Como cliente revisa que que tu importe económico se adecue a lo que
estás pidiendo. Eres el primero en hacer una estimación económica y
sobre todo revisa que en tu estimación están todos los requerimientos
obligatorios.
7 Establece contacto con los proveedores seleccionados. Asegúrate que el
contacto del proveedor puede decirte si están interesados.
8 Publica tu RFP en un sitio donde los proveedores seleccionados puedan
descargarse el documento, de esta forma al enviar por correo el link
todos los proveedores dispondrán del mismo tiempo.
9 prepárate para mantener conversaciones con los proveedores (solos o en
conjunto) así como las preguntas que van a realizar o el material que van
a requerirte. Todo debería estar agendado en el cronograma de la RFP.
10 Debes ser muy cordial con los proveedores ya que primero, pueden que
no conozcan tu sector en profundidad y pregunta que para ti sean obvias.
El documento no es pequeño y cosas se pueden pasar por alto. También
te recomiendo que tengas cuidado con aquellos proveedores que
conozcan a personas dentro de tu organización por qué esto puede
pervertir la RFP que presenten al tener información interna y que se
supone confidencial.
El líder de la RFP es el responsable de que los tiempos se cumplan y que las
personas adecuadas estén disponibles cuando se les requiere.
2.2.3.3 Actividades Post-RFP
Estas son algunas de las actividades que hace un cliente cuando los
proveedores hemos enviado la propuesta. Y aquí si no has estado en ambos
31
lados, pierdes mucho contexto que los clientes tienen, porque lo habitual es
que tengan persona que han estado en ambos frentes tiene una ventaja
táctica muy importante.
Es raro ver el movimiento de estar muchos años en producto y creando RFP
como cliente al moverse a consultoría para comenzar a responderla. O que
clientes finales tengan parte de consultoría y estén en ambos frentes. Son
raros, pero existen estos perfiles. Lo habitual es que las personas pasen de
consultoría a producto final.
Por ejemplo:
1. Evaluar la propuesta: aquí hacemos un filtro de aquellas que cumplen
con los requisitos y requerimientos, aquellas que llegan o no en el
plazo requerido, aquellas que pueden ser susceptibles de problemas
(precios por exceso o por defecto que no justifiquen los requerimientos
o en base a un 50% por exceso o defecto), aquellas que están
pobremente respondidas, etc.
2. Primera ronda de filtrado de proveedores: envía una respuesta a los
proveedores y el porqué de su descalificación. También te vendrá bien
crear un documento donde tengas todo esto explicado por qué te
servirá para cuando justifiques la propuesta ganadora.
3. Deja una lista pequeña de proveedores: ahora toca estudiar la
propuesta que entran procurando dejar como máximo entre 2 y 3
proveedores final. Es complicado, pero usando un el razonamiento y
documentando tus decisiones será más sencillo.
4. Pide una demostración: si la RFP es sobre un producto que necesita
personalización, como puede ser un CRM, ERP, pide que te lo
muestren y si puede ser una demo de un caso de uso de lo que pides.
5. Visita real: a veces tanto que el cliente visite la factoría o empresa del
cliente o viceversa se produce un análisis que nos muestra que los
equipo existen, que las persona que nos han asignado están y claro está
con unos equipos de personas más que con otros se produce un feeling
que ayuda a engrasar el trabajo entre dos entidades desconocidas, y
esto puede ser motivo de descarte de uno de los proveedores.
32
6. BAFO (Best of final offer): a veces durante la evaluación se puede
producir una sobre estimación en tiempo o dinero que puedes tratar
con el proveedor para ver las razones e incluso bajar alguna
funcionalidad para que todos estemos más cómodos, estas
conversaciones que no debes tener con más de 2 proveedores
terminarán por pulir la propuesta final ya que das la oportunidad al
proveedor para repensar algunos puntos y afinar el precio para
establecer la oferta final.
7. Selección del proveedor: considera que este paso final de la RFP es el
primer paso del proyecto. Si todos hemos realizado nuestros deberes es
posible comenzar directamente el proyecto (en muy pocas ocasiones lo
he visto, ya que se debes tener en cuenta la disponibilidad de personas
que están cerrando proyectos).
8. Informe de selección del proveedor: posiblemente no tengas que
hacerlo, pero lo recomiendo, es una buena práctica poner un por qué si
o por qué no están seleccionados los proveedores. De esta forma el
informe sirve para poder dejar documentadas las decisiones.
9. Informes para proveedores descartados: si lo deseas o lo piden, yo
prefiero hacerlo siempre, es ofrecer feedback del por qué no fue
seleccionado, esto puede ayudar mucho y genera una buena relación
entre cliente proveedor para futuras RFP.
10. No guardes nada pasados 6 meses: borra todas las anteriores RFP, no
tengas síndrome de Diógenes digital, no te vale para nada tener RFP
que no valen y es más, incluso puedes estar en una posición que
incumplas alguna clausula legal. Durante esos 6 meses puede que
algún punto que detallo un proveedor te venga bien rescatarlo y es
hasta posible ofrecerle esa parte por qué exista alguna contingencia
con el proveedor principal. Esto pasa más de lo que piensas.
2.2.3.3.1 Los contratos
Esta parte merece una mención muy especial ya que los contratos son los
que nos permitirán tener una salvaguarda en cuanto una de las partes
incumple algún plazo, cambia el alcance, etc. Aunque la intención es que
entre ambos exista una muy buena relación y sea una relación win-win, en
33
muchas ocasiones se tuerce un poco la relación, por eso, los contratos son
nuestras reglas de juego.
Por muy pequeño que sea el cambio que introduce alguna de las partes,
impactará siempre en el calendario de entrega. Por tanto, cualquier pequeño
cambio debe ser tratado con la misma importancia que uno grande.
Si todo se soluciona amistosamente, perfecto, pero cuando no es así
comienzan los litigios y cualquier coma mal puesta en un texto es susceptible
de ser reinterpretado.
Cuando hemos realizado un diseño de UX/UI que hemos acordado con
usuarios y Product Owner, pero 2 desarrolladores 1 del cliente y 1 del
proveedor deciden que ese campo debe ser de otra forma (aunque sea una
cosa muy inocente), afecta a las pruebas, afecta al trabajo de otras personas y
provocará reacciones imprevisibles.
Y aquí para poder ser fehacientes con un cambio de este tipo, quizá por que
se necesite, la documentación entra en juego, las reuniones y las actas. Es
una forma de consensuar entre todas las partes y si provoca un cambio de
alcance todo el mundo estará informado y habrá asumido las consecuencias.
Documenta, documenta y documenta. Más hoy en día que puede hacer la
documentación como código:
34
2.3 ANALIZANDO UNA RFP: SIEMPRE FALTA ALGO
Siempre falta algo por parte del cliente o por parte del proveedor, seamos
ligeramente flexibles ya que ambas partes desean un objetivo común, por eso
quizá esta sección sea más bien sea una conclusión.
Escribir y revisar RFP desde la parte de un cliente es una tarea complicada
que consume recursos de la empresa, a pesar de ser el cliente quien conoce
mejor el funcional de su aplicación. Por eso cuando se escribe es para que no
falte nada, que se realice con tiempo y con los actores adecuados, además de
tener la asignación económica para el proyecto. Ya que muchas veces veo
que partes se escriben rápidamente y sin consenso, el proveedor puede intuir
que esto es un mal proyecto o que están apurados, estas cosas pueden tirar
para atrás a muchos proveedores.
Cuando alguien crea una RFP esta dando el primer paso para su proyecto,
debe ser una demostración de que el cliente esta apostando por un cambio y
así debe ser plasmado en su RFP.
Como cliente ten en cuenta que los proveedores no estamos obligados a
responder, por eso no escribas de forma pobre, mal estructurada, con poca
información o con “falta por concretar”, ya que, como decía antes, como
proveedor puedo pensar dos cosas: está RFP ya está asignada o esta RFP
apesta y lógicamente destine mis esfuerzos a algo con mejor aspecto, ten en
cuenta que los proveedores también debemos ser selectivos y muchas veces
vamos a algo que podemos o tenemos posibilidades de ganar.
Para finalizar, a mi me gusta pensar que el proveedor que gana la propuesta
se convertirá en otro miembro más del equipo del cliente y parte de la
compañía. Construir una buena relación entre cliente y proveedor debe
basarse en un mutuo entendimiento y confianza con el objetivo común de
cumplir con el proyecto para el que nos hemos involucrado todos.
35
3 DESDE EL OTRO LADO: LA RESPUESTA
Como parte proveedora ya habéis visto como debería llegar una RFP y que
pasos da el cliente para construirla. Ellos han invertido tiempo y dinero en
hacerla lo mejor posible. Ahora es cuando nos toca ser recíprocos y ofrecer la
mejor respuesta posible.
3.1 ¿CÓMO DEBERÍA SER LA RPF QUE TENGO QUE ESTUDIAR?
A mí me gusta tener todo bien estructurado, es un defecto profesional,
cuanto mejor este estructurado menos variables quedarán al azar.
El cliente puede que nos de un guion para responder a la RFP, esto sería lo
ideal, pero como casi nunca lo veo, lo mejor es que te de un guion sencillo
con lo que debería pedirte un cliente. Puedes usarlo para comparar lo que te
llega y así tener las primeras preguntas listas para la ronda inicial de
cuestiones entre cliente y proveedor.
Guion Título
1 Cubierta con el título e información del proveedor
2 Resumen ejecutivo de la propuesta
3 Respuesta a los requerimientos administrativos
4 Solución técnica y descripción
5 Administración del proyecto
6 Respuesta a los requerimientos
6.1 Requerimientos administrativos
6.2 Requerimientos técnicos
7 Sección adicional que el proveedor considere importante
7.1 Metodologías: Waterfall, Agile, DevOps, etc.
7.2
Procesos: como se trata un cambio de alcance, como se envían
incidencias, etc.
7.3 Soluciones ilustrativas de arquitectura y alternativas contempladas
7.4
Pasos que hacemos para diseñar una aplicación: ux/ui, construcción,
soporte, etc.
7.5
Algún añadido técnico muy importante que no debe ir en Anexos
(muy opcional)
8 Precio
Anexos
a Referencias del proveedor y casos de éxito
36
b Calificación financiera e informe de cuentas anual
c Contratos de compra, legales, etc.
d Licencias de software y acuerdos
3.2 GUÍA PARA RESPONDER A UNA RFP
Como ya os he comentado, puede que el cliente nos de un guion, mi consejo
es intenta extrapolarlo al guion que os he dado yo para trabajar de forma
ordenada; si con algún punto no encuentras semejanza y ves que falta
información importante, intenta colocar lo que falte, con respecto al guion
que os proporciono, situarlo en la sección que mejor se adecue de la
propuesta del cliente.
¿Cómo debo presentar la propuesta? en Word, en
PowerPoint, en Confluence, en Markdown, etc. Esto es algo
que tu organización como proveedor debe darte o bien exigir
el cliente. En cualquier caso, sea el sistema que sea debe
tener los logos, las fuentes, las imágenes, iconos, etc. que
puedas usar, para no incurrir en ningún problema legal con
tu empresa.
3.2.1 Cubierta
A modo ilustrativo una portada debería incluir:
• Título del Proyecto y subtítulo
• Logotipo de tu organización y del cliente.
• Fecha de presentación y versión del documento.
Una página dedicada a la confidencialidad y NDA del documento
presentado.
Y, por supuesto, el guion.
3.2.2 Resumen ejecutivo
Habrá quien te diga que no es necesario, que esto suele hacerse a parte o que
se muestra en la defensa de la RFP. Sí, no lo voy a discutir ya que cada
organización tiene sus normas, pero siempre he partido de esa base por qué
la RFP puede llegar a distintas manos y alguien con mucha responsabilidad
37
es una persona que tiene el tiempo justo y proporcionarlo directamente en la
RFP ayuda a que esa persona tenga la idea global.
Desde mi experiencia debemos tener en cuenta el siguiente guion:
- Introducción:
a. Presenta tu empresa y su experiencia relevante en el campo.
b. Menciona el nombre y número de la RFP a la que estás
respondiendo.
c. Resalta la importancia de la RFP y cómo tu respuesta cumple con
los requisitos establecidos.
- Visión general del enfoque:
a. Describe brevemente el enfoque general que tomarás para
abordar los desafíos y necesidades planteados en la RFP.
b. Destaca los principales beneficios y valor que tu solución
aportará al cliente.
c. Haz hincapié en cómo tu enfoque se alinea con los objetivos y
valores del cliente.
- Experiencia relevante:
a. Enumera y destaca proyectos similares realizados previamente
que demuestren tu experiencia y éxito en el área relacionada con
la RFP.
b. Menciona clientes clave con los que has trabajado y los
resultados obtenidos.
c. Resalta cualquier certificación, reconocimiento o premio
relevante que respalde tu experiencia.
- Solución propuesta:
a. Resume los aspectos clave de tu solución y cómo abordará los
requisitos específicos de la RFP.
b. Destaca las características y funcionalidades clave de tu
propuesta.
c. Explica cómo tu solución se diferencia de las alternativas
disponibles y cómo beneficiará al cliente.
- Equipo y recursos:
a. Presenta al equipo que estará involucrado en la implementación
de la solución propuesta.
38
b. Destaca las capacidades y experiencia relevantes de los
miembros del equipo.
c. Menciona los recursos y tecnologías que se utilizarán para llevar
a cabo el proyecto.
- Plan de implementación y cronograma:
a. Proporciona una visión general del plan de implementación de la
solución propuesta.
b. Destaca los hitos clave y los plazos asociados.
c. Explica cómo se gestionará y controlará el proyecto para
garantizar una ejecución exitosa.
- Presupuesto y detalles contractuales:
a. Proporciona una estimación de costos para la implementación de
la solución propuesta.
b. Menciona cualquier consideración adicional relacionada con los
términos contractuales, como garantías, soporte post-
implementación, etc.
- Conclusión:
a. Resume los principales puntos de la respuesta a la RFP.
b. Reafirma el compromiso de tu empresa para cumplir con los
requisitos y expectativas del cliente.
c. Invita al cliente a tomar contacto para discutir más detalles o
aclaraciones necesarias.
3.2.3 Respuesta a los requerimientos administrativos
Si nos lo piden explícitamente los clientes, ellos nos podrán una lista de
cosas a las que responder, en otro caso, los requerimientos administrativos
que suelen pedir los clientes son:
1. Experiencia y expertise del equipo: destacamos la experiencia y
calificaciones de su equipo, certificados de la empresa, formación de
los equipos, experiencia laboral relevante y certificaciones
profesionales. Esto brinda confianza en su capacidad para cumplir con
los requisitos del proyecto.
2. Plan de gestión del proyecto: se incluye un plan detallado de cómo se
gestionará el proyecto, incluyendo la asignación de recursos, el
cronograma, las actividades clave y la estrategia de gestión del riesgo.
39
3. Políticas y procedimientos: documentamos las políticas y
procedimientos que nuestra empresa tiene en vigor para garantizar la
calidad, la gestión de riesgos, la seguridad de los datos, la protección
del medio ambiente y el cumplimiento normativo.
4. Cumplimiento legal y regulatorio: nos aseguramos de incluir una parte
donde se indique que cumplimos con todas las leyes y regulaciones
aplicables en el ámbito del proyecto. Proporcionar una prueba de
cumplimiento, como licencias, permisos y certificaciones requeridas
son algo muy favorecedor.
5. Seguro y responsabilidad: tenemos que indicar el tipo de seguro de
responsabilidad civil que posee nuestra empresa y el alcance de la
cobertura. Esto brinda protección tanto a su empresa como al cliente
en caso de cualquier eventualidad durante el proyecto.
6. Plan de comunicación: desarrollaremos un plan de comunicación que
establezca cómo mantendremos informado al cliente sobre el progreso
del proyecto, los hitos alcanzados, los problemas identificados y las
soluciones propuestas.
En algunas ocasiones nos podrán permitir responder de forma alternativa:
• Estructura del documento de la RFP.
• Una respuesta alternativa a como realizar la RFP, a veces nos piden
precio cerrado y podemos proponer un Time & Material o incluso para
poder hacer lo que nos piden podemos proponer una assessment.
Siempre que queráis ir por este lado preguntar de formar escrita al
cliente preguntando si esto nos descalificaría de la propuesta.
Como cliente me he encontrado que en esta primera reunión el proveedor llega
sin que esté alguien del equipo de arquitectura, esto es un error muy grave por
parte del proveedor. Como proveedor esto nunca debe ocurrirte y como cliente
esto es una bandera roja muy importante.
Al igual que os pongo lo que suelo ver en esta área, como cliente existen cosa
que no me gusta ver, es un error común en muchas respuestas: que los
proveedores incluyan términos o cláusulas de contratos dentro de la sección
40
administrativa. Aquí no estamos tratando de condiciones, de contratos o
términos legales.
3.2.3.1 Anatomía de la sección administrativa
Veamos los elementos comunes de una sección técnica. Cuando
respondemos a la RFP los clientes suelen quedarse en la parte de formatos de
ficheros, integraciones con terceros, Stack tecnológico de su organización,
etc. Lo que deberían incluir y casi nunca lo incluyen nos servirá como guía
para poder responder como proveedor y a los clientes esto os servirá de guía
para saber cómo afrontar esta sección.
Los puntos habituales son:
1. Plan del proyecto: plan detallado del proyecto que incluya los
objetivos, los hitos clave, las entregas y los recursos necesarios.
Explicaremos cómo abordar el alcance, los plazos y la asignación de
recursos para garantizar la finalización exitosa del proyecto.
2. Cronograma del proyecto: cronograma detallado que muestre las
diferentes etapas del proyecto, las fechas estimadas de inicio y
finalización, y los hitos importantes. Utiliza herramientas como
diagramas de Gantt para visualizar el cronograma de manera clara y
concisa.
3. Plan de preparación del sitio y responsabilidades: si el proyecto implica
la instalación o implementación en un sitio específico, describe cómo
te encargarás de preparar el sitio. Incluye tareas como la instalación de
infraestructura, configuraciones técnicas y cualquier requisito de
preparación previa al despliegue. Asigna responsabilidades claras a tu
equipo y, si es necesario, a otros proveedores o al cliente.
4. Requisitos de personal: especifica los recursos humanos necesarios
para el proyecto, incluyendo habilidades y roles específicos. Define el
equipo de proyecto necesario, como gerentes, desarrolladores,
diseñadores, especialistas en calidad, etc. Describe el proceso de
selección y asegúrate de resaltar la experiencia y las habilidades
relevantes del personal propuesto.
5. Diseño, desarrollo e implementación: detalla tu enfoque para el diseño
y desarrollo de la aplicación informática. Explica cómo trabajarás con
41
el cliente para recopilar requisitos, diseñar la arquitectura, desarrollar
el software y realizar pruebas exhaustivas. Destaca tus metodologías,
herramientas y enfoques de calidad para garantizar un resultado
exitoso.
6. Entrega e instalación: describe cómo se llevará a cabo la entrega y la
instalación de la aplicación informática en el entorno del cliente.
Menciona cualquier proceso de migración de datos, configuración y
puesta en marcha que sea necesario. Asegúrate de abordar los plazos y
la coordinación necesaria con el cliente y otros proveedores
involucrados.
7. Pruebas de aceptación del sistema: explica cómo llevarás a cabo las
pruebas de aceptación del sistema para asegurarte de que la aplicación
cumple con los requisitos definidos. Describe los criterios de
aceptación, las estrategias de prueba y los procedimientos para la
identificación y resolución de problemas.
8. Mantenimiento del sistema: describe cómo proporcionarás el
mantenimiento continuo del sistema una vez que esté implementado.
Detalla los servicios de soporte, las actualizaciones del software, las
correcciones de errores y cualquier otro aspecto relacionado con el
mantenimiento y la estabilidad a largo plazo del sistema.
9. Capacitación: explica cómo llevarás a cabo la capacitación para los
usuarios finales de la aplicación. Describe los materiales de
capacitación, las metodologías de enseñanza y los enfoques de
seguimiento para garantizar que los usuarios comprendan y puedan
utilizar eficazmente la aplicación.
10. Documentación: indica cómo crearás y proporcionarás documentación
detallada sobre la aplicación, incluyendo manuales de usuario, guías de
instalación, documentación técnica y cualquier otra documentación
relevante. Destaca la importancia de una documentación clara y
concisa para facilitar el uso y el mantenimiento del sistema.
Muchas veces esta sección se ve afectada una vez ganada la propuesta.
Quiero decir, que, aunque la propuesta está ganada, muchos clientes añaden
clausulas al contrato que hacen que el precio y el alcance definido en esta
42
área se ve a afectado tanto por como se aborda como por el precio que
cambia.
Como podría ampliar esta sección, pues depende del proyecto y lo que
quieras que llegue a engordar:
1. Plan de recuperación ante desastres: describe tu enfoque para
garantizar la continuidad del negocio y la recuperación de datos en
caso de un evento adverso. Explica cómo identificarás y evaluarás los
posibles riesgos y amenazas, y cómo desarrollarás estrategias y
procedimientos para minimizar el impacto de los desastres.
2. Metodología de gestión de proyectos: explica la metodología que
utilizarás para gestionar el proyecto. Puedes mencionar enfoques ágiles
como Scrum o Kanban, así como cualquier otro marco de trabajo o
proceso específico que hayas desarrollado internamente.
3. Gestión de riesgos: identifica los posibles riesgos asociados con el
proyecto y explica cómo los mitigarás o gestionarás de manera
proactiva. Menciona cualquier enfoque específico que hayas
desarrollado para la gestión de riesgos, como la realización de
evaluaciones periódicas y la implementación de planes de
contingencia.
4. Comunicación y colaboración: describe cómo mantendrás una
comunicación fluida y eficaz con el cliente y otros stakeholders del
proyecto. Destaca las herramientas que utilizarás para facilitar la
colaboración, como sistemas de gestión de proyectos, plataformas de
comunicación y reuniones regulares.
5. Gestión del cambio: explica cómo abordarás los cambios en los
requisitos del proyecto o las solicitudes adicionales del cliente. Destaca
tu capacidad para adaptarte a las necesidades cambiantes y mantener
la transparencia en la gestión de cambios.
6. Estándares: describe los estándares que seguirás durante el desarrollo y
la implementación de la aplicación informática. Esto puede incluir
estándares de codificación, estándares de seguridad de la información,
estándares de interoperabilidad y cualquier otro estándar relevante
para el proyecto. Explica cómo cumplirás con estos estándares y cómo
garantizarás su cumplimiento a lo largo del proyecto.
43
7. Transiciones del proyecto (Project Cutovers): si el proyecto implica
transiciones críticas entre fases o sistemas existentes, explica cómo
planificarás y ejecutarás estas transiciones de manera eficiente.
Describe los pasos y las actividades necesarias para minimizar los
riesgos y garantizar una transición fluida y exitosa.
8. Problemas y preocupaciones de los proveedores (Supplier Issues and
Concerns): si tu proyecto involucra a proveedores externos, explica
cómo gestionarás cualquier problema o preocupación relacionada con
ellos. Describe tu enfoque para establecer y mantener una
comunicación clara con los proveedores, así como los mecanismos de
resolución de conflictos y las estrategias para minimizar los impactos
negativos en el proyecto.
La administración del proyecto es un factor clave en la evaluación,
determinar si somos elegidos o no, mucho antes que la solución técnica, a
muchos clientes les da igual como estén las tripas mientras el engranaje
funcione y obtengan el valor que desean con la aplicación. Dependiendo del
proyecto esta sección tiene mucho más peso que la solución técnica.
Esta sección los clientes la utilizan para ver la fuerza y debilidades de nuestra
organización.
3.2.4 Respuesta a los requerimientos técnicos
En esta sección nosotros, los proveedores estamos respondiendo a los
requerimientos, servicios, formaciones, etc. que quiere comprar el cliente.
Esto es el corazón de la RFP es donde la información que ofrecemos hace que
un cliente se decante o no por la propuesta, aunque muchas veces mandan
las variables tiempo y dinero sobre lo bien que está presentada y pensada la
RFP.
Aquí no estamos vendiendo un producto o nuestro producto, algunos
proveedores se enrocan en vender algún producto de los que son socios, y
cuando este ocurre te tienen que vender una modificación o extensión que se
adapte a tu negocio. He vivido un memorándum donde la dirección hacía
hincapié en montar el estándar a toda costa y cambiar los procesos al cliente.
Por eso no es lo mismo que un cliente te diga “quiero un coche donde entren 6
44
personas”, a que te pida “quiero un coche negro con 5 puertas que pueda hacer
un trayecto de 800Km sin repostar, que consuma menos de 5.4L/100KM y que
entren cómodamente 6 personas”.
Y gracias al anterior ejemplo os puedo decir que el cliente podrá encontrar
100 proveedores que cumplan esos requerimientos mínimos, pero
seguramente habrá 5 o menos que puedan cumplir la mayoría de los
requerimientos detallados que el cliente pide. Y por tanto será el cliente
quien decida que gana y que pierde, si es que ningún proveedor es capad de
ofrecer todo lo que pide.
Como proveedor para no perder el norte cuando respondo a la petición de
requisitos es:
1. Focalizar que tecnología me puede ayudar a cumplir la mayoría de los
requisitos obligatorios.
2. E identificar aquellos requisitos que no puedo cumplir, para buscar
alternativas o bien para responder directamente que no es posible.
Como he estado hablando de requisitos, vamos a ver que son, para que
sepamos identificarlos bien.
3.2.4.1 Requisitos
Una RFP es una colección de requerimientos que definen un producto o
servicio, por tanto, la primera pregunta que nos debemos responder es ¿Qué
es un requerimiento?
Los requerimientos se refieren a las funcionalidades, características y
restricciones que un sistema o software debe cumplir para satisfacer las
necesidades de los usuarios, los clientes y otras partes interesadas. Los
requerimientos son descripciones detalladas de lo que se espera que el
sistema realice o logre.
Los requerimientos pueden incluir aspectos como las funcionalidades
específicas que debe tener el sistema, los comportamientos esperados, los
requisitos de rendimiento, las restricciones técnicas o de recursos, los
45
criterios de usabilidad y cualquier otro elemento necesario para definir el
alcance y el funcionamiento del sistema.
Los requerimientos son las especificaciones y condiciones necesarias que se
deben cumplir para desarrollar un sistema de software eficaz.
Por ejemplo, en una RFP sobre un software de tienda on-line, uno de los
requerimientos es que la factura se imprima en papel y se adjunte al pedido
físico. ¿Cuáles serían los requerimientos identificados por el usuario?
1. Debe debe imprimir junto a la etiqueta de envío y devolución.
2. El formato de la factura: la factura debe ser impresa en papel normal y
otra parte es pegatina para las etiquetas, A4, con la fuente corporativa.
3. El contenido de la factura: debe contener nombre y dirección del
vendedor, nombre y dirección del comprador, descripción de los
productos o servicios adquiridos, precios unitarios, cantidades,
impuestos aplicables, total a pagar.
4. El idioma de la factura: el idioma en el que debe estar redactada la
factura impresa es el que indique el perfil del usuario.
5. Se debe adjuntar al pedido físico: debe existir un mecanismo de
control que asegurarse que la factura impresa se adjunte físicamente al
pedido al momento de ser enviado, de manera que llegue al
destinatario junto con los productos adquiridos.
6. Debe poder ser enviado en copia digital: además de la versión impresa
adjunta al pedido físico, nos debe enviar un PDF en un mail y una
copia en el perfil del usuario disponible para su descarga desde el sitio
web de la tienda online. Además, el PDF debe ser generado
automáticamente a partir de la información de la factura y debe incluir
todos los detalles pertinentes, como el nombre y dirección del
vendedor, el nombre y dirección del comprador, la descripción de los
productos o servicios adquiridos, los precios unitarios, las cantidades,
los impuestos aplicables y el total a pagar.
7. Cumplimiento legal: debe cumplir con los requisitos legales y fiscales
aplicables en la jurisdicción correspondiente, incluyendo información
obligatoria, numeración de facturas, requisitos de conservación de
registros, etc.
46
Los anteriores requerimientos son requerimientos de negocio y técnicos.
Pocas veces vendrán separados de los requerimientos técnicos y funcionales,
habitualmente vendrá mezclado como por ejemplo el punto 6.
Como proveedor una pista que nos indica que estamos ante un
requerimiento, ya sea técnico o funcional, es que encontremos frases con
verbos que indican un tipo de intención, como, por ejemplo:
Debe indica un requerimiento, me aventuro a decir, que en cualquier RFP
que lo encuentres indica un requerimiento. Por ejemplo, “debe cumplir con
los requisitos legales …” (punto 7)
Debería, suele utilizarse para expresar un objetivo a alcanzar. Muchas veces
parece que no es un requerimiento tal y como se puede usar, pero sí que es
un requerimiento ya que el cliente esta diciendo que espera algo. Por
ejemplo, “el programa debería mandar un mail con un pdf adjunto, …”
Deseo, realizará, … verbos de la familia del “indicativo”, se usa más como una
intención. Por ejemplo, “deseo que el proveedor pueda incluir una solución
que permita seguir usando las impresoras que usamos en el almacén…”
Los anteriores ejemplos nos llevan a realizar un pequeño paréntesis: ¿qué
diferencia existe entre un requerimiento y una especificación?
A veces se usan de forma intercambiada, pero existen diferencias sutiles
entre estos términos.
Los requerimientos son declaraciones de alto nivel que describen las
necesidades y funciones esperadas del sistema, mientras que las
especificaciones son documentos más detallados que proporcionan la
información técnica necesaria para implementar y construir el sistema de
software de acuerdo con los requerimientos establecidos. Las
especificaciones se basan en los requerimientos y actúan como una guía
técnica para los equipos de desarrollo.
Debe Debería
Deseo,
realizará, ...
47
También puedes definir los requerimientos como una suma de
especificaciones. Las especificaciones se centran en el "cómo" se cumplirán
los requerimientos. Proporcionan detalles técnicos, descripciones de
interfaces, reglas de validación, formatos de datos, algoritmos y cualquier
otro aspecto necesario para implementar y construir el sistema de software.
Las especificaciones son más detalladas y se utilizan como referencia para el
diseño.
Los requerimientos los podemos encontrar definidos en estas categorías:
Preguntas
Que vienen a denotar una serie de peticiones ocultas o más bien problemas
ocultos que los proveedores debemos saber responder. Por ejemplo:
• ¿El sistema permite a los usuarios registrarse y crear una cuenta?
• ¿Es posible realizar búsquedas por nombre de producto en la tienda en
línea?
• ¿El sistema proporciona un carrito de compras para que los usuarios
agreguen productos antes de realizar el pago?
Podéis observar que para cada pregunta podemos escribir cientos y cientos
de líneas y diagramas, según se nos ocurra. Para no caer en esta “trampa”
podemos tomar dos decisiones:
• Responder con asunciones.
• Hacer preguntas al cliente para que concrete que es lo que necesita.
las asunciones se refieren a las suposiciones o premisas que se hacen al
elaborar la propuesta. Estas asunciones son declaraciones que se consideran
verdaderas o válidas en el contexto de la propuesta, pero que no se pueden
confirmar o garantizar con certeza absoluta.
Las asunciones en una propuesta ayudan a establecer ciertos parámetros y
aclarar los límites o condiciones en las que se desarrollará el proyecto.
Algunas de las áreas comunes en las que se pueden incluir asunciones en una
son:
48
1. Restricciones técnicas: Se pueden hacer asunciones sobre la
disponibilidad de tecnologías o herramientas específicas, la
compatibilidad con sistemas existentes, requisitos de infraestructura, etc.
2. Restricciones de recursos: Pueden incluir asunciones sobre la
disponibilidad de personal, habilidades técnicas, equipo necesario,
capacidad de financiamiento, etc.
3. Cronograma y plazos: Se pueden realizar asunciones sobre la duración del
proyecto, las fechas de entrega, los hitos importantes, la disponibilidad de
recursos clave, etc.
4. Requisitos legales o regulatorios: Pueden incluir asunciones sobre el
cumplimiento de ciertas leyes, regulaciones o estándares específicos.
5. Condiciones del entorno: Se pueden realizar asunciones sobre el entorno
operativo, el acceso a datos o recursos externos, el nivel de colaboración
con otras partes interesadas, etc.
Es importante que las asunciones se identifiquen y se comuniquen
claramente en una propuesta para que todas las partes involucradas tengan
una comprensión común de los supuestos en los que se basa la propuesta.
Esto ayuda a evitar malentendidos y a establecer expectativas realistas
durante el proceso de licitación y ejecución del proyecto.
Cuidado con responder con un monosílabo a las respuestas anteriores,
muchas veces a la pregunta: ¿El sistema permite a los usuarios registrarse y
crear una cuenta? La respondemos con un sí (categórico) que conlleva a que
el cliente pida absolutamente todo lo que se le pase por la cabeza: “ahora
quiero un captcha”, “ahora quiero integración con SSO de Google, de
Twitter”, mañana querrá “Facebook” así de forma indefinida. Lo ideal es
responder con una serie de supuestos: te permitimos como máximo un SSO,
no tendrá opción de cambio de contraseña, solo se permiten nombre de
usuario y no cuentas de email, etc. etc.
Declaraciones
Por ejemplo:
• El sistema debe ser PCI Compliance.
49
• El SLA debe ser de un 99,99%.
• El sistema de pagos debe admitir pago con tarjeta bancaria y PayPal.
Para los usuarios registrados también vamos a permitir pagar con
transferencia bancaria.
Este tipo de declaraciones pueden llegar provocar una situación incomoda a
los proveedores, podemos responder sí (categórico) como en las preguntas,
pero además estamos dando pie a que no nos esforcemos en responder o que
respondamos con una cantidad innecesaria de información.
Cuando un cliente nos de este tipo de declaraciones debemos llevarlas a
nuestro terreno, crear cuanta asunciones veamos necesarias, plantear
restricciones técnicas o comerciales. Para dejar unas claras expectativas al
cliente y evitar situaciones incomodas o conflictos en el proceso de ejecución
del proyecto.
Descripción narrativa
Se refiere a una forma de expresar los requerimientos mediante narrativas o
historias que describen escenarios o situaciones específicas en los que se
espera que el sistema cumpla ciertas funcionalidades. Por tanto, no permiten
el uso de declaraciones y preguntas.
La descripción narrativa ayuda a visualizar y comprender mejor los
requerimientos en acción, permitiendo a los equipos de desarrollo e
involucrados en el proyecto obtener una visión más clara de cómo se espera
que el sistema funcione en situaciones de la vida real. Esto puede ayudar a
identificar posibles mejoras, detectar conflictos o inconsistencias en los
requerimientos, y brindar una base sólida para el diseño y desarrollo del
sistema.
Las narrativas descriptivas pueden incluir detalles sobre el contexto del
usuario, las interacciones con el sistema, las acciones realizadas y las
respuestas esperadas. Por ejemplo, una descripción narrativa podría contar
una historia sobre un usuario que visita una tienda en línea, navega por los
productos, agrega artículos al carrito de compras, realiza el pago y recibe una
confirmación de compra.
Por ejemplo:
50
Mónica, una usuaria registrada de nuestra tienda en línea, desea
acceder a su cuenta para realizar una compra. Al ingresar al sitio web,
se encuentra con la página de inicio de sesión, donde se le solicita que
ingrese su dirección de correo electrónico y su contraseña.
Mónica ingresa su dirección de correo electrónico asociada a su cuenta
y luego teclea su contraseña en el campo correspondiente. Después de
hacer clic en el botón 'Iniciar sesión', el sistema verifica la información
ingresada.
Si los datos son correctos, Mónica es redirigida a su perfil de usuario,
donde puede ver su historial de compras, actualizar su información
personal y acceder a funciones adicionales. Además, se muestra un
mensaje de bienvenida personalizado para hacerla sentir valorada
como cliente.
En caso de que Mónica ingrese una dirección de correo electrónico o
contraseña incorrectas, el sistema le muestra un mensaje de error
indicando que los datos ingresados son inválidos. Además, se le ofrece
la opción de restablecer su contraseña en caso de haberla olvidado.
La sesión de Mónica se mantiene activa durante un período
determinado de inactividad, para que pueda explorar el sitio web sin
necesidad de iniciar sesión nuevamente. Sin embargo, si Mónica
decide cerrar sesión manualmente, se le muestra un mensaje de
confirmación y se redirige a la página de inicio.
En resumen, el proceso de inicio de sesión permite a Mónica, nuestra
usuaria registrada, acceder de manera segura a su cuenta,
proporcionando su dirección de correo electrónico y contraseña. Si los
datos son correctos, se le redirige a su perfil de usuario con un mensaje
de bienvenida personalizado. En caso de error, se le notifica y se le
brinda la opción de restablecer su contraseña. Además, se ofrece la
opción de mantener la sesión activa durante un período determinado
de inactividad
Y los requerimientos que hemos podido extraer de este texto son:
51
1. Autenticación: El sistema debe permitir a los usuarios registrados
ingresar su dirección de correo electrónico y contraseña para
autenticarse y acceder a sus cuentas.
2. Verificación de datos: El sistema debe verificar la información
ingresada por el usuario durante el inicio de sesión para garantizar la
precisión de los datos y la seguridad del acceso.
3. Redirección y acceso al perfil de usuario: Después de una autenticación
exitosa, el sistema debe redirigir al usuario a su perfil de usuario,
donde puede ver su historial de compras, actualizar información
personal y acceder a funciones adicionales.
4. Mensaje de bienvenida personalizado: El sistema debe mostrar un
mensaje de bienvenida personalizado al usuario una vez que haya
iniciado sesión, con el objetivo de hacerlo sentir valorado y brindar
una experiencia personalizada.
5. Gestión de errores: El sistema debe ser capaz de manejar y mostrar
mensajes de error adecuados en caso de que se ingresen datos
incorrectos durante el inicio de sesión, notificando al usuario que los
datos son inválidos.
6. Restablecimiento de contraseña: En caso de que se ingrese una
contraseña incorrecta o se olvide, el sistema debe proporcionar una
opción para que el usuario restablezca su contraseña, garantizando así
la capacidad de recuperar el acceso a su cuenta.
7. Sesión activa: El sistema debe permitir que la sesión del usuario
permanezca activa durante un período determinado de inactividad, lo
que evita que el usuario tenga que iniciar sesión nuevamente cada vez
que realice acciones en el sitio web.
Cuando nos enfrentamos a una narrativa, los proveedores podemos
enfrentarnos a una serie de problemas:
1. Ambigüedad en los requerimientos: Si la RFP está redactada de manera
narrativa, puede haber ambigüedad en los requerimientos o falta de
claridad en lo que se espera del proveedor. Las narrativas pueden ser
interpretadas de diferentes maneras, lo que puede llevar a respuestas
divergentes y dificultar la comparación de las propuestas recibidas.
52
2. Falta de estructura y detalles: Las narrativas pueden carecer de la
estructura y los detalles necesarios para que los proveedores
comprendan plenamente los requerimientos y presenten propuestas
sólidas. La falta de información específica puede dificultar la
estimación precisa de los costos, los recursos necesarios y los plazos de
entrega.
3. Dificultad para cumplir con los criterios de evaluación: Si los criterios
de evaluación no están claramente definidos en una RFP narrativa, los
proveedores pueden tener dificultades para comprender cómo se
evaluarán y se seleccionarán las propuestas. Esto puede llevar a
respuestas inadecuadas o a una falta de enfoque en los aspectos que
son más importantes para los solicitantes.
4. Desalineación de expectativas: Las narrativas pueden dejar espacio
para diferentes interpretaciones y expectativas entre los proveedores y
los solicitantes. Esto puede generar discrepancias en las propuestas
presentadas y dificultar el logro de un acuerdo común sobre los
requisitos y las soluciones propuestas.
5. Dificultad para demostrar cumplimiento: Si los requisitos se expresan
en forma narrativa, los proveedores pueden encontrar desafíos para
demostrar de manera clara y concreta cómo cumplirán con esos
requerimientos. La falta de una estructura más precisa puede dificultar
la presentación de argumentos sólidos y evidencias de que se
cumplirán las necesidades del cliente.
Para mitigar estos problemas, es importante que los clientes proporcionen
orientación adicional, claridad y detalles. Pero como seguramente el cliente
no nos lo dé así, debemos extraer secciones detalladas para que podamos
hacer preguntas claras y presentar la propuesta de la forma más precisa y
alineada con las expectativas del cliente.
Los requisitos deben cumplir unos mínimos de calidad, sin esto, los
proveedores tenemos la potestad de decirlo claramente al cliente. Si no ves esto
en la propuesta del cliente, deberías empezar a pensar mal del cliente.
53
Sobre la calidad de los requisitos
• Los requisitos deben reflejar productos o servicio reales. Los requisitos
deben reflejar con precisión las funcionalidades, características y
restricciones que se requieren en el producto o servicio final. Los
requisitos deben ser realistas y alcanzables, considerando las
limitaciones técnicas, los recursos disponibles y las necesidades del
cliente. Al asegurarse de que los requisitos reflejen productos o
servicios reales, se evita la creación de requisitos excesivamente
ambiciosos o poco prácticos que no se puedan lograr en la
implementación. También ayuda a establecer expectativas claras y
realistas entre los stakeholders, los equipos de desarrollo y los clientes.
Además, los requisitos que reflejan productos o servicios reales
brindan una base sólida para el diseño, desarrollo y prueba del sistema.
Ayudan a garantizar que el producto final cumpla con las necesidades
y expectativas de los usuarios, y que sea funcionalmente coherente con
lo que se espera lograr.
• Los requerimientos no deben ser ambiguos. Significa que los
requerimientos deben ser claros, precisos y libres de ambigüedad.
Cuando los requerimientos son ambiguos, existen diferentes
interpretaciones posibles o falta de claridad sobre lo que se espera.
Esto puede llevar a malentendidos, problemas de comunicación y
resultados insatisfactorios. Los requerimientos ambiguos pueden
dificultar la implementación del sistema, ya que los desarrolladores
pueden tener dificultades para comprender completamente los
objetivos y las funcionalidades requeridas. Para evitar ambigüedades
en los requerimientos, es importante que estén redactados de manera
clara, específica y sin ambigüedades. Deben ser lo suficientemente
detallados y preciso para que no quede lugar a dudas o
interpretaciones erróneas. Además, es importante establecer un
proceso de revisión y validación de los requerimientos para garantizar
que se entiendan correctamente y sean consistentes con las
necesidades y expectativas de los stakeholders involucrados.
• Los requisitos no deben estar redactados de forma ambigua. Significa
que, al definir los requisitos, es importante evitar cualquier tipo de
54
ambigüedad en su redacción. Esto implica que los requisitos deben ser
claros, precisos y no dejar lugar a interpretaciones diversas o
confusiones. La ambigüedad en los requisitos puede conducir a
malentendidos, dificultades en la implementación y resultados
insatisfactorios en el desarrollo del software. Cuando los requisitos son
ambiguos, los desarrolladores pueden tener dificultades para
comprender exactamente lo que se espera de ellos y pueden tomar
decisiones incorrectas o basadas en suposiciones incorrectas. Para
evitar la ambigüedad, los requisitos deben ser expresados de manera
precisa, utilizando un lenguaje claro y conciso. Deben describir
claramente qué se espera del sistema, qué funcionalidades o
características debe tener, qué restricciones existen y cualquier otro
detalle relevante. Además, es importante que los requisitos sean
coherentes entre sí y no entren en conflicto. Cuando se redactan los
requisitos, es útil ser específico y evitar términos vagos o ambiguos. Es
importante tener en cuenta el contexto y las necesidades de los
usuarios y las partes interesadas para asegurarse de que los requisitos
sean comprensibles y abarquen todas las expectativas relevantes. Al
mantener los requisitos libres de ambigüedad, se facilita la
comunicación clara y efectiva entre los equipos de desarrollo, los
stakeholders y los proveedores de software, lo que ayuda a garantizar
que el sistema se construya de acuerdo con las expectativas y
necesidades establecidas.
• Los requisitos deben ser medibles. Significa que los requerimientos
establecidos deben ser específicos y cuantificables, de manera que sea
posible evaluar y verificar su cumplimiento de manera objetiva y clara.
Cuando se establece que los requisitos deben ser medibles, se busca
evitar ambigüedades y asegurar que se puedan establecer criterios
claros para determinar si un requerimiento ha sido satisfecho o no.
Esto implica que los requisitos deben ser formulados de tal manera que
permitan definir métricas, indicadores o criterios de éxito para evaluar
su cumplimiento. Al ser medibles, los requisitos se convierten en
objetivos alcanzables y evaluables, lo que facilita la planificación, el
seguimiento y la verificación del progreso del proyecto. Además, la
medición permite realizar pruebas de aceptación para validar que los
55
requerimientos se cumplen adecuadamente. Por ejemplo, en lugar de
tener un requerimiento vago como "el sistema debe ser rápido", un
requisito medible sería "el sistema debe cargar una página en un
tiempo máximo de 250 ms ". En este caso, el tiempo de carga se
convierte en una métrica objetiva que puede ser medida y comparada
con el objetivo establecido.
• Los requisitos deben ser significativos. Implica que los requisitos
establecidos en un contexto determinado deben ser relevantes,
importantes y tener un impacto significativo en el sistema o proyecto
en cuestión. Cuando se menciona que los requisitos deben ser
significativos, se enfatiza la importancia de establecer requerimientos
que sean relevantes para el objetivo y la finalidad del proyecto. Estos
requisitos deben contribuir de manera significativa al funcionamiento,
rendimiento o valor general del sistema que se está desarrollando. Al
asegurarse de que los requisitos sean significativos, se evita incluir
elementos innecesarios o superfluos que puedan agregar complejidad o
costos adicionales sin un beneficio real. Por lo tanto, se busca
establecer requerimientos que sean esenciales para cumplir con los
objetivos y satisfacer las necesidades de los usuarios o las partes
interesadas involucradas. Es importante tener en cuenta que el
significado de los requisitos puede variar según el contexto y los
objetivos específicos del proyecto. Por lo tanto, es fundamental definir
claramente los criterios y métricas para determinar la relevancia y el
significado de los requisitos, lo que puede facilitar la toma de
decisiones y la priorización adecuada durante el proceso de desarrollo
del software.
• El requisito debe estar completo. Indica que el requisito en cuestión
debe estar detallado de manera exhaustiva y no debe haber
información faltante o ambigua. En otras palabras, se espera que el
requisito esté totalmente especificado, sin dejar cabos sueltos o
ambigüedades que puedan generar confusiones o malentendidos
durante el proceso de desarrollo o implementación del sistema de
software. Al requerir que un requisito esté completo, se busca
garantizar que todas las partes involucradas tengan una comprensión
clara y precisa de lo que se espera y que no queden aspectos abiertos a
56
la interpretación. Esto es esencial para la correcta implementación del
requisito y para evitar malentendidos o desviaciones en el desarrollo
del software. Un requisito completo debe incluir todos los detalles
necesarios, como las funcionalidades específicas que se requieren, los
comportamientos esperados, los criterios de rendimiento, las
restricciones técnicas o de recursos, y cualquier otro elemento
relevante para definir completamente el alcance y el funcionamiento
del sistema. Si esto no sucede añade todas las asunciones posibles para
dejarlo lo más detallado posible por tu parte al escribir la respuesta a la
RFP.
• Los requerimientos no deben incluir la solución. Significa que, al
definir los requerimientos de un proyecto o sistema, es importante
enfocarse en describir qué se necesita lograr, en lugar de como se debe
lograr. Cuando se definen los requerimientos, se busca establecer las
funcionalidades, características y restricciones del sistema de software,
sin entrar en detalles específicos de cómo implementar esas
funcionalidades. Los requerimientos deben centrarse en los "qué" en
lugar de en el "cómo". La razón detrás de esta recomendación es
permitir flexibilidad y opciones al equipo de desarrollo. Al evitar la
especificación de la solución en los requerimientos, se da libertad al
equipo para explorar diferentes enfoques y tecnologías que puedan
cumplir con los requerimientos de manera eficiente y efectiva. Al
separar los requerimientos de la solución, también se evita limitar las
opciones y las posibilidades de innovación. Permite que el equipo de
desarrollo utilice su experiencia y conocimientos para encontrar la
mejor manera de abordar los requerimientos, adaptándose a las
condiciones y restricciones del proyecto.
• Los requisitos no deben incluir características superfluas e
innecesarias. Se refiere a la importancia de evitar la inclusión de
funcionalidades o elementos en los requisitos de un proyecto o sistema
que no sean realmente necesarios o que no aporten valor significativo.
En el contexto de la ingeniería de software, los requisitos son las
descripciones detalladas de las funcionalidades, comportamientos y
restricciones que se esperan de un sistema o software. Estos requisitos
definen qué debe hacer el sistema y cómo debe comportarse para
57
satisfacer las necesidades de los usuarios y clientes. La frase indica que
se debe evitar agregar características adicionales o innecesarias en los
requisitos. Esto significa que se deben incluir únicamente las
funcionalidades esenciales y relevantes para cumplir con los objetivos
del sistema y las necesidades de los usuarios. No se deben agregar
características superfluas que puedan complicar la implementación,
aumentar los costos, afectar el rendimiento o confundir a los usuarios.
Al mantener los requisitos enfocados en las necesidades reales y
esenciales, se busca optimizar el proceso de desarrollo y garantizar que
los recursos se utilicen de manera eficiente para implementar las
funcionalidades fundamentales y valiosas para los usuarios finales.
¿Requisitos técnicos?
Son aquellos que los clientes nos cuentan, de forma narrativa (a veces
acompañada de ilustraciones), lo que hacen y por qué lo hacen.
Habitualmente vienen expresados como una “necesidad”, por ejemplo:
• Necesitamos que nuestros clientes puedan ver el stock en tiempo real,
no queremos hacer esperar a nuestros clientes.
• Para que la experiencia de compra esté en consonancia con nuestros
productos deportivos necesitamos que la tienda on-line transmita
nuestros valores.
• Necesitamos que el conocimiento técnico tras la ejecución del
proyecto quede dentro de nuestra organización.
Como podéis observar, todas las frases están construidas más o menos igual:
• Necesidad, stock en tiempo real.
• Objetivo, proporcionar información actualizada al cliente.
• Razón de negocio, no hacer esperar a los clientes.
Por lo tanto, esto requerimientos cumplen con un punto importante: que
sean medibles:
58
Requerimiento Objetivo Medición
..puedan ver el
stock…
Proporcionar
información
actualizada al cliente.
Se pueden usar diferentes
acciones:
- Tiempo de respuesta
del stock.
- Precisión del stock.
- Nivel de satisfacción
del cliente.
3.2.4.2 Anatomía de la sección técnica
Veamos los elementos comunes de una sección técnica. Cuando
respondemos a la RFP los clientes suelen quedarse en la parte de formatos de
ficheros, integraciones con terceros, Stack tecnológico de su organización,
etc. Lo que deberían incluir y casi nunca lo incluyen nos servirá como guía
para poder responder como proveedor y a los clientes esto os servirá de guía
para saber cómo afrontar esta sección.
Actual entorno empresarial (funcional)
Se refiere al contexto y los elementos existentes en la organización
solicitante antes de la implementación de la nueva aplicación. Es importante
describir el actual entorno empresarial para que los proveedores de software
comprendamos los sistemas, las tecnologías y los procesos que ya están en
uso. Esto permite evaluar cómo la solución propuesta se integrará con el
entorno existente y cumplirá con los requisitos y necesidades específicas de
la organización.
Algunos aspectos que se pueden incluir en la descripción del actual entorno
empresarial son:
1. Infraestructura tecnológica: implica describir los sistemas operativos,
bases de datos, servidores, redes y otros componentes de
infraestructura utilizados en la organización.
2. Aplicaciones y sistemas existentes: se deben mencionar las
aplicaciones de software y los sistemas utilizados actualmente en la
organización, indicando sus funciones, integraciones y limitaciones.
59
3. Procesos y flujos de trabajo: se debe describir cómo se llevan a cabo las
operaciones y los procesos empresariales en la organización,
incluyendo cualquier flujo de trabajo, automatizaciones o
integraciones existentes.
4. Políticas y estándares: se deben mencionar las políticas y los
estándares tecnológicos en vigor en la organización, como políticas de
seguridad, requisitos de cumplimiento normativo u otras directrices
relevantes.
Por ejemplo, que podría pedirnos un cliente:
"[Nombre_Tienda]" nos hemos expandido significativamente en los
últimos años y hemos experimentado un aumento en el volumen de
pedidos y la gestión del inventario. Actualmente, gran parte de los
procesos, como la actualización manual del inventario, el seguimiento
de envíos y la generación de informes, se realizan de forma manual, lo
que ha llevado a errores, retrasos y una falta de eficiencia operativa.
Para abordar estos desafíos, "[Nombre_Tienda]" hemos decidido
buscar una solución tecnológica que automatice y optimice sus
operaciones comerciales. Para ello, hemos emitido una RFP para
seleccionar un proveedor de software especializado en comercio
electrónico.
Entre las necesidades identificadas "[Nombre_Tienda]" se encuentran:
1. Automatización del inventario: La tienda necesita un sistema de
gestión de inventario que actualice automáticamente las
existencias y la disponibilidad de productos en tiempo real. Esto
debe incluir notificaciones automáticas de stock bajo y
reabastecimiento de productos.
2. Procesamiento de pedidos: buscamos una solución que permita
el procesamiento automatizado de pedidos, incluyendo la
generación de facturas y confirmaciones de envío, así como la
integración con servicios de envío para generar etiquetas y
rastrear los envíos.
3. Informes y análisis: necesitamos una plataforma que genere
informes y análisis detallados sobre las ventas, el rendimiento del
60
inventario y otras métricas clave del negocio. Estos informes
deben ser personalizables y actualizarse automáticamente.
4. Integraciones: debemos integrar la nueva solución con su
plataforma de comercio electrónico existente, así como con otros
sistemas internos, contabilidad y CRM.
Como proveedores vamos a responder a esto:
Después de revisar detenidamente sus necesidades, me complace
presentar nuestra propuesta. Nuestra solución se centra en abordar los
desafíos clave que ustedes han identificado:
1. Automatización del inventario: Proponemos implementar un
sistema de gestión de inventario que actualice en tiempo real las
existencias y la disponibilidad de productos. Nuestra solución
enviará notificaciones automáticas de stock bajo y ofrecerá
funcionalidades avanzadas de reabastecimiento, asegurando que
siempre tengan control sobre su inventario.
2. Procesamiento de pedidos: Implementaremos un proceso
automatizado de procesamiento de pedidos que incluye la
generación automática de facturas y confirmaciones de envío.
Además, integraremos su plataforma de comercio electrónico con
servicios de envío confiables para generar etiquetas y realizar un
seguimiento en tiempo real de los envíos.
3. Informes y análisis: Nuestra solución incluirá un potente módulo de
generación de informes y análisis. Podrán acceder a informes
personalizables sobre ventas, rendimiento de inventario y otras
métricas clave del negocio. Estos informes se actualizarán
automáticamente, brindándoles información relevante y oportuna
para la toma de decisiones estratégicas.
4. Integraciones: Nos aseguraremos de que nuestra solución se integre
sin problemas con su plataforma de comercio electrónico existente,
así como con otros sistemas internos, como contabilidad y CRM.
Esto permitirá una transferencia de datos fluida y una experiencia
coherente en toda su organización.
61
Como podéis observar ya tenéis claro como deberíamos ambas partes
comportarnos en esta sección.
Actual entorno técnico
Se refiere al contexto y la infraestructura tecnológica existente en la
organización solicitante antes de la implementación de la nueva aplicación.
En una RFP, es importante describir el actual entorno técnico para que los
proveedores de software comprendamos los sistemas, las tecnologías y los
recursos con los que la nueva aplicación debe ser compatible y funcionar de
manera integrada. Esto nos permite evaluar cómo su solución propuesta se
alinea con el entorno existente y cumple con los requisitos técnicos y de
interoperabilidad.
Algunos aspectos que se pueden incluir en la descripción del actual entorno
técnico son:
1. Infraestructura de hardware: Esto implica describir los servidores,
estaciones de trabajo, dispositivos de red y otros componentes de
hardware utilizados en la organización, junto con sus capacidades y
especificaciones técnicas.
2. Infraestructura de software: Se debe mencionar el sistema operativo y
las aplicaciones de software utilizadas actualmente en la organización,
indicando las versiones y las configuraciones específicas.
3. Bases de datos y almacenamiento de datos: Se deben describir las bases
de datos utilizadas, como los sistemas de gestión de bases de datos
(SGBD) y los sistemas de almacenamiento de datos. También se
pueden mencionar las políticas de respaldo y recuperación de datos.
4. Integraciones existentes: Si la organización ya utiliza sistemas o
aplicaciones específicas que deben integrarse con la nueva aplicación,
es importante mencionar estas integraciones y las interfaces técnicas
utilizadas.
5. Requisitos de seguridad y cumplimiento normativo: Se deben
mencionar los protocolos y las políticas de seguridad implementadas
en la organización, así como los requisitos de cumplimiento normativo
que la nueva aplicación debe cumplir.
62
Por ejemplo, que podría pedirnos un cliente:
Somos [Nombre_Tienda], una tienda en línea líder en la venta de
productos electrónicos. Hemos experimentado un crecimiento
significativo en los últimos años y hemos realizado esfuerzos para
digitalizar nuestra operación. Sin embargo, durante los eventos de
Black Friday y otros períodos de alta demanda, nos hemos enfrentado
a desafíos significativos en nuestra capacidad para brindar un servicio
óptimo a nuestros clientes.
Para abordar estos desafíos y garantizar una experiencia de compra
excepcional durante los picos de demanda, hemos decidido emitir una
RFP para seleccionar un proveedor de software especializado.
Buscamos una solución que nos permita superar las limitaciones
actuales y mejorar nuestra capacidad para atender a un alto volumen
de clientes de manera eficiente y sin interrupciones.
Algunas de nuestras necesidades clave que esperamos abordar a través
de esta RFP son las siguientes:
1. Escalabilidad y rendimiento: Necesitamos una solución que nos
permita escalar rápidamente nuestros recursos de infraestructura
y garantizar un rendimiento óptimo del sitio web durante
períodos de alta demanda. Queremos evitar caídas del sitio,
tiempos de carga lentos y errores en el proceso de compra.
2. Administración de inventario: Buscamos una solución que nos
ayude a gestionar nuestro inventario de manera más eficiente
durante los eventos de Black Friday y otras promociones.
Necesitamos una visibilidad en tiempo real de las existencias,
una gestión automatizada del inventario y alertas para
reabastecimiento de productos.
3. Procesamiento de pedidos y pagos: Queremos mejorar la
velocidad y la precisión del procesamiento de pedidos y pagos
durante los períodos de alta demanda. Necesitamos una solución
que nos permita manejar transacciones simultáneas de manera
segura y sin interrupciones, minimizando los errores y
63
garantizando una experiencia de compra fluida para nuestros
clientes.
4. Atención al cliente: Buscamos una solución que mejore nuestra
capacidad para brindar un servicio al cliente excepcional durante
los eventos de alta demanda. Esto puede incluir opciones de chat
en vivo, gestión de consultas y seguimiento eficiente de los
problemas planteados por nuestros clientes.
Como proveedores vamos a responder a esto:
Nuestra propuesta se basa en el uso de Kubernetes para administrar y escalar
su infraestructura de manera flexible y dinámica. A continuación, detallamos
cómo abordaremos sus necesidades:
1. Escalabilidad y rendimiento: Implementaremos una arquitectura
basada en Kubernetes que nos permitirá escalar rápidamente los
recursos de infraestructura según la demanda. Utilizaremos
autoscaling y orquestación de contenedores para garantizar un
rendimiento óptimo del sitio web incluso en momentos de alta
demanda. Además, aprovecharemos las capacidades de balanceo de
carga de Kubernetes para distribuir eficientemente el tráfico entrante y
garantizar una experiencia de usuario fluida.
2. Administración de inventario: Desarrollaremos una solución
personalizada que integre su sistema de gestión de inventario actual
con Kubernetes. Esto permitirá una actualización en tiempo real de las
existencias y una gestión automatizada del inventario en consonancia
con los picos de demanda.
3. Procesamiento de pedidos y pagos: Implementaremos microservicios
en Kubernetes para gestionar el procesamiento de pedidos y pagos de
manera eficiente y segura. Utilizaremos contenedores aislados para
cada paso del proceso, lo que permitirá una mayor escalabilidad y
confiabilidad. Además, aprovecharemos las capacidades de gestión de
colas y balanceo de carga de Kubernetes para garantizar una
distribución equitativa y rápida del flujo de trabajo de los pedidos y
pagos.
64
4. Atención al cliente: Desarrollaremos un sistema de atención al cliente
basado en Kubernetes que incluirá opciones de chat en vivo y
herramientas de seguimiento de consultas. Esto permitirá una
comunicación fluida y una resolución eficiente de problemas durante
los momentos de alta demanda. Además, utilizaremos la
monitorización en tiempo real de Kubernetes para detectar y
responder rápidamente a cualquier problema que pueda surgir.
3.2.4.3 Tablas de resúmenes
Veamos los elementos comunes de una sección técnica. Cuando
respondemos a la RFP los clientes suelen quedarse en la parte de formatos de
ficheros, integraciones con terceros, Stack tecnológico de su organización,
etc. Lo que deberían incluir y casi nunca lo incluyen nos servirá como guía
para poder responder como proveedor y a los clientes esto os servirá de guía
para saber cómo afrontar esta sección.
Actual entorno empresarial (funcional)
Se refiere al contexto y los elementos existentes en la organización
solicitante antes de la implementación de la nueva aplicación. Es importante
describir el actual entorno empresarial para que los proveedores de software
comprendamos los sistemas, las tecnologías y los procesos que ya están en
uso. Esto permite evaluar cómo la solución propuesta se integrará con el
entorno existente y cumplirá con los requisitos y necesidades específicas de
la organización.
3.2.5 Entregables
La sección de entregables de tu propuesta responderá a la pregunta del
cliente: "¿Qué voy a obtener?". Esta sección y la sección de precios son a
menudo donde el cliente potencial presta más atención. El cliente quiere
asegurarse de que al final del día se entregará el producto esperado al precio
acordado.
Tu lista final de entregables debe ser detallada, organizada e incluir
referencias a los servicios aplicables descritos.
Para crear tu lista de entregables, debes examinar cada en la respuestas
administrativas y técnica para ver si puedes responderte a estas preguntas:
65
"¿Qué elementos tangibles voy a entregar al cliente durante esta fase del
proyecto?".
En una aplicación de software, algunos ejemplos de elementos tangibles que
podrías entregar como parte de los entregables podrían incluir:
• Documentación técnica: Manuales de usuario, guías de instalación,
documentación de API, descripciones de arquitectura, etc.
• Código fuente: Los archivos de código que conforman la aplicación,
incluyendo scripts, clases, archivos de configuración, etc.
• Interfaces de usuario: Diseños de pantalla, maquetas interactivas,
elementos gráficos, iconos, etc.
• Base de datos: Esquema de base de datos, scripts de creación y
población de la base de datos, datos de prueba, etc.
• Informes y análisis: Informes generados por la aplicación, tablas y
gráficos de análisis, datos procesados, etc.
• Integraciones: Conexiones y adaptadores para integrar la aplicación
con otros sistemas o servicios externos.
• Herramientas y utilidades: Scripts, herramientas de migración de
datos, utilidades de administración del sistema, etc.
• Pruebas y validación: Resultados de pruebas unitarias, pruebas de
integración, pruebas de aceptación, informes de errores corregidos,
etc.
• Capacitación y material educativo: Materiales de capacitación,
tutoriales, videos explicativos, presentaciones, etc.
• Soporte técnico: Acuerdos de nivel de servicio, contratos de soporte,
canales de comunicación para solicitar asistencia, etc.
Además de los elementos mencionados anteriormente, si has realizado
análisis UX/UI y temas de infraestructura en el desarrollo de la aplicación de
software, puedes incluir los siguientes elementos tangibles en tus
entregables:
• Diseño de experiencia de usuario (UX): Wireframes, mapas de
navegación, prototipos interactivos, flujos de usuario, etc. Estos
elementos representan la estructura y el flujo de la aplicación,
ayudando a definir cómo los usuarios interactuarán con ella.
66
• Diseño de interfaz de usuario (UI): Diseños visuales de la interfaz,
paleta de colores, tipografía, estilos y componentes visuales. Estos
elementos dan vida a la apariencia y estilo visual de la aplicación,
creando una experiencia atractiva y coherente para los usuarios.
• Arquitectura de infraestructura: Diagramas de arquitectura de la
infraestructura tecnológica necesaria para la aplicación, incluyendo
servidores, redes, sistemas de almacenamiento, balanceadores de
carga, bases de datos, servicios en la nube, entre otros. Estos elementos
describen cómo se estructura y organiza la infraestructura para
soportar el funcionamiento de la aplicación.
• Configuraciones de infraestructura: Documentación y archivos de
configuración necesarios para implementar y desplegar la aplicación
en la infraestructura, incluyendo scripts de implementación, archivos
de configuración del servidor, políticas de seguridad, etc.
• Optimización y rendimiento: Informes y resultados de pruebas de
rendimiento, optimizaciones realizadas en la aplicación para mejorar
la velocidad de respuesta, escalabilidad y eficiencia en el consumo de
recursos.
• Seguridad y cumplimiento normativo: Planes y documentación
relacionados con la seguridad de la aplicación, auditorías de seguridad
realizadas, certificaciones de cumplimiento normativo, como GDPR o
HIPAA, y cualquier otro aspecto relacionado con la protección de
datos y la seguridad de la aplicación.
Como apreciación personal y para enlazar con los precios, nunca asocies
entregables con hitos de facturación.
3.2.6 El Precio
Las RFP tienen dos hitos importantes:
• Cumplir con los requisitos que nos pide el cliente.
• Que nuestro precio entre en el presupuesto del cliente.
67
Uno de ellos podemos hacerlo sin problemas y el otro es “nuestro” precio, lo
que valen nuestros servicios, como arquitecto/a de soluciones, aquí debemos
dar el precio que nuestra empresa ofrece a los clientes por los servicios que
vamos a prestar.
Otro tema que no nos debería concernir y el cual genera fricciones en los
equipos, es el ajuste por qué la persona que gestiona la cuenta intuye (por que
sabe el presupuesto del cliente) o por que cree que estamos fuera con X precio.
En ambas opciones, la respuesta de arquitectura debe ser bajar o eliminar
elementos que puedan bajar, pero sin comprometer la estructura de la
aplicación tanto técnica como administrativa.
Lo que es importante que sepas también, es que esta tendencia a bajar precios
puede jugar en tu contra. Muchos clientes no se fían de los outlier por exceso o
defecto. Mucho cuidado con esto.
Personalmente, me gusta que el precio se presente con un formato consistente y preciso,
ya que esto me brinda una mayor claridad y transparencia en cuanto a los costos
asociados con el proyecto. Al recibir una propuesta con un formato uniforme, puedo
comparar de manera más efectiva las diferentes opciones disponibles y entender cómo se
distribuyen los costos en cada componente o actividad del proyecto.
Además, al requerir un formato preciso, puedo asegurarme de que el precio
proporcionado sea detallado y específico. Esto me permite comprender exactamente qué
está incluido en el costo y cómo se ha calculado, evitando ambigüedades o estimaciones
aproximadas. La precisión en la presentación del precio me brinda confianza al saber que
el proveedor ha realizado un análisis minucioso y ha considerado todos los elementos
necesarios para ofrecer un presupuesto preciso.
Como cliente esto te debería interesar mucho; un formato consistente y preciso en la
presentación del precio, permite evaluar y comparar las propuestas de manera eficiente,
entender la distribución de costos y tener una imagen clara de los gastos totales. Te
ayudará a tomar decisiones informadas y a garantizar que el presupuesto sea adecuado y
acorde con tus necesidades y expectativas.
3.2.6.1 Anatomía de los precios
Aquí lo primero es deciros que seguramente vuestra organización disponga
de una plantilla de EXCEL, MS Project, herramienta interna, etc. que será lo
que tengas que usar para la estimación del precio.
68
Como arquitecto/a de soluciones tendrás tu método para asignar un peso a
cada tipo de requerimiento. En esto no os puedo ayudar mucho por qué la
experiencia que tengáis será determinante y sobre todo porque sabéis como
y cuanto tardan vuestros recursos asignables.
Tienes que discernir entre dos tipos de información que se pone en
conocimiento o pide el cliente:
• Un orden de magnitud, que es una estimación con una horquilla
máxima y mínima, es una estimación rápida que nos permitirá saber si
el cliente esta dispuesto a continuar con la RFP y a veces nos lo piden
en la primera semana. Es una forma de no hacer perder tiempo a los
proveedores. Aunque esto debería ser siempre una RFP, pero en la
práctica no suele ser así y nos toca trabajar con la RFP y este tipo de
reunión con precio preliminar. En otras ocasiones los proveedores,
aunque lo pidan y luego quieran la RFP ya saben que no te cogerán…
esto ya entra en la ética de cada empresa.
• Un precio final cerrado, el cliente quieren el precio final de todo el
proyecto y bien detallado.
• Cuando estamos en un Time & Materials, si eres el cliente yo me
cuidaría mucho de al menos tener bien claro que vamos a entregar y
cuando, aunque luego existan alcances, pero por lo menos tengas bien
claro que es lo mínimo que necesitas de esas personas y tiempo para
hacer una estimación inicial. Muchas veces veo que es un body-
shopping que afecta siempre al proveedor perdiendo talento por el
desorden existente en el cliente y el abandono de la consultora. Como
proveedor existes un plan inicial y un pequeño estudio del proyecto
darás a entender al cliente y tus empleados que no eres un body-
shopping, esto además incide en que tus clientes no deberían verse
afectados tanto con la rotación de personal de estas empresas de
servicios.
Por tanto, voy a centrarme más en otros aspectos más cuantificables sin
entrar en juego en los que tengas en tu organización, pero habitualmente
tendrás que estimar a:
69
Nivel técnico
• Hardware, sí, lo lees bien, el hardware existe o es que pensáis que todo
va en el cloud. Por ejemplo, tu aplicación necesita unas ¿HoloLens de
Microsoft?, ¿necesitas tabletas rugerizadas con impresora portátil?, etc.
Ves como puedes asignar hardware en una RFP en la era del Cloud.
• Software de sistema y aplicación. Licencias de terceros para por
ejemplo usar una VPN o controles que aclararen el desarrollo de una
aplicación Web o certificados para sitios web o licencias de entornos
de desarrollo o licencias de sistemas operativos o licencias de
herramientas de monitorización.
• Consumibles, pues sí, imagina que tienes que hacer una impresión de
etiquetas térmicas en las Tablet, pues el papel el los consumibles. O
haces grabación de tarjetas de RFID, aquí tienes otro consumible.
• Y por supuesto estimaciones del consumo de recursos Cloud.
Nivel administrativo
• Desde la administración del proyecto hasta los servicios gestionados
(incluyendo personal on/off-site).
• Integraciones entre hardware y software propietario. En este caso por
ejemplo coordinar equipos de desarrollo y equipo del propietario de
ese hardware tan especializado, desde como instalarlo hasta como
programarlo.
• Desarrollo de la aplicación a medida.
• Instalaciones.
• Test de aceptación.
• Mantenimiento.
• Formación y transferencias de conocimiento.
• Documentación.
• Asignación de personal.
• Gestión del cambio y mejoras.
• Gestión de viajes y dietas.
• Etc.
70
¿Desarrollo de software a medida?
Por ejemplo, estas son algunas de las acciones que debes tener en cuenta
cuando desarrollas software a medida:
1. Planificación del proyecto: Definir los objetivos del proyecto,
establecer los plazos, identificar los entregables y determinar los
recursos necesarios para llevar a cabo el desarrollo.
2. Creación del equipo de proyecto: Asignar roles y responsabilidades
dentro del equipo, incluyendo el gerente de proyecto, analistas,
diseñadores, desarrolladores y especialistas en calidad.
3. Establecimiento de un sistema de comunicación: Establecer canales de
comunicación efectivos para garantizar una comunicación clara y
constante entre los miembros del equipo, los clientes y otras partes
interesadas.
4. Seguimiento y control del proyecto: Realizar un seguimiento regular
del progreso del proyecto, supervisar el cumplimiento de los plazos y
los hitos clave, y tomar medidas correctivas cuando sea necesario.
5. Gestión del alcance: Definir y controlar los límites y las
funcionalidades del proyecto para evitar cambios o desviaciones no
planificadas.
6. Gestión de riesgos: Identificar los riesgos potenciales y desarrollar
planes de mitigación para minimizar su impacto en el proyecto.
Realizar un monitoreo continuo de los riesgos a lo largo del desarrollo.
7. Gestión de cambios: Evaluar y gestionar los cambios solicitados por el
cliente o identificados durante el desarrollo, considerando su impacto
en los plazos, el presupuesto y los recursos.
8. Establecimiento de métricas y métricas de rendimiento: Definir
métricas y criterios para evaluar el rendimiento del proyecto, como la
calidad del software, el cumplimiento de los plazos y la satisfacción del
cliente.
9. Gestión de presupuesto: Establecer un presupuesto detallado y realizar
un seguimiento de los gastos a lo largo del proyecto. Controlar los
costos y hacer ajustes si es necesario.
10. Reportes y documentación: Generar informes periódicos para el cliente
y otras partes interesadas, brindando actualizaciones sobre el progreso,
71
el rendimiento y los hitos alcanzados. Documentar los procesos,
decisiones y cambios importantes durante el desarrollo.
11. Gestión de la calidad: Establecer estándares de calidad y realizar
pruebas y revisiones para garantizar que el software desarrollado
cumpla con los requisitos y expectativas establecidos.
12. Implementación y puesta en marcha: Coordinar la implementación del
software desarrollado, realizar pruebas de aceptación y asegurarse de
que el producto final esté listo para su uso.
Tal y como puede observar, el trabajo administrativo es mucho y diverso,
que cambiará según sea el tipo de tu aplicación.
¿Desarrollo de extensión sobre software de producto?
Por ejemplo, estas son algunas de las acciones que debes tener en cuenta
cuando desarrollas extensiones para un producto:
1. Análisis de requisitos: Comprender completamente los requisitos y
necesidades del cliente o usuarios finales para la extensión. Identificar
las funcionalidades y características específicas que se deben agregar al
producto base.
2. Evaluación de la arquitectura del producto base: Analizar la
arquitectura y estructura del producto base para determinar cómo se
pueden integrar y extender las nuevas funcionalidades de manera
eficiente y coherente.
3. Diseño y planificación: Crear un diseño detallado de la extensión,
considerando aspectos como la interfaz de usuario, la integración con
el producto base y la compatibilidad con las versiones existentes.
Planificar el cronograma de desarrollo y establecer hitos clave.
4. Desarrollo de la extensión: Implementar las funcionalidades de la
extensión de acuerdo con el diseño establecido. Realizar pruebas
unitarias y de integración para garantizar su correcto funcionamiento y
su compatibilidad con el producto base.
5. Documentación: Crear documentación clara y completa que explique
cómo instalar, configurar y utilizar la extensión. Proporcionar ejemplos
y casos de uso para facilitar su comprensión.
72
6. Pruebas y control de calidad: Realizar pruebas exhaustivas de la
extensión para identificar y corregir posibles errores o problemas de
rendimiento. Asegurar que la extensión cumpla con los estándares de
calidad y satisfaga los requisitos definidos.
7. Gestión de la versión: Establecer un sistema de control de versiones
para administrar los cambios y actualizaciones de la extensión. Seguir
buenas prácticas de gestión de versiones para garantizar una evolución
ordenada y controlada de la extensión.
8. Implementación y soporte: Preparar los recursos necesarios y los pasos
requeridos para instalar y desplegar la extensión en el entorno de
producción del cliente. Brindar soporte y asistencia técnica para
resolver problemas o consultas relacionadas con la extensión.
9. Gestión del ciclo de vida de la extensión: Establecer una estrategia para
mantener y actualizar la extensión a lo largo del tiempo, incluyendo la
resolución de problemas, la incorporación de nuevas funcionalidades y
la compatibilidad con futuras versiones del producto base.
10. Comunicación con el cliente: Mantener una comunicación clara y
constante con el cliente o los usuarios finales, informando sobre el
progreso del desarrollo, respondiendo a consultas y recopilando
retroalimentación para mejorar la extensión.
Seguro que se te ocurren más, pero las anteriores tareas conllevan un gran
trabajo administrativo.
¿Servicios gestionados?
Cuando trabajas con servicios gestionados, hay varias tareas administrativas
que debes tener en cuenta. Estas tareas se centran en la gestión y supervisión
de los servicios gestionados contratados. Algunas de las tareas
administrativas comunes incluyen:
1. Selección de proveedores: Identificar y seleccionar proveedores de
servicios gestionados confiables y con experiencia en el área específica
requerida. Esto implica evaluar las capacidades, la reputación, la
calidad del servicio y los costos asociados con cada proveedor.
2. Contratación y negociación: Establecer acuerdos contractuales y
negociar los términos y condiciones con el proveedor de servicios
73
gestionados. Esto incluye definir los niveles de servicio, los plazos, los
precios, las responsabilidades y cualquier otra cláusula relevante para
la prestación del servicio.
3. Gestión de contratos y pagos: Administrar los contratos con los
proveedores de servicios gestionados, incluyendo la renovación, la
modificación y la terminación de contratos. Además, realizar los pagos
correspondientes según los términos acordados.
4. Supervisión del rendimiento: Realizar un seguimiento continuo del
rendimiento del proveedor de servicios gestionados para garantizar
que cumpla con los niveles de servicio acordados. Esto implica
establecer métricas de rendimiento, realizar evaluaciones periódicas y
mantener una comunicación constante con el proveedor.
5. Resolución de problemas y escalación: Gestionar y resolver cualquier
problema o incidencia relacionada con los servicios gestionados. Esto
puede implicar la coordinación con el proveedor para solucionar
problemas técnicos, la gestión de cambios o la escalada de problemas
cuando sea necesario.
6. Gestión de la seguridad: Supervisar y garantizar la seguridad de los
servicios gestionados, incluyendo la protección de datos, la prevención
de brechas de seguridad y el cumplimiento de regulaciones y
estándares de seguridad aplicables.
7. Gestión de cambios: Administrar los cambios en los servicios
gestionados, incluyendo cambios en los requisitos, actualizaciones
tecnológicas, implementación de nuevas funcionalidades o ajustes en
la configuración. Esto implica coordinar con el proveedor y garantizar
una implementación adecuada y sin interrupciones del servicio.
8. Reportes y comunicación: Generar informes y comunicarse
regularmente con el proveedor de servicios gestionados para mantener
una visibilidad clara del rendimiento, los problemas y las
actualizaciones relacionadas con los servicios.
9. Evaluación y mejora continua: Evaluar de forma periódica la eficacia y
la calidad de los servicios gestionados. Identificar áreas de mejora y
colaborar con el proveedor para implementar acciones correctivas y
optimizar la prestación del servicio.
74
10. Gestión de la relación con el proveedor: Mantener una relación sólida y
colaborativa con el proveedor de servicios gestionados. Esto incluye la
comunicación regular, la resolución de conflictos y la identificación de
oportunidades para una mayor colaboración y beneficio mutuo.
¿Mantenimiento y soporte?
Al brindar mantenimiento y soporte para un producto o servicio, existen
varias tareas administrativas que debes considerar. Aquí hay algunas de ellas:
1. Establecer acuerdos de nivel de servicio (SLA, por sus siglas en inglés):
Definir los niveles de soporte y los tiempos de respuesta esperados
para diferentes tipos de solicitudes de soporte. Esto incluye acordar los
plazos de resolución para problemas críticos, importantes y menores.
2. Crear un sistema de seguimiento de incidencias: Implementar una
herramienta o sistema para registrar, asignar y dar seguimiento a las
incidencias y solicitudes de soporte de los usuarios. Esto permite un
seguimiento eficiente y una resolución oportuna de los problemas
reportados.
3. Asignación de recursos: Asignar personal adecuado y capacitado para
manejar las solicitudes de mantenimiento y soporte. Esto puede incluir
técnicos, especialistas, ingenieros o personal de atención al cliente,
dependiendo de los requerimientos y la complejidad del producto o
servicio.
4. Priorización y gestión de incidencias: Evaluar y clasificar las
incidencias según su nivel de gravedad y su impacto en el usuario.
Establecer una metodología para priorizar y manejar las incidencias de
manera efectiva, asegurándose de que los problemas críticos sean
atendidos de manera prioritaria.
5. Comunicación con los usuarios: Establecer canales de comunicación
claros y efectivos para recibir y responder a las solicitudes de soporte.
Proporcionar actualizaciones regulares sobre el estado de las
incidencias y garantizar una comunicación clara y transparente con los
usuarios.
6. Mantenimiento preventivo: Establecer un programa de mantenimiento
preventivo para evitar posibles problemas y optimizar el rendimiento
75
del producto o servicio. Esto puede incluir actualizaciones de software,
parches de seguridad, revisión de configuraciones, limpieza de datos,
entre otros.
7. Generación de informes de seguimiento: Crear informes periódicos
sobre el rendimiento del sistema, las incidencias resueltas, el tiempo
de respuesta promedio y otros indicadores clave. Estos informes
proporcionan una visión general del estado del soporte y permiten
identificar áreas de mejora.
8. Gestión de contratos de mantenimiento: Si existen contratos de
mantenimiento con los clientes, gestionar los términos, condiciones y
renovaciones de dichos contratos. Asegurarse de cumplir con los
compromisos acordados y revisar periódicamente los términos para
adaptarlos a las necesidades cambiantes del negocio.
9. Retroalimentación y mejora continua: Recopilar comentarios y
sugerencias de los usuarios y el equipo de soporte para mejorar
continuamente los procesos de mantenimiento y soporte. Establecer
mecanismos para recibir y evaluar la retroalimentación, y realizar
ajustes en consecuencia.
10. Gestión de conocimiento: Crear y mantener una base de
conocimientos con soluciones, procedimientos y recursos útiles para
resolver problemas comunes de manera eficiente. Promover la
documentación y el intercambio de conocimientos entre el equipo de
soporte para mejorar la capacidad de resolución de incidencias.
3.2.6.2 Tipos de costes
Debes prestar atención a los costes por su tipo, ya que esto deberá quedar
reflejado en la propuesta el precio, ciclo de vida, variaciones, etc. A
continuación, os pongo los más comunes:
Ciclo de vida
• Los gastos recurrentes y no recurrentes son dos categorías que se
utilizan para clasificar los diferentes tipos de gastos que una
organización o individuo puede tener. Aquí te explico cada uno de
ellos:
76
Gastos recurrentes: Los gastos recurrentes son aquellos que se
producen de manera regular y se repiten en períodos
predefinidos, generalmente de forma mensual, trimestral o
anual. Estos gastos son necesarios para el funcionamiento
continuo de una entidad y suelen ser parte de las operaciones
normales. Algunos ejemplos de gastos recurrentes incluyen:
▪ Gastos de alquiler o arrendamiento de instalaciones o
equipos.
▪ Pagos de nómina y salarios a los empleados.
▪ Gastos de servicios públicos, como electricidad, agua y
telefonía.
▪ Gastos de mantenimiento y reparación de equipos y
propiedades.
▪ Pagos de seguros, como seguros de salud o seguros de
propiedad.
▪ Costos de suministros y materiales necesarios para las
actividades diarias.
▪ Gastos de marketing y publicidad regulares.
▪ Pagos de intereses y cuotas de préstamos a largo plazo.
Los gastos recurrentes son necesarios para mantener las
operaciones en funcionamiento y, por lo general, se incluyen en
el presupuesto anual de una organización.
• Gastos no recurrentes: Los gastos no recurrentes, también conocidos
como gastos extraordinarios o gastos únicos, son aquellos que no se
repiten regularmente y suelen ser de naturaleza no planificada. Estos
gastos suelen surgir debido a circunstancias excepcionales o eventos
no habituales. Algunos ejemplos de gastos no recurrentes incluyen:
▪ Gastos de reubicación o traslado de oficinas.
▪ Costos de adquisición de nuevos equipos o tecnología.
▪ Gastos legales o de consultoría relacionados con un litigio
o proyecto específico.
▪ Gastos de formación o capacitación especializada para los
empleados.
77
▪ Gastos de marketing y promoción relacionados con un
evento o lanzamiento de producto específico.
▪ Costos de desarrollo de software personalizado o proyectos
especiales.
▪ Gastos de remodelación o renovación de instalaciones.
Los gastos no recurrentes no forman parte de los costos
operativos regulares de una organización y, por lo tanto, no se
incluyen en el presupuesto recurrente. Estos gastos suelen ser
planificados y presupuestados por separado, ya que no se
esperan de forma continua.
Variación del precio, descuentos, términos de pago, períodos de
garantía, mantenimiento, etc.
Son puntos que estas fuera como arquitecto/a de soluciones, pero otros no,
ya deberías saber por tu experiencia cuales te afectan al presupuesto y cuáles
no.
3.2.6.3 Precio fijo
El precio fijo es un alcance de trabajo establecido con un precio específico.
Le dices a los clientes exactamente lo que vas a hacer y cuánto les va a costar.
Mientras los clientes se mantengan dentro del alcance del proyecto, se les
cobra el precio que cotizaste. En mi experiencia, el precio fijo es la opción
más comúnmente utilizada en la industria.
Ventajas para ti: Sabes exactamente cuánto ganarás en el proyecto. Si el
trabajo te lleva menos tiempo del esperado, obtienes más ganancias.
Desventajas para ti: Como estás comprometido con un precio, si el trabajo
te lleva más tiempo del esperado, obtienes menos ganancias (incluso puedes
perder dinero).
Ventajas para los clientes: Los clientes saben exactamente cuánto tendrán
que pagar, siempre y cuando se mantengan dentro del alcance del proyecto.
Pueden asumir razonablemente que podrán cumplir con su presupuesto
asignado para el proyecto.
78
Desventajas para los clientes: Debido a la naturaleza complicada de los
precios fijos, es probable que tú debas inflar tu estimación para tener en
cuenta cualquier desafío imprevisto en el proyecto. Como resultado, los
clientes podrían terminar pagando mucho más por un proyecto que si se
hubiera fijado un precio en una estructura diferente. Además, si los clientes
se salen del alcance en un grado que requiera que les envíes órdenes de
cambio, pueden frustrarse y sentir que estás tratando de sacarles hasta el
último centavo.
Problemas a tener en cuenta: Con los precios fijos, debes definir
claramente el alcance del proyecto. Si no tienes cada detalle minuciosamente
definido (entregables, funcionalidad, rondas de diseño, rondas de cambios,
etc.) en tu propuesta, es muy probable que eventualmente te encuentres en
problemas con un proyecto de precio fijo.
Debes intentar ayudar a los clientes a adherirse al alcance definido del
proyecto. Desafortunadamente, sin importar lo que hagas para detallar
claramente el proyecto, existe la posibilidad de que los clientes te pidan
hacer algo que no se incluyó en el alcance. Mantenerlos dentro del alcance
puede ser una tarea desafiante de gestión de clientes.
Cuando usarlo: Las estructuras de precio fijo se utilizan mejor cuando los
clientes saben exactamente lo que quieren que produzcas y exactamente
cuánto están dispuestos a gastar.
3.2.6.4 Time & Materials (recursos dedicados)
Se asignan ciertos empleados a un cliente por un período determinado. Las
estructuras de recursos dedicados compran personas en lugar de horas. Por
lo general, se calcula en semanas hombre (man-day). Trabajas con los
clientes para determinar cuánto tiempo esperas que dure el proyecto y
dedicas empleados específicos a la tarea. Cuantas más semanas hombre
compren los clientes, menor será la tarifa que pagan.
Ventajas para ti: Puede brindarte flujo de efectivo y confianza para
expandir tu negocio.
79
Desventajas para ti: Al reducir tu tarifa, reduces tu margen de beneficio.
También es posible que debas dedicar algunos de tus mejores empleados a
un cliente, perdiendo así su participación en otros proyectos.
Ventajas para los clientes: Los clientes pagan menos dinero por más
trabajo y pueden construir una sólida relación de trabajo con los miembros
de tu equipo, ya que colaboran estrechamente en el proyecto.
Desventajas para los clientes: Durante el período establecido en el
acuerdo, es como si los clientes emplearan directamente a los miembros de
tu equipo. Tienen la responsabilidad de mantener ocupados a esos miembros
del equipo para obtener el máximo provecho de la relación.
Problemas a tener en cuenta: Asegúrate de incluir una cláusula legal en tu
acuerdo con los clientes para evitar que contraten a tus empleados. A
medida que construyen una sólida relación de trabajo con los miembros de
tu equipo, esto se convierte en un riesgo.
Cuando usarlo: Esta estructura funciona mejor para compromisos a largo
plazo donde el alcance y el conjunto de características del proyecto son
difíciles de determinar al principio.
3.3 EVALUACIÓN DE UNA RFP
Esta sección os voy a contar como debemos proceder para evaluar una RFP.
Y para ello que mejor que tener un flujo de trabajo que te ayude con el
proceso:
80
81
3.3.1 ¿Ofertar o no ofertar?
La decisión de gestión más importante que una empresa toma en relación
con cualquier proyecto dado es si presentarse a la licitación del contrato.
Una propuesta representa una inversión significativa de los recursos de la
empresa y solo debe emprenderse si existe una posibilidad razonable de
ganar el contrato. O puedes decidir aceptar una pérdida en el trabajo si
deseas establecer tu empresa con un cliente, especialmente si el prestigio del
cliente animará a otros clientes a contratar tus servicios.
Este paso consta de dos partes: un análisis de la solicitud de propuesta (RFP)
y un análisis económico para determinar si el retorno potencial supera el
costo de preparar la propuesta y completar el trabajo.
3.3.2 Desarrollo preliminar de un punto de venta único/diferenciador.
Se trata de la etapa de planificación y diseño de un punto de venta que tenga
características únicas o distintivas. Esto implica desarrollar conceptos, ideas
y propuestas para crear un punto de venta que se destaque de la
competencia y atraiga al cliente de manera efectiva.
3.3.3 Desarrollo del Diseño del Programa
El gestor de la propuesta coordina toda la información para desarrollar el
diseño final del programa. En este paso, nuestra empresa determinará
exactamente lo que haremos por el cliente, cómo lo haremos, cuánto tiempo
y dinero necesitará para finalizar el proyecto. Este paso incluye la
elaboración de estimaciones de tiempo y costes.
3.3.4 Desarrollo de la Portada y el Resumen Ejecutivo
Una vez finalizado el primer borrador de la propuesta, la lideres lo revisarán
y normalmente sugerirá cambios. Cuando los directivos aprueben el
contenido final, el equipo de la propuesta elaborará la portada.
La portada de la propuesta incluye la carta de presentación (o de
transmisión), el índice final, la lista de gráficos y tablas, y el resumen
ejecutivo. El resumen ejecutivo es una parte clave de la propuesta porque
describe brevemente las cuestiones principales y las acciones recomendadas
por su empresa. El resumen ejecutivo sirve como potente pieza de ventas y
marketing para su empresa.
82
3.3.5 ¿Cómo debo hacer las preguntas al cliente?
Los proveedores debemos tener el derecho a poder realizar preguntas y que
el cliente las responda. El cliente distribuirá las preguntas que lancemos a los
actores correspondientes
Las preguntas que solemos enviar al cliente suelen estar orientadas a
requerimientos funcionales, no funcionales y procedimientos.
El cliente debería redistribuir entre todos los proveedores tanto nuestras
preguntas y las correspondientes respuestas como las que lanzan otros
proveedores, es un ejercicio de transparencia, no una competición por ver
quien es más listo y lanza menos preguntas para dar a entender al cliente
que hemos entendido todo a la perfección. Por supuesto, el cliente debe
anonimizar de quien es cada pregunta.
Por ejemplo, esta sería la forma correcta de enviar las preguntas (ya sea en
un documento de Word o Excel o en un simple correo):
Nombre Ejemplo
Nombre del fichero fichero-version-1.0.0.pdf
Numero de la sección 3.1.1 Requerimiento funciona
Número del párrafo 4
Número de la página 36
Texto o fragmento
cuestionado
“…de 15.00h a 15.15h, se cambia el turno y se
debe cerrar la caja, la aplicación hace uso
intensivo y muchas veces se queda bloquead…”
Pregunta sobre el texto ¿De cuantos usuarios estamos hablando en ese
momento pico?, ¿se hace en todas las regiones
igual con el horario local a las 15.00h a 15.15h?,
¿podría darnos una tabla de dichos picos y
cuando sucede en cada región?
Como veis, estamos lanzado una pregunta facilitando al cliente como
localizar la información. No es habitual que en una RFP te envíen como
debes formular las preguntas. Con el modelo que os muestro es más que
suficiente.
Si estamos trabajando en el cliente en otros proyectos y tenemos algo de
contexto esto puede ser un problema, ya que la posible respuesta puede ser
83
“pregunta a tus compañeros”, esto es una desventaja muy grande y denota una
falta de empatía por parte del cliente ya que puedes tener o no contacto con
ese equipo. Mi recomendación es contacta con tus compañeros, obtén esa
información si es que disponen de ella, en caso contrario deja marcado en la
pregunta que ya has realizado un sondeo a tus compañeros y o bien carecen de
esa información o bien su respuesta, que adjuntarás a la pregunta, no es
concluyente y es necesario la respuesta del cliente.
A vuestra disposición pongo un listado con más de 2000 preguntas,
clasificadas para requerimientos no funcionales:
2000 preguntas para Requerimientos No Funcionales (NFR)
3.3.6 ¿Cómo debo hacer asunciones?
Realizar asunciones en respuesta a una RFP es una práctica común para
abordar posibles lagunas de información o ambigüedades en los requisitos
establecidos por el cliente. Aquí hay algunas pautas a seguir al hacer
asunciones en tu respuesta a una RFP:
84
1. Identifica las áreas ambiguas: Lee cuidadosamente la RFP y busca
secciones o requisitos que no estén claramente definidos o que dejen
margen para interpretación.
2. Documenta las asunciones: Crea una lista clara y concisa de las
asunciones que estás haciendo en tu respuesta. Enumera cada
asunción de manera separada y brinda una descripción detallada de lo
que estás asumiendo.
3. Sé realista y fundamentado: Asegúrate de que tus asunciones sean
razonables y realistas. Basa tus asunciones en tu experiencia y
conocimiento del dominio en el que estás trabajando.
4. Comunica las asunciones: Incluye las asunciones en tu propuesta,
preferiblemente en una sección separada. Explica por qué estás
haciendo cada asunción y cómo impacta en tu oferta y en la entrega
del proyecto.
5. Pide aclaraciones si es necesario: Si hay alguna ambigüedad o falta de
información en la RFP, considera comunicarte con el cliente para
solicitar aclaraciones antes de hacer tus asunciones. Esto te ayudará a
tener una comprensión más clara de los requisitos y a reducir el riesgo
de hacer suposiciones incorrectas.
6. Evalúa el impacto de las asunciones: Analiza cómo afectarán tus
asunciones a la oferta, al alcance del proyecto, al tiempo de entrega y al
costo. Considera los posibles riesgos asociados a tus asunciones y cómo
mitigarlos.
7. Documenta cambios en las asunciones: Si durante el proceso del
proyecto se descubre que una asunción era incorrecta o requiere
ajustes, comunica estos cambios al cliente y realiza las modificaciones
necesarias en la entrega del proyecto.
Hacer asunciones es una estrategia para abordar incertidumbres, pero
siempre es importante minimizarlas a través de una comunicación clara con
el cliente y una comprensión completa de los requisitos.
3.3.7 Una serie de cuestionarios que te ayudarán
Esto puede llegar a ser infinito, pero aquí tienes un cuestionario que puede
ayudarte a evaluar una RFP:
85
1. ¿Los requisitos son claros y están bien definidos?
2. ¿Se proporciona información suficiente sobre el alcance del proyecto?
3. ¿Los objetivos del proyecto están claramente establecidos?
4. ¿Se especifica el cronograma y los plazos esperados?
5. ¿Se detallan los criterios de evaluación y los puntos de referencia para
medir el éxito del proyecto?
6. ¿Se proporciona información sobre los recursos disponibles, como
personal, presupuesto y herramientas?
7. ¿Se identifican los riesgos y desafíos potenciales del proyecto?
8. ¿Se establecen claramente las expectativas de colaboración y
comunicación entre el proveedor y el cliente?
9. ¿La RFP incluye detalles sobre los entregables esperados y las
responsabilidades de ambas partes?
10. ¿Se menciona la experiencia requerida del proveedor y los criterios de
selección?
11. ¿Se proporciona información sobre el proceso de evaluación y
selección de proveedores?
12. ¿Se incluyen los términos y condiciones generales para el contrato?
13. ¿La RFP proporciona información sobre el presupuesto disponible para
el proyecto?
14. ¿Se especifican los requisitos técnicos y tecnológicos necesarios para el
proyecto?
15. ¿Se incluye un resumen ejecutivo que brinde una visión general clara
del proyecto?
16. ¿La RFP establece claramente los roles y responsabilidades de las
partes involucradas?
17. ¿Se mencionan las expectativas de calidad y rendimiento del proyecto?
18. ¿La RFP incluye información sobre la propiedad intelectual y los
derechos de autor relacionados con los entregables del proyecto?
19. ¿Se mencionan los requisitos de seguridad y privacidad de los datos en
la RFP?
20. ¿La RFP proporciona información sobre el proceso de presentación de
propuestas y los plazos de entrega?
21. ¿Se incluyen ejemplos o referencias de proyectos similares realizados
anteriormente?
86
22. ¿La RFP establece claramente los criterios de aceptación y las pruebas
de validación necesarias?
23. ¿Se mencionan los requisitos de soporte técnico y mantenimiento
post-implementación?
24. ¿La RFP incluye información sobre los estándares y regulaciones que
deben cumplirse?
25. ¿Se proporciona un plan de comunicación para mantener informadas a
todas las partes interesadas durante el proyecto?
26. ¿La RFP menciona los procedimientos de resolución de conflictos o
disputas contractuales?
27. ¿Se menciona la disponibilidad de recursos internos por parte del
cliente para colaborar en el proyecto?
28. ¿La RFP establece expectativas claras sobre los informes y
actualizaciones del progreso del proyecto?
29. ¿Se proporciona información sobre los requisitos de formación y
capacitación para el personal del cliente?
30. ¿La RFP incluye detalles sobre la transferencia de conocimiento y la
documentación final del proyecto?
31. ¿Se mencionan los requisitos de integración con sistemas existentes o
de terceros?
32. ¿La RFP establece las expectativas de disponibilidad y tiempos de
respuesta para el soporte técnico?
33. ¿Se incluye un apartado para preguntas y respuestas aclaratorias por
parte de los proveedores interesados?
Estas preguntas pueden variar dependiendo del tipo de proyecto y la
industria. Adaptar el cuestionario según tus necesidades específicas te
ayudará a evaluar de manera más precisa la RFP y determinar si es adecuada
para tu organización.
3.3.8 Tipos de estimación y herramientas que ayudan
Existen diferentes tipos de estimación que se pueden utilizar para evaluar
RFPs. Aquí hay algunos de los tipos comunes de estimación y herramientas
que pueden ayudar en este proceso:
87
• Estimación de esfuerzo: Esta es una estimación basada en la cantidad
de tiempo y recursos humanos requeridos para completar el proyecto.
Las herramientas que pueden ayudar en esta estimación incluyen hojas
de cálculo, software de gestión de proyectos y métodos de
descomposición de tareas.
• Estimación de costo: Esta estimación se basa en los recursos
financieros necesarios para llevar a cabo el proyecto. Se pueden utilizar
herramientas como hojas de cálculo, software de gestión de
presupuestos y sistemas de contabilidad para calcular y evaluar los
costos asociados.
• Estimación de duración: Esta estimación se enfoca en el tiempo
necesario para completar el proyecto. Las herramientas como
diagramas de Gantt, software de gestión de proyectos y técnicas de
programación ayudan a visualizar y evaluar la duración de las tareas y
el cronograma general del proyecto.
• Estimación de riesgos: Esta estimación se centra en identificar y
evaluar los posibles riesgos asociados con el proyecto. Se pueden
utilizar herramientas como matrices de riesgos, análisis FODA
(fortalezas, oportunidades, debilidades y amenazas) y técnicas de
gestión de riesgos para evaluar y priorizar los riesgos potenciales.
• Estimación de calidad: Esta estimación se refiere a la calidad del
trabajo entregado al final del proyecto. Las herramientas que pueden
ayudar en esta estimación incluyen estándares de calidad, procesos de
control de calidad y métricas de rendimiento.
Existen diversas herramientas en el mercado que pueden ayudarte a realizar
estimaciones para evaluar RFPs. Aquí tienes algunas opciones populares:
• Microsoft Project: Es una herramienta de gestión de proyectos que
permite crear y gestionar cronogramas, asignar recursos, realizar
seguimiento de tareas y estimar la duración y el esfuerzo requeridos
para completar un proyecto.
• Primavera P6: Es una herramienta de gestión de proyectos
ampliamente utilizada en la industria de la construcción y la
ingeniería. Permite realizar estimaciones de tiempo, costos y recursos,
88
y ofrece funcionalidades avanzadas para la programación y el
seguimiento de proyectos complejos.
• Smartsheet: Es una herramienta de colaboración y gestión de
proyectos en línea que incluye funciones de estimación y seguimiento
de proyectos. Permite crear hojas de cálculo interactivas, asignar
tareas, establecer hitos y colaborar en tiempo real con otros miembros
del equipo.
• Jira: Es una herramienta de gestión de proyectos y seguimiento de
problemas que se utiliza comúnmente en el desarrollo de software ágil.
Proporciona capacidades para estimar el esfuerzo, asignar tareas,
realizar seguimiento del progreso y gestionar las dependencias entre
las diferentes partes del proyecto.
• Excel: Aunque es una herramienta más básica, Excel puede ser
utilizado de manera efectiva para realizar estimaciones en hojas de
cálculo personalizadas. Puedes utilizar fórmulas y funciones para
calcular costos, esfuerzo y tiempo, y crear modelos de estimación
adaptados a tus necesidades específicas.
3.3.9 ¿Cómo debería ser el equipo?
A veces, solo necesitas asignar a una persona para preparar y escribir una
propuesta. Pero si el trabajo es grande o técnicamente complicado, es posible
que necesites juntar a un equipo, por ejemplo:
89
Desde mi experiencia existen cuatro elementos claves para tener un buen
equipo de propuestas:
• Gerentes (mánager) o coordinadores: estas personas se encargan del
trabajo diario del equipo que escribe la propuesta. Son necesarios para
coordinar cosas como la investigación de antecedentes y de mercado,
recopilación de información sobre la competencia, desarrollo del plan
del programa y presupuesto, y encontrar a los expertos dentro de la
empresa y a los miembros del equipo que trabajarán en el proyecto. Y
mantener la relación con el cliente, debe ser su contacto principal.
• Un líder que supervise el proceso. Puede ser un arquitecto/a de
soluciones, de data, de infraestructura, IA, etc. dependerá del tipo de
proyecto que tengas.
• Miembros del equipo con las habilidades y conocimientos específicos.
Provienen de todas las áreas de la empresa o consultores externos o
90
empresas que tienen habilidades o conocimientos especializados en
relación con los requisitos de la propuesta.
• Un lugar dedicado para el equipo. Puede ser tan sencillo como un
equipo de Microsoft Teams o si trabajas on-site, una sección de la
empresa reservada para el trabajo de la propuesta. Un espacio separado
permite que el equipo trabaje más cerca y mantengan los materiales en
un solo lugar.
3.3.9.1 ¿Qué espero de quien lidera la propuesta?
Debe ser un líder consolidado y la persona que dirige al equipo. Para mi debe
ser una persona que sea experta en el tema de la propuesta, si no puede ser,
debería tener suficiente conocimiento para ayudar a dirigir y guiar al equipo.
Debe ser capaz de motivar a los miembros del equipo y coordinar y organizar
el trabajo. Es esencial que los lideres debe ser el apoyo necesario para
terminar el trabajo para cada área coordinada.
Las tareas principales:
• Principal contacto con el mánager de la propuesta y poder tener un
contacto indirecto o directo con el cliente.
• Reclutar, organizar y dirigir al equipo de planificación de propuestas.
Esto incluye elegir a coordinadores que dirijan las actividades de los
diferentes grupos involucrados.
• Obtener los servicios de consultores y otras empresas (si es necesario)
y definir sus responsabilidades y funciones.
• Ayudar al equipo a analizar la solicitud de propuesta (RFP) para
entender las necesidades del cliente.
• Establecer el cronograma de planificación de propuestas y asignar
tareas a los miembros individuales o grupos de trabajo del equipo.
• Asegurarse de que el equipo se mantenga en el rumbo y siga las pautas
y metas establecidas.
• Revisar el material enviado por los miembros del equipo.
• Mantener una comunicación constante con el mánager de la propuesta
y los resultados del equipo y solicitar ayuda adicional cuando sea
necesario.
• Presentar la propuesta preliminar a los superiores.
91
• Construir la propuesta final y ser el enlace con los superiores.
• Supervisar la producción y entrega de la propuesta al mánager.
3.3.9.2 ¿Qué espero de los mánager o gerentes de Áreas Funcionales?
Los coordinadores de áreas funcionales, seleccionados por el líder de
propuestas, dirigen el trabajo de sus miembros del equipo y reportan al líder
de la propuesta. Esta estructura ayuda a establecer conexiones fuertes entre
los diferentes departamentos o divisiones de la empresa, lo cual facilita el
proceso de la propuesta. En general, a cada grupo se le asigna desarrollar y
escribir una sección de la propuesta. Los coordinadores se aseguran de que
las tareas asignadas a cada grupo se completen a tiempo.
Sus responsabilidades incluyen:
• Asegurarse de que el grupo comprenda los objetivos generales y el
propósito de la propuesta.
• Hacer un esquema detallado de su sección de la propuesta.
• Asignar tareas de trabajo, establecer límites de páginas y plazos de
entrega.
• Usar consultores/subcontratistas u organizaciones colaboradoras
según sea necesario e integrar sus aportes en el proceso.
• Revisar borradores y participar en revisiones de la dirección del
material en borrador.
• Incorporar los comentarios de la revisión en la versión final de la
sección y agregarla a la propuesta total.
• Mantener al líder de la propuesta informado sobre el progreso del
grupo y solicitar ayuda según sea necesario.
3.3.9.3 5.10.2.3 Miembros del Equipo
Los miembros del equipo generalmente son empleados de la empresa que se
seleccionan por las contribuciones específicas que pueden hacer para
preparar la propuesta. A veces, es necesario agregar consultores externos o
empresas al equipo. Puedes agregar personal externo a través de acuerdos de
consultoría o acuerdos de colaboración.
92
3.3.9.4 Acuerdos de Consultoría
Estos acuerdos se hacen con personas que tienen experiencia especializada, a
menudo en temas técnicos. El acuerdo generalmente establece las
condiciones bajo las cuales el consultor trabajará con tu empresa e incluye
una cláusula que indica que no trabajará para una empresa competidora
durante el plazo del acuerdo. Si ganas el contrato y el consultor formará
parte del equipo del proyecto, esto también debería mencionarse en la
propuesta. Se debe incluir el currículum vitae del consultor junto con el de
los demás miembros del personal.
Es importante no engañar al cliente en cuanto a quiénes formarán parte del
equipo. Algunas empresas les gustan presumir de sus expertos para
impresionar al cliente, especialmente si pueden mencionar a algunos
consultores "famosos" de la industria, academia o campos técnicos. Si el
cliente le otorga a tu empresa un contrato basándose en esos nombres y luego
descubre que el consultor no trabajará en el proyecto, el cliente puede
considerar esta acción fraudulenta y podría cancelar el contrato o demandar a
la empresa.
3.3.9.5 Acuerdo de Colaboración
Un acuerdo de colaboración se puede usar para obtener experiencia en la
preparación de la propuesta y/o para obtener las capacidades de una
organización externa para trabajar en el proyecto. Esto se conoce como una
estrategia de "ir juntos y luego separarse". Dos o más empresas se unen para
completar un proyecto y luego se separan una vez que ha terminado. En este
caso, las empresas deberían elegir a una sola persona como enlace principal
con el cliente. De lo contrario, el riesgo de comunicación incorrecta entre el
cliente y las empresas que presentan ofertas es alto.
Es posible que tu empresa necesite hacer acuerdos de colaboración con dos o
tres subcontratistas para obtener todas las habilidades y conocimientos que el
proyecto pueda requerir. La empresa cliente puede ver este esfuerzo conjunto
con buenos ojos en comparación con los esfuerzos de tu empresa por sí sola.
El acuerdo de colaboración es un contrato legal entre tu empresa y las
organizaciones colaboradoras. Establece las condiciones y restricciones bajo
las cuales se realizará el trabajo y define las responsabilidades de todas las
93
partes. Es mejor que los departamentos legales de todas las partes
involucradas resuelvan los detalles del acuerdo para evitar problemas en el
futuro. Al igual que con los consultores, si las organizaciones colaboradoras
también trabajarán en el proyecto del cliente, esto debería destacarse en la
propuesta.
3.3.9.6 Especialista en Desarrollo de Propuestas
Algunas empresas recurren a especialistas en desarrollo de propuestas para
ayudarles a preparar propuestas cuando la empresa tiene personal o fondos
limitados para dedicar a una oferta en particular. Los consultores
profesionales sirven como líderes de propuestas o como un “equipo” de una
sola persona que coordina los esfuerzos de la propuesta. Algunas
organizaciones grandes utilizan equipos de estos especialistas a tiempo
completo para planificar y desarrollar propuestas en diferentes áreas de
trabajo con clientes.
Por ejemplo, las empresas que hacen mucho negocio con el gobierno pueden
tener especialistas en desarrollo de propuestas que se concentran
exclusivamente en preparar ofertas para distintas agencias gubernamentales.
Debido a que cumplir con las especificaciones de las ofertas del gobierno es
tan complejo y cambia constantemente, a menudo se requiere el esfuerzo a
tiempo completo de un especialista. Si tu empresa presenta ofertas solo
ocasionalmente para proyectos gubernamentales, deberías considerar
contratar a una consultoría externa para que te ayude a preparar la
propuesta. Si los especialistas actúan como líderes de propuestas o
coordinadores, cumplirán muchas de las mismas responsabilidades que las
personas internas de la empresa.
94
4 ANEXOS
4.1 CLIENTE: CRONOGRAMA INVERSO DE EJEMPLO PARA PLANIFICAR UNA
RFP
Acción Actividad
1 Pre-RFP
2 Identificar la necesidad
3 Estudio inicial
4 Pliego para justificar el proyecto
5 Estimar el presupuesto del proyecto
6 Aprobación del proyecto de RFP
7 RFP
8 Identificar los perfiles y el equipo
9 Identificar el cronograma y los hitos del proyecto
10 Identificar los requerimientos de alto nivel
11 Capacitar a los perfiles de nuestro equipo en las posibles nuevas tecnologías
del proyecto
12 Identificar a los usuarios que ayuden en la RFP
13 Desarrollar los requerimientos técnicos
14 Revisar los requerimientos con los usuarios
15 Revisar los requerimientos con los estándares y herramientas de nuestra
empresa
16 Finalizar los requerimientos técnicos
17 Desarrollar los requerimientos administrativos
18 Revisar los requerimientos con los usuarios
19 Revisar los requerimientos con los estándares y herramientas de nuestra
empresa
20 Finalizar los requerimientos administrativos
21 Escribir la RFP
22 Escribir los criterios de evaluación
23 Escribir el cronograma (desde el final hasta el principio)
24 Revisar la RFP
25 Enviar la RFP a los proveedores
26 Post-RPF
27 Permite que los proveedores formulen preguntas/respuestas durante un
periodo de tiempo
28 Recepción de las propuestas
29 Evaluar las propuestas
95
30 Pregunta a los proveedores, si lo necesitas
31 Primera criba de proveedores: quédate entre 2/3 proveedores
32 Establece reuniones con los proveedores (in situ), demos y referencias
33 Escoge un ganador
34 Negocia el contrato
35 Proporciona información a los proveedores descartados
36 Genera un documento de por que gana un proveedor y por qué los otros se
descartan
37 Revisar, borra y almacena como máximo 6 meses las propuestas descartadas
38 Comienza la Implementación
Para poder poner las fechas vamos a comenzar por el paso 38, establecemos la fecha
comienzo del desarrollo/implantación, y vemos moviéndonos para atrás, es decir,
¿Cuándo quiero que esté el paso 37?, ¿el 36? Así vamos asignando fechas hasta llegar al
primer paso. Podrás observar cuanto tiempo te llevará realizar una propuesta.
4.2 CLIENTE: EJEMPLO DE LA ORGANIZACIÓN DEL EQUIPO
Tablas, Excel, etc. etc.
Project
Manager
Legal
Lider
Ayudante
Product
Owner
Lider
Ayudante
Usuarios
IT
Lider
Ayudante
Compras
Lider
Ayudante
96
4.3 CLIENTE: EJEMPLO DE INFORMACIÓN ADMINISTRATIVA
A continuación, un ejemplo de la parte administrativa que podría enviarnos
un cliente. En este ejemplo he roto las subsecciones para que, en una
evaluación, como parte proveedora, puedas entender que podría contener
cada área.
Información administrativa
[NOMBRE_EMPRESA] emite esta solicitud de propuesta (RFP) para la modernización
de nuestro actual ERP. Esta sección proporciona la guía con la información
administrativa que requerimos a los proveedores.
A continuación, incluimos los puntos a tratar:
Cronograma de la RFP
Actividad Fecha Hora límite
Emisión de la RFP 01/01/2024
Interés de licitación +2 días 12:00
Reunión general con todos los proveedores + 4 días
Demo del actual ERP + 5 días
Dudas, fecha límite de envío por parte de los
proveedores
+ 7 días 15:00
Envío de respuestas por parte del cliente +9 días 15:00
Fecha límite del envío de RFP por parte de los
proveedores
+15 días 18:00
Preguntas del cliente a los proveedores +19 días
Finalización de la evaluación +23 días
Emisión de un ganador +25 días
Nota: Si la fecha inicial es 01/01/2024, +15, significa que es el 16/01/2024.
Estas fechas que os propongo son un ejemplo de lo que podrías proponer. Al
menos debes dejar 15 días laborables desde que nos envías una propuesta a
los proveedores hasta la fecha límite de respuesta. Muchas veces nos lo piden
los clientes en una semana y en una semana en ciertas organizaciones es
muy complicado dar la respuesta tal y como nos gustaría darla. Y en otras
que no tienen tanta cadena burocrática, posiblemente en una semana
tampoco puedan darte una propuesta con la que se sientan cómodos.
Información del contrato
Aquí no soy ningún experto, os pongo un poco lo que me suelo encontrar.
Habitualmente nos ponen una frase como la siguiente: “por favor complete la
97
siguiente información de contacto”. ¿Por qué nos lo piden así? Primero por que
puedes tener un proceso automatizado que al llegar el mail revise el
documento de Word, PowerPoint o PDF y lo remita a quien toca, otra por
puro formalismo y comodidad para completar la información en el CRM del
cliente, etc. etc.:
[Nombre de tu empresa]
[Dirección postal completa]
[Telf. De contacto de la empresa]
[email de contacto de la empresa]
Persona de contacto:
[Nombre Persona de contacto] | [Cargo]
[email de la persona de contacto]
[Telf. Persona de contacto]
Con esta información es suficiente para que el cliente pueda localizar a quien
corresponda.
Intención de licitación
Debe ser algo escueto, digamos: apéndice G
4.4 CLIENTE: INSTRUCCIONES PARA RESPONDER A LA RFP
Algo que muchas veces no veo, como ya os he comentado, pero que aquí os
doy como guía que servirá para el cliente y el proveedor. Espero que pueda
ayudar y hacer la vida más fácil a ambas partes.
jmfloreszazo
luup_hr
weddingpark
sms_tech
pirika_info
shippio
maijun
suzakiyoshito
sugitama
atsumiee
recruitasken
tomomifuruya
yanaken
frogandcode
jonrohan
davidbonilla
samanthasiow
tmm1
bluesmoon
reverentgeek
brad_frost
revolveconf
phodgson
eileencodes
jrom