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.