A veces se confunde un pliego de condiciones (SOW) con un contrato marco de servicios (MSA) y, de hecho, algunos utilizan los términos indistintamente.
Por otro lado, un SOW es una forma ideal de delimitar el alcance de un proyecto, especialmente de un proyecto complejo, a diferencia de un MSA, que detalla un acuerdo de servicios de larga duración. (Puedes leer un blog mío reciente sobre cómo elaborar contratos, SLA y MSA).
Muchas veces un cliente exigirá específicamente un SOW, por lo que debes estar preparado para elaborar uno que convenga a ambas partes.
Si ya tiene un contrato o un acuerdo de servicios administrativos con un cliente, su pliego de condiciones puede abarcar algunas de las mismas cuestiones y reforzar esos vínculos.
Resumen general del pliego de condiciones
Un SOW, al basarse casi siempre en un proyecto, se centra en definir cuáles son los entregables y cuándo deben llegar.
Igualmente importante es que el SOW define todos los hitos que sustentan los entregables y quién se encarga de qué. Esto requiere calendarios, una forma de supervisar el progreso y un mecanismo para vincular el pago al avance del proyecto. Además, en el SOW se definen todos los recursos críticos para el proyecto, así como qué partes asumen qué costes.
También es necesario llegar a un acuerdo sobre cómo se gestiona y se rige el proyecto, mediante qué métodos, y qué define el éxito o el fracaso. A veces estas mediciones incluirán KPI; otras veces hay otras formas de definir si el proyecto avanza correctamente y estas mediciones dependen del alcance o el estilo del proyecto. Algunos, por ejemplo, pueden estar más relacionados con la infraestructura o la red, mientras que otros se centran exclusivamente en nuevos servicios. Obviamente, estos se medirían de forma muy diferente. Por ejemplo, medir un proyecto de infraestructura puede requerir asegurarse de que el hardware esté instalado, configurado y tenga un buen rendimiento y seguridad de red. Un servicio se evaluaría en función de si está debidamente personalizado para el cliente, si los usuarios finales pueden aprovechar el servicio (como en el caso de las copias de seguridad en la nube) y si existe la confianza de que el servicio puede cumplir los SLA.
Puede ser una buena idea establecer un procedimiento de gestión de cambios para hacer frente a cambios en el alcance del proyecto, dificultades imprevistas fuera del control de cualquiera de las partes u otras circunstancias. De este modo, dispondrás de un mecanismo para abordar los cambios solicitados teniendo en cuenta a ambas partes.
Sin embargo, un pliego de condiciones no siempre puede cubrir todos los aspectos del proyecto. En el caso de proyectos complejos, puede haber una serie de documentos relacionados y apéndices para tratar los detalles, como las especificaciones en el caso de un proyecto de software o apéndices contractuales relacionados con las garantías de servicio.
Cómo un SOW conduce a otros trabajos
Al igual que un simple contrato, MSA o SLA, un SOW se utiliza para medir el rendimiento de un proveedor de servicios. Si su rendimiento es bueno, el SOW es una herramienta de ventas clave para conseguir nuevos negocios. No sólo ha demostrado que puede realizar el proyecto, sino que también entiende al cliente y está totalmente preparado para hacer más. Y puedes demostrarlo de forma detallada, mostrando cómo has gestionado todos los aspectos del proyecto y demostrando tu excelente rendimiento.
Aspectos Jurídicos
Al igual que con un contrato o un MSA, cualquier SOW debe ser revisado cuidadosamente por un asesor jurídico. Al mismo tiempo, el lenguaje incluye tanto aspectos técnicos como jurídicos. Dado que el pliego de condiciones es un documento utilizado por muchas personas, incluidos directivos y otros profesionales, debe redactarse utilizando un lenguaje claro y sin jerga en la medida de lo posible. Es importante que el documento sea comprensible para todos los lectores, no sólo para abogados y expertos técnicos. Para ello, pídale a un miembro de su equipo o a un tercero que lo lea para comprobar su claridad y haga las correcciones oportunas.
Estos son algunos de los aspectos jurídicos que debe contemplar el pliego de condiciones.
Propiedad intelectual
En muchos casos, un MSP propiedad intelectual exclusiva para sus clientes, es decir, inventos que tienen valor de mercado. Esto podría incluir técnicas, scripts, código y herramientas de software completas. En esta sección, el cliente debe aceptar que, aunque se le concedan derechos de uso, usted, como creador, es el propietario de dichos inventos.
Información confidencial
Sus prácticas comerciales, precios y descuentos pueden ser tan valiosos como su propiedad intelectual.
Sus clientes no deben compartir esta información con sus clientes potenciales y, sobre todo, con la competencia.
Lo mismo ocurre con los MSP. Como proveedor de servicios de confianza, usted tiene acceso a datos y estrategias confidenciales de los clientes. Proteger esta información no solo redunda en su interés profesional, sino también en su interés legal.
Rescisión del Contrato
La rescisión puede perjudicar a ambas partes. Si rescindes el contrato, el cliente no obtendrá el proyecto o el servicio que quizá necesite con urgencia. En tu caso, es posible que no obtengas los ingresos con los que contabas y que te resulte difícil recuperar los costes irrecuperables.
El SOW debe determinar, para ambas partes, cuál es la causa justa de rescisión y si se puede compensar a cualquiera de las partes por el trabajo prometido o entregado en el momento de la rescisión, y de qué manera. Debe establecer a quién pertenece qué propiedad, como el hardware físico, y si (y cuándo) debe devolverse al verdadero propietario.
Algunos MSP
El Gobierno del estado de Texas colabora con proveedores de servicios gestionados (MSP) y proveedores de servicios en la nube, que prestan asistencia en materia de aplicaciones y operaciones de TI. En un documento titulado «Cómo redactar un pliego de condiciones eficaz», el Gobierno ofrece asesoramiento a los MSP. Un ejemplo resulta especialmente pertinente, ya que se refiere a un contrato de pliego de condiciones relativo a MSP básicas MSP .
He aquí el ejemplo: "El cliente desea y el proveedor proporciona supervisión y mantenimiento in situ que incluyen supervisión y alerta remotas de equipos de red, reparación y mantenimiento remotos e in situ, y servicios de respuesta a cortes de suministro en sitio en Houston, Dallas y El Paso", reza el documento.
Así es como se dividen las responsabilidades.
- "Funciones y Responsabilidades del Cliente
- Acceso a los tres emplazamientos
- Adquisición y entrega de equipos de red
- Diseño de la configuración de todos los equipos de red
- Funciones y responsabilidades de los proveedores
- Responder a las interrupciones de la red de acuerdo con los SLA.
- Responder a las solicitudes de los clientes de acuerdo con los SLA
- Actualice los planos de la red a medida que se produzcan cambios".
El proveedor, o MSP, debe:
- " Realizar un inventario del emplazamiento y proporcionar una lista de inventario y esquemas actualizados.
- Informes semanales de situación".
Texas también exige SLA como parte del SOW. "Los niveles de servicio permiten al cliente especificar las expectativas de nivel de servicio para los servicios prestados. Los niveles de servicio pueden estar relacionados con los tiempos de respuesta del servicio, el tiempo de actividad de una red, el tiempo medio de reparación (MTTR) o medidas similares.
- El proveedor responderá a las averías en un plazo de dos horas desde su notificación.
- El proveedor proporcionará un estado en las 4 horas siguientes a la notificación del corte".
Texas también tiene especificaciones y requisitos para aceptar el trabajo y, si no se cumplen, el Estado retiene el pago.
- " Realizar un inventario del emplazamiento y proporcionar una lista de inventario y esquemas actualizados.
- Informes semanales de situación".
Vincular el pago al trabajo realizado también es fundamental para Texas, y en su documento se detalla: "La fijación de precios y los calendarios e hitos de pago pueden estar vinculados a las entregas, como se ha indicado anteriormente, pero también pueden estar vinculados a la finalización de las fases de un proyecto, siempre y cuando el proveedor demuestre la finalización de las tareas y el seguimiento hacia el objetivo del proyecto.
Ejemplo: Fases del proyecto que pueden generar pagos:
- Informe sobre las prácticas empresariales actuales
- Puede incluir entrevistas con el personal, redacción de informes, revisión de plataformas informáticas, etc.
- Informe de análisis de carencias
- Esto incluiría las tareas del vendedor de identificar el objetivo final del cliente, analizar los sistemas y procesos actuales y redactar el informe de deficiencias.
- Informe final de evaluación"
CompTIA al rescate
Para muchas MSP , CompTIA ofrece una gran cantidad de recursos. En la guía «Incorporating a Statement of Work», la organización ofrece orientación sobre los aspectos fundamentales de la elaboración de un SOW y explica por qué puede ser necesario contar con uno.
Resolución de litigios
Como con cualquier contrato, un pliego de condiciones ayuda a proteger a ambas partes en caso de litigio, sobre todo si éste parece encaminarse hacia los tribunales.
"Si hay una disputa sobre un contrato, una de las primeras cosas que hace un tribunal es intentar entender qué pretendían las partes. El pliego de condiciones es el lugar indicado. Todo acuerdo debe contener algún tipo de descripción de lo que se vende, el tipo de trabajo que se va a realizar o los objetivos que hay que alcanzar; no tiene por qué ser más elaborado de lo que justifiquen las circunstancias", argumenta CompTIA.
Supuestos básicos
CompTIA cree que gran parte del SOW puede basarse en la información de su cotización original, pero luego se agregan detalles sobre cómo se tratan las contingencias. "Sin duda, usted cotizó su precio basándose en lo que haría para el cliente, lo que el cliente o un tercero podría hacer y cuándo o con qué frecuencia. A menudo, estas suposiciones se basan en lo que se puede controlar y lo que no", explica CompTIA.
El grupo cita el ejemplo de una reparación en sitio que debería durar un día. Sin embargo, ese calendario presupone que usted recomendó al cliente que tuviera piezas de repuesto en su inventario. Si eso no ocurre, esa reparación de un día puede convertirse en muchas.
Cuanto mayor es el ámbito, más abundantes son los problemas
Para proyectos o tareas de menor envergadura, un contrato sencillo puede ser suficiente. Sin embargo, los proyectos más amplios y complejos introducen más variables. «La instalación plantea una serie de cuestiones cuando se incluye en el contrato. ¿Llave en mano? ¿Tiempo y materiales? ¿Pagos por hitos? ¿Coordinación de contratistas? La prestación de servicios de asistencia técnica añade otra serie de problemas», son algunas de las cuestiones que planteó CompTIA. «¿Qué paquetes tendrá que dar soporte? ¿Qué nivel de formación tienen sus usuarios? ¿Qué antigüedad tiene su sistema? La naturaleza del negocio del cliente y las leyes que lo regulan también complican la ecuación. Los sectores sanitario y financiero suelen manejar grandes cantidades de información de clientes que es altamente sensible y potencialmente perjudicial si se ve comprometida».
Conclusión
Los MSP ponen todo su corazón en los servicios que prestan. Al mismo tiempo, los clientes no siempre son perfectos. Puede ser difícil tratar con ellos y pueden surgir problemas de comunicación porque no entienden la tecnología tan bien como usted.
Por eso son tan importantes contratos como los SOW y los MSA. Ofrecen protección jurídica en caso de malentendido y proporcionan al cliente una hoja de ruta sobre lo que usted ofrece. También pueden ser documentos vivos que cambian a medida que se añaden servicios nuevos o de mayor nivel.
