Capítulo 24 - Solicitudes de propuestas y negociaciones competitivas

1

Introducción

Proporciona una declaración del problema y debe ser lo suficientemente detallada para que los proveedores comprendan los problemas comerciales que impulsan la RFP y los problemas técnicos que pueden haber precipitado el problema.

2

Instrucciones y administración de la propuesta

Contiene todos los requisitos administrativos y la información que un proveedor debe cumplir para presentar una propuesta aceptable. Esta sección incluye reglas básicas para la contratación, desde la presentación de la RFP hasta la adjudicación del contrato, y debe contener los siguientes tipos de información:

• si se llevará a cabo una conferencia previa a la propuesta y cuándo;
• Fechas relevantes para el ciclo de compras
• requisitos para preparar y presentar propuestas (es decir, los requisitos del Código de Virginia , así como el protocolo de propuestas)
• Cómo se evaluarán las propuestas
• RFP Nombre e información de contacto del punto de contacto único
• Cuándo, dónde y a quién deben presentarse las propuestas
• Otra información que se requiere para que un proveedor responda plenamente

Si las instrucciones están incompletas o no son claras, los proveedores pueden pasar por alto reuniones o hitos críticos. Algunos proveedores pueden ver la falta de instrucciones de calidad como una señal de un equipo de proyecto débil o un proyecto conflictivo, lo que podría influir en los principales proveedores de la industria para que no presenten propuestas. El incumplimiento por parte de un proveedor de los requisitos administrativos de la RFP puede ser motivo de rechazo de la propuesta. Esta sección debe presentar reglas claras para responder a la RFP y para que los proveedores estén al tanto de las sanciones por no cumplirlas.

3

Formato de la propuesta

Proporciona detalles sobre cómo se formatearán y encuadernarán las propuestas y los medios requeridos (es decir, copia impresa, CD, etc.). Es útil incluir una tabla que muestre si las distintas secciones de la propuesta se van a presentar por separado; es decir, técnico del costo, redactado, etc.). Esta sección no debe duplicar ni entrar en conflicto con las instrucciones de la propuesta en la sección 2.

4

Situación actual

Describa con precisión los antecedentes organizacionales de la agencia y los entornos comerciales y técnicos actuales del proyecto para que los proveedores puedan proponer soluciones de manera efectiva y precisa para adaptar o modificar ese entorno para satisfacer los nuevos requisitos. La descripción del entorno empresarial actual debe incluir a todos los usuarios y benefactores de los servicios y procesos empresariales actuales afectados. La descripción del entorno técnico actual debe ser una definición clara que incluya todo el hardware y software que se esté utilizando, lo que podría utilizarse o debería utilizarse para abordar los requisitos del proyecto, así como las interfaces actuales con otros sistemas/plataformas y/o aplicaciones existentes. El flujo de trabajo y las interfaces de la aplicación se pueden presentar mediante elementos visuales.

5

Requisitos funcionales y técnicos

Proporciona requisitos funcionales y técnicos e información suficiente para permitir que los proveedores entiendan los problemas y preparen una propuesta completa y firme. Esta visión general debe abordar tanto la aplicación empresarial actual como el entorno técnico (hardware, software, comunicaciones). Se recomienda que los organismos no utilicen requisitos técnicos que "deban ser" y "deberán", sino que permitan que los proveedores sugieran cómo resolverán el problema como parte de una propuesta basada en la solución. La sección de requisitos técnicos y funcionales incluye preguntas a las que los proveedores deben responder, tales como:

• Factores críticos de éxito
• Especificaciones funcionales para el sistema actual
• Especificaciones funcionales para el sistema proyectado
• Especificaciones de rendimiento
• Expectativas de nivel de servicio
• Requisitos de hardware (si es obligatorio)
• Requisitos de software
• Requisitos de seguridad y protección de datos
• Requisitos de comunicación (si es obligatorio)
• Requisitos de prueba
• si su solución cumple (o puede cumplir) con los ITRMPSG de VITA Security, Data Standards and Enterprise Architecture y IT Accessibility/508 Compliance

