¡Su navegador no admite JavaScript!

Capítulo 25 - Formación de contratos de TI

25.4 Formación de un contrato de TI

25.4.2 Directrices generales para el éxito de un contrato de TI

La clave del éxito en la formación de cualquier contrato de IT es establecer y cumplir con las necesidades comerciales de la agencia y las expectativas del proyecto. Esto puede lograrse mediante la designación de un comité directivo conjunto para gestionar el éxito del contrato; identificar a las personas de ambas partes que tendrán la responsabilidad del proyecto; el diálogo continuo y la discusión abierta de los problemas; mantener el contrato actualizado con un proceso eficaz de control de cambios; y exigir al proveedor que proporcione informes de progreso tempranos y frecuentes para minimizar la posibilidad de sorpresas. Según IT expertos en contratos, la mayoría de los problemas IT contratos son el resultado de uno de los siguientes escenarios:

  • El proveedor asume compromisos poco realistas (por ejemplo, garantías de rendimiento, cronogramas inalcanzables, contratos de precio fijo sin el análisis requerido) o el proveedor subestima el tiempo de mano de obra, los costos y los riesgos.

  • No hay una línea de base contractual firme (por ejemplo, requisitos, términos y condiciones y declaraciones de trabajo poco claros) en el contrato.

  • El proveedor no DOE gestionar la relación de agencia (es decir, la relación de trabajo debe mejorarse continuamente y los problemas no deben ocultarse).

  • El contrato no DOE contener un procedimiento y un proceso para gestionar el cambio (es decir, no hay un proceso formal de gestión del cambio).

Se deben utilizar las siguientes consideraciones de mejores prácticas de la industria al formar un contrato de IT :

  • Un contrato de IT exitoso incluirá todas las expectativas y compromisos técnicos y administrativos de ambas partes. El contrato debe incluir procedimientos para revisiones de calidad, pruebas, medición del progreso, captura e informes de rendimiento, gestión de defectos, procesamiento de solicitudes de cambio, actualizaciones y escalamiento de problemas. La agencia debe considerar sus necesidades con respecto a la confiabilidad del proveedor, el rendimiento, la funcionalidad, la compatibilidad, la vida útil, el cumplimiento de la seguridad, el soporte y el costo.

  • Con el fin de reducir la probabilidad de fracaso, el contrato debe ser lo más específico posible. El fracaso del contrato puede evitarse asegurándose de que ambas partes acuerden un conjunto común y escrito de definiciones, especificaciones y plazos con respecto a los servicios o sistemas que se contratan. A medida que surjan preguntas y problemas, ambas partes pueden consultar y, si es necesario, revisar el documento.

  • El proveedor busca definir sus obligaciones contractuales, mientras que la agencia busca resolver problemas comerciales. Para hacer frente a esta diferencia de perspectivas, el contrato debe incluir cláusulas de conflicto y cambio. Por ejemplo, el acuerdo del contrato puede requerir reuniones mensuales para revisar el desempeño, los problemas y los éxitos. Esto fomenta la gestión de proveedores y ayuda a las partes a abordar los problemas antes de que se conviertan en problemas importantes.

  • La agencia debe monitorear cuidadosamente todos los contratos IT , especialmente los contratos para IT servicios. En la mayoría de los contratos de IT , hay un elemento de servicio o soporte involucrado, y los proveedores deben estar sujetos a sus garantías contractuales de rendimiento/tiempo de respuesta y niveles de servicio prometidos más allá del período de implementación inicial. Si el proveedor no proporciona un servicio adecuado o no cumple con los niveles de servicio acordados, si el producto no funciona según lo prometido o si el uso de la agencia no es tan alto como se anticipó, la agencia puede recibir un reembolso parcial o solicitar un crédito o un descuento mayor.

  • Existe una ventaja en aceptar un acuerdo de nivel de servicio (SLA) detallado que confirma cuáles son exactamente las responsabilidades del proveedor en virtud del contrato. Un buen SLA reflejará las discusiones de sentido común del proyecto y buscará un equilibrio de intereses e incentivos.

  • Los precios deben adaptarse a ciertos cambios en el contrato, por ejemplo, cambios en los servicios, servicios opcionales y SLA revisados o incumplidos. Otra modalidad de precios adaptables incluiría los servicios basados en suscripciones, como en las adquisiciones de software como servicio, en las que la fijación de precios de pago por uso (o precios escalables) debería incluirse en la fijación de precios para que las agencias sólo paguen por el número real de usuarios del servicio. Si los precios de los contratos son fijos a lo largo de un período, puede ser necesario considerar los aumentos de precios, y a veces las disminuciones. Las agencias deben tratar de limitar los aumentos a la tasa de inflación e incluso pueden incluir un tope; es decir, +/-3% del IPC.

  • Ambas partes deben acordar contractualmente expectativas, promesas y contingencias específicas. Por ejemplo, las especificaciones del sistema deben incluir no solo la funcionalidad requerida, sino que también deben detallar los requisitos o restricciones de rendimiento, los requisitos de compatibilidad, la vida útil anticipada y los niveles aceptables de defectos.

  • Ambas partes deben definir de manera clara e inequívoca los términos, condiciones y actividades clave, como el significado de "pruebas beta" o los estándares para determinar si la agencia ha aceptado el sistema. En el mundo IT , la aceptación de un sistema puede ocurrir en muchos momentos diferentes, como cuando ha pasado una serie de pruebas acordadas ("pruebas de aceptación") y ha estado en funcionamiento durante un cierto período de tiempo sin defectos graves. Si todas las partes no están dispuestas a definir la aceptación, esa es una fuerte señal de advertencia de que puede surgir una disputa. Sin embargo, el ejercicio de crear un SLA puede eliminar posibles áreas problemáticas mucho antes de cualquier firma, pago o entrega.

  • Todas las referencias horarias deben ser fechas específicas. Evite el uso de "tiempo razonable" o "prontamente" y sea específico en los requisitos de cada parte en virtud del contrato. es decir, "dentro de los tres días siguientes (en algún momento; es decir, la fecha de adjudicación del contrato)".

  • Si se utilizan fórmulas dentro del acuerdo, asegúrese de que funcionen.

  • No use referencias vagas como "preparado a nuestra satisfacción", "de manera oportuna", "se esperaría razonablemente que lo hiciera". Es difícil determinar cuándo un proveedor "se ha desempeñado de manera oportuna".

  • Evite usar palabras como "materialidad" y "únicamente" a menos que se incluyan definiciones.

  • Seleccione cuidadosamente el uso de las palabras "deberá" (obligatorio) y "podrá" (permisivo).

  • Si el contrato se define como de "alto riesgo" de conformidad con el 2.2-4303.01 del Código de Virginia, el contrato debe contener métricas de rendimiento distintas y medibles y disposiciones de aplicación claras, incluidas sanciones e incentivos, que se utilizarán en caso de que no se cumplan las métricas de rendimiento del contrato u otras disposiciones.

Finalmente, VITA recomienda que todos los documentos del contrato suban y bajen por la cadena de mando en las organizaciones de ambas partes según sea necesario para asegurarse de que todo el personal relevante entienda lo que se promete y lo que se espera, y que el contrato final incluya a todos. Además, la División de Gestión y Supervisión de Proyectos de VITAproporciona plantillas y herramientas estándar relacionadas con proyectos de la Commonwealth, incluido un Glosario de Gestión de Tecnología, para una terminología basada en ITpara impulsar la coherencia en toda la Commonwealth. (Visita: https://www.vita.virginia.gov/it-governance/project-management/).


Busque en el manual por palabras clave o términos comunes.