Los requisitos de gestión de proyectos establecen las condiciones para gestionar e implementar el proyecto. Esta sección debe proporcionar a los proveedores la información que necesitan para desarrollar un plan de proyecto, un plan de mitigación de riesgos u otro plan de gestión, según sea necesario para la complejidad y la criticidad de la misión del proyecto y que abarque la definición de requisitos, la implementación, la instalación, las pruebas, la capacitación, el mantenimiento y otras fases del proyecto. El plan de proyecto propuesto proporciona la seguridad de que el proveedor tiene los recursos necesarios para ejecutar el contrato con éxito. El plan de dirección del proyecto suele contener lo siguiente:

• Necesidades de personal
• Responsabilidades de la preparación del sitio
• Cronograma y plan de entrega e instalación
• Requisitos de la prueba de aceptación del sistema
• Requisitos de mantenimiento del sistema
• Requisitos de capacitación del sistema
• Requisitos de documentación

Las agencias deben recordar que es posible que un proveedor pueda cumplir con los requisitos técnicos, pero no pueda cumplir con los requisitos de gestión, como lo demuestran sus respuestas deficientes o inadecuadas a esta sección. La sección de gestión ayudará a diferenciar entre proveedores con capacidades de gestión maduras o inmaduras.

Puede pedir a los proveedores que identifiquen todas las suposiciones y los riesgos potenciales asociados con la RFP y los objetivos deseados del proyecto; y/o pedirles que describan en detalle un proyecto similar y cómo resolvieron problemas o incidencias que ocurrieron durante su actuación a satisfacción de su cliente.

6

Medidas de Desempeño y Disposiciones de Cumplimiento Claras y Distintas

IT las solicitudes y contratos que cumplan con la definición de "alto riesgo", tal como se define en los 2.2-4303.01 del Código de Virginia, deben incluir medidas de rendimiento y disposiciones de cumplimiento claras y distintas, incluidos los recursos en caso de incumplimiento del Proveedor.

Utilice las herramientas a continuación para obtener más información sobre las medidas de rendimiento claras y distintas y las disposiciones de cumplimiento, incluidos los recursos:

         Matriz de requisitos mínimos para las contrataciones de IT principales, las contrataciones de IT de alto riesgo, y

         1.  Adquisiciones delegadas 

         2.  Herramienta de métricas de rendimiento

7

Perfil del proveedor

Se pide a los proveedores que describan sus cualificaciones empresariales y profesionales y que proporcionen referencias. Se les debe pedir que presenten detalles sobre su estado corporativo y financiero y los clientes que servirán como referencias para su desempeño profesional e integridad. Los siguientes ejemplos son los que normalmente se requieren en esta sección:

• Historial corporativo, estructura organizativa, ubicaciones y estado del tamaño de la empresa del proveedor (es decir, estado de certificación DSBSD, si corresponde).
• Antecedentes generales, experiencia y capacidad del proveedor para proporcionar el tipo de solución o producto que se está
• Una descripción de la relación entre el proveedor y cualquier socio/subcontratista/fabricante propuesto, si lo hubiera, y cuánto tiempo ha durado esta relación.
• Evidencia de que el proveedor tiene las habilidades técnicas, operativas y de gestión, el personal y los recursos financieros necesarios y la viabilidad para realizar la
• Una lista de productos, sistemas o sistemas
• Nombres de clientes con proyectos, configuraciones y/o aplicaciones similares que puedan proporcionar referencias, incluidos nombres de contacto y números de teléfono.
• Calificaciones del proveedor, incluidos los currículums, el perfil de la empresa y el negocio
• Método habitual del proveedor para proporcionar servicios, incluida una descripción del plan de trabajo, los métodos que se utilizarán y un ejemplo de cronograma de entregables/cronograma para el proyecto.

8

Sección SWaM

Se solicita a los proveedores que proporcionen un "Plan de adquisición y subcontratación del proveedor" que establezca el porcentaje de compromiso general que el proveedor anticipa gastar directamente con los subcontratistas en el cumplimiento de los requisitos del contrato. Además, se solicita a los Proveedores que proporcionen una lista de todos los subcontratistas que anticipan utilizar en la ejecución del contrato por parte del Proveedor. La lista de subcontratistas debe designar a los subcontratistas que son empresas de SWaM, así como a los que no son empresas de SWaM. En el caso de que un proveedor no DOE previsto utilizar subcontratistas en la ejecución de un contrato, se le pide al proveedor que indique este hecho en su respuesta.

9

Información de precios

Especifica cómo los proveedores deben proporcionar información sobre precios y proporciona un formato detallado para que lo sigan en el desarrollo de sus propuestas de precios. Las instrucciones deben ser lo suficientemente claras para garantizar que las propuestas de precios puedan compararse en igualdad de condiciones. Para facilitar esta comparación, considere proporcionar una hoja de cálculo de muestra que divida el sistema propuesto en componentes como los siguientes:

• Software del sistema
• Software de desarrollo de aplicaciones
• instalación
• mantenimiento
• Capacitación
• Documentación
• Gestión de proyectos
• Integración de hardware o software único
• Tarifas de licencia (en curso)

Incluya un cronograma/escenario de precios como ejemplo de cómo se deben enviar los precios de la propuesta. Si la fijación de precios a tanto alzado no es ventajosa, utilice un escenario de fijación de precios para obtener precios por cantidades u horas desconocidas. Pida un desglose de los costos recurrentes frente a los no recurrentes. La lista de precios debe estar vinculada a los entregables y debe coincidir con el método de pago estipulado en la solicitud.

Al observar los programas de precios, preste atención a los precios que implican costos únicos frente a costos recurrentes. El precio inicial de un paquete de software es un costo único; Las tarifas anuales de mantenimiento y licencias de software son costos recurrentes que deben identificarse para desarrollar el costo total del ciclo de vida de un proyecto. El precio no suele ser el único determinante para la adjudicación, pero debe utilizarse para romper un empate entre dos proveedores con propuestas técnicas y de gestión igualmente buenas.

En el caso de proyectos complejos, también puede pedir a los proveedores que presenten una lista de precios por hitos a la que se puedan aplicar porcentajes de retención que se pagarán después de la aceptación final en la factura final. Esto motiva a los proveedores y agrega protección para la agencia si la aceptación final se retrasa o es problemática. También permite una divisibilidad más fácil del contrato en cualquier hito si el proveedor no cumple.

10

Acuerdo estándar de agencia (es decir, modelo de contrato)

Contiene un modelo de contrato propuesto con acuerdos de no divulgación, confidencialidad, protección de datos y requisitos de seguridad, garantías, requisitos de acuerdos de licencia y otros términos y condiciones estatutarios, legales y específicos de IT, o cualquier término federal que pueda ser necesario. Se debe pedir a los proveedores que marquen el modelo de contrato propuesto para resaltar todas las excepciones con las que no puedan estar de acuerdo. Los proveedores no deben marcar la cláusula de responsabilidad en este momento.

Pueden plantear cuestiones o comentarios por primera vez durante las negociaciones posteriores. Identifique los problemas más llamativos durante el período de evaluación de la propuesta porque es posible seleccionar un proveedor que no aceptará el contrato de la agencia.

11

Sección del proveedor (opcional)

Permite a los proveedores incluir información que consideren relevante aunque no sea obligatoria o solicitada en la RFP. También pueden discutir posibles problemas que sean relevantes para la RFP y para su propuesta. Por ejemplo, un proveedor puede tener características adicionales del producto para demostrar que están fuera del alcance de la RFP, presentar una solución única que no fue anticipada por el comprador, o puede proporcionar una solución a un problema evidente en la RFP que otros proveedores no consideraron. Incluso si este proveedor en particular no DOE ganar, puede valer la pena considerar la explicación del problema y la posible solución.

12

Apéndices

Contener información voluminosa pero relevante, como diagramas de red, estudios de requisitos técnicos, esquemas del plan del proyecto y otra información detallada. Algunos ejemplos son los siguientes:

• Hojas de cálculo con estadísticas
• Planos de redes de comunicaciones y
• Lista de
• Las normas utilizadas en el marco de la
• Plan tentativo del proyecto con
• Modelo de contrato
• Formulario del plan de subcontratación para pequeñas empresas
• Formulario de la Comisión de la Corporación Estatal completado por el proveedor registrado para realizar transacciones comerciales en el

A continuación, la información está disponible para el proveedor, pero no DOE distraer la atención de la parte narrativa de la RFP. Nota: Dígale a los proveedores si deben utilizar esta información al desarrollar sus propuestas.