Declaración de trabajo de SAP: qué debe contener

Una declaración de trabajo (SOW) de SAP es el documento contractual que dice qué entregará el socio, con qué esfuerzo, quién lo hará y cómo puede cambiar. Debe cubrir el alcance, los supuestos y las exclusiones detallados, el esfuerzo por fase y por rol, los entregables con criterios de aceptación, los recursos nombrados y el control de cambios.

La mayoría de las SOW cubren el alcance razonablemente bien. Lo que los clientes suelen omitir son los supuestos y las exclusiones detallados, y esa es la sección que decide lo que usted acaba pagando.

Este artículo forma parte de mi guía sobre cómo elegir un socio de implementación de SAP. La SOW es el último paso de ese proceso, después de la RFP para socios de SAP y de las presentaciones orales. Para ver un ejemplo práctico de revisión de una SOW antes de la firma, lea mi caso práctico sobre la negociación de contratos de ERP.

Una buena SOW de SAP se lee como un manual de funcionamiento del programa. Cualquier persona de su lado debería poder abrirla y responder a tres preguntas: qué recibimos, de qué depende y qué ocurre cuando algo cambia.

Estas son las secciones que necesita, y lo que sale mal cuando falta alguna:

Sección	Qué debe decir	Qué ocurre si es escasa
Alcance	Procesos, módulos, sociedades, centros, países y usuarios dentro del alcance	Cada taller vuelve a abrir la cuestión de qué estaba incluido
Supuestos	Las condiciones de las que depende el precio, cada una con una consecuencia si resulta falsa	El socio presenta solicitudes de cambio que usted no puede rebatir
Exclusiones	Lo que el socio no hará, y quién lo hace en su lugar	El trabajo queda entre usted y el socio, y nadie se responsabiliza
Enfoque y fases	El método, el plan de fases y las puertas de calidad	No hay un punto acordado en el que una fase esté terminada
Esfuerzo	Esfuerzo estimado por fase y por rol	No puede saber si el ritmo de consumo va según el plan
Entregables y aceptación	Documentos y resultados con nombre, criterios de aceptación, plazo de aprobación	Se pagan facturas por trabajo parcial
Recursos	Personas clave nombradas, roles, dedicación y reglas de sustitución	El equipo que conoció en las presentaciones orales no es el que está en el proyecto
Responsabilidades del cliente	Qué debe aportar su gente, y cuándo	Los retrasos causados por su lado se convierten en solicitudes de cambio del socio
Control de cambios	Cómo se presenta, evalúa, cotiza y aprueba un cambio	Las solicitudes de cambio se convierten en una segunda línea de ingresos
Gobierno	Comité directivo, informes, escalado	Los problemas salen a la luz tarde, cuando son caros

Redacte usted mismo el alcance antes de pedir precios, para que los socios coticen su alcance y no el suyo propio.

Esta es la sección que los clientes suelen omitir. Sin ella, el precio descansa en condiciones que nadie de su lado ha leído ni aceptado.

Un supuesto es una condición sobre la que el socio ha cotizado. Una exclusión es trabajo que el socio no ha cotizado en absoluto. Ambos tienen que ser lo bastante concretos para que un tercero pueda comprobar si se cumplieron.

Tipos de supuestos que hay que dejar por escrito

Cada supuesto necesita una consecuencia. «Si resulta falso, el cambio pasa por el control de cambios con una evaluación de impacto» convierte un supuesto de adorno en un control.

Estas son las categorías que debe cubrir una SOW de SAP:

1. Alcance organizativo. El número de sociedades, centros, organizaciones de ventas, países y entidades jurídicas que cubre el precio.
2. Alcance de procesos. Los procesos de negocio dentro del alcance, con nombre, y los procesos estándar de SAP que el socio espera que usted adopte.
3. Volumen WRICEF. El número de flujos de trabajo, informes, interfaces, conversiones, ampliaciones y formularios, por complejidad. Los presupuestos se resienten en la fase Explore a medida que crece esta lista, así que el recuento de partida debe estar en el contrato.
4. Datos. Los objetos de datos que hay que migrar, el volumen de histórico, el número de cargas de prueba y quién depura los datos.
5. Integraciones. Cada interfaz con nombre, con el sistema del otro lado y quién modifica ese sistema.
6. Pruebas. El número de ciclos de prueba, quién redacta los guiones, quién los ejecuta y quién corrige los defectos.
7. Disponibilidad del cliente. Qué personas suyas hacen falta, con qué dedicación y con qué rapidez hay que tomar las decisiones.
8. Entornos y licencias. Quién aporta los sistemas, las herramientas y los accesos, y para cuándo.
9. Ubicación e idioma. Dónde trabaja el equipo, la combinación de trabajo local y remoto, los viajes y los idiomas de los documentos y la formación.
10. Formación y hypercare. El modelo de formación, el número de formadores formados, y la duración y los criterios de salida del hypercare.

La línea base WRICEF es lo que más importa para el presupuesto. El propio material formativo de SAP describe la fase Explore como un análisis de fit-to-standard, en el que los requisitos delta aprobados se añaden al backlog del producto para la fase Realize (SAP Learning). Cada delta aprobado puede convertirse en nuevo esfuerzo WRICEF, así que necesita el recuento inicial para medir el crecimiento.

Tipos de exclusiones que hay que dejar por escrito

Las exclusiones deben nombrar quién hace el trabajo en su lugar. «Excluido» sin responsable es un hueco que espera a descubrirse durante el cutover.

Estas son las categorías habituales:

1. Depuración y enriquecimiento de datos en los sistemas heredados, a menudo una tarea del cliente.
2. Cambios en sistemas de terceros y heredados al otro lado de una interfaz.
3. Licencias de software y suscripciones, que están en su contrato con SAP, no en la SOW.
4. Infraestructura y alojamiento, salvo que el socio los gestione de forma explícita.
5. Impartición de la formación a usuarios finales, cuando el socio solo forma a sus formadores.
6. Gestión del cambio organizativo más allá de lo que se enumera.
7. Diseño de seguridad, roles y autorizaciones, si es responsabilidad de otra parte.
8. Pruebas de rendimiento, de penetración y de regresión fuera de los ciclos nombrados.
9. Países, entidades o localizaciones que no están en el alcance organizativo.
10. Soporte de aplicaciones posterior al hypercare, que es un contrato aparte.

Lea las dos listas en paralelo con su director del programa. Todo lo que no aparezca en ninguna de las dos es el lugar del que vendrá una solicitud de cambio.

El modelo comercial que recomiendo para una implementación de SAP es tiempo y materiales, con el esfuerzo cuantificado. Eso significa que el esfuerzo estimado por fase y por rol se escribe en el contrato, para que pueda comparar cada mes el esfuerzo real con esa cifra.

El precio cerrado parece más seguro ante un consejo. En la práctica, el precio solo es cerrado mientras se cumplen todos los supuestos, y un programa de SAP pone a prueba la mayoría de ellos antes de que termine Explore. Mis notas sobre el costo de una implementación de SAP explican cuándo una fase a precio cerrado todavía puede tener sentido.

Así se comparan los dos modelos en la SOW:

Punto de comparación	Precio cerrado	Tiempo y materiales con esfuerzo cuantificado
Qué fija el contrato	El precio, mientras se cumplen los supuestos	Las tarifas, y el esfuerzo estimado por fase y por rol
Dónde está el riesgo	El socio lo incluye en el precio como contingencia	En usted, pero visible cada mes
Cuando el alcance se mueve	Cada cambio se convierte en una negociación	El esfuerzo se mueve, y usted lo ve frente a la estimación
Qué puede controlar	Hitos y solicitudes de cambio	Esfuerzo real frente al plan, por fase y por rol
Qué le protege	Supuestos y exclusiones precisos	Supuestos, exclusiones e informes de esfuerzo precisos

El esfuerzo cuantificado convierte tiempo y materiales de un cheque en blanco en un presupuesto controlado. Pida la estimación como una tabla de fases por roles, en días-persona, y haga que el informe mensual frente a esa tabla sea una obligación contractual.

No deje que las tarifas se escondan en el esfuerzo. Compare la combinación de roles con las tarifas de mercado usando mi guía de planificación de la asignación de recursos en proyectos SAP.

Un plan con muchos días sénior al principio y días júnior después es habitual. Lo contrario necesita una explicación.

Un entregable es un resultado con nombre y una definición de terminado. «Apoyo al diseño» no es un entregable. Un documento de diseño de la solución firmado para el proceso de registro a informe (record to report), revisado frente a criterios acordados, sí lo es.

Vincule la aceptación a las puertas de calidad

SAP Activate se desarrolla en seis fases: Discover, Prepare, Explore, Realize, Deploy y Run. SAP describe puertas de calidad formales después de cada fase, que comprueban que los entregables de la fase están completos antes de que el proyecto avance (SAP Learning).

Use esas puertas en la SOW. Enumere los entregables previstos en cada puerta, los criterios de aceptación y el número de días que tiene para revisarlos. Vincule el pago a los entregables aceptados, no al calendario.

Alguien de su lado tiene que poder juzgar esos documentos. Es uno de los tres momentos en los que recomiendo incorporar a un consultor independiente: durante la contratación, para el diseño y para evaluar los entregables del socio. Mi artículo sobre socio de SAP o consultor independiente explica cómo trabajan juntas las dos funciones.

Nombre a las personas, y compruébelas

Una calidad baja en los recursos propuestos es una de las dos cosas que me hacen descartar una oferta. La otra es un socio que no sabe explicar la arquitectura y el plan.

La SOW debe nombrar al arquitecto de soluciones, al director del programa y a cada responsable funcional y técnico. Incluya su dedicación, su derecho a entrevistar a los sustitutos y su aprobación para cada sustitución. El caso práctico sobre la negociación de contratos de ERP muestra la cláusula de recursos nombrados en la práctica.

Compruebe las certificaciones en lugar de fiarse del currículo. SAP emite los distintivos de certificación a través de Credly, que permite la verificación en tiempo real (SAP Learning). Según el proceso de mantenimiento de la certificación de SAP, una certificación caduca si su titular no realiza la evaluación obligatoria (SAP Learning).

Esta cláusula importa más de lo que parece. He cambiado de socio en mitad de un programa, y el desencadenante fue que el socio no podía aportar recursos de calidad. Mi guía para cambiar de socio de SAP a mitad del proyecto explica qué asegurar antes de llegar a ese punto.

El control de cambios es donde una SOW escasa sale cara. Si los supuestos son vagos, casi cualquier cosa puede presentarse como un cambio.

Una sección de control de cambios que funcione necesita estos elementos:

1. Un desencadenante. Un cambio solo existe cuando falla un supuesto, una exclusión pasa a estar dentro del alcance o usted pide algo nuevo.
2. Una evaluación de impacto. Alcance, esfuerzo por rol, plazo y costo, por escrito, antes de empezar el trabajo.
3. Una tabla de tarifas. Los cambios se cotizan a las tarifas del contrato, sin recargo por urgencia salvo acuerdo.
4. Un nivel de aprobación. Quién de su lado puede aprobar cambios hasta qué importe, con el CFO por encima de un umbral fijado.
5. Un registro. Cada cambio, aprobado o rechazado, se comunica al comité directivo con el total acumulado.
6. Un vínculo con la línea base. Los nuevos objetos WRICEF se miden frente al recuento de los supuestos.

El socio presentará cambios legítimos. Los programas de SAP descubren cosas que nadie sabía al firmar el contrato. El objetivo es que cada cambio sea visible, esté cotizado y esté aprobado antes de que nadie gaste el dinero.

En los 21 programas de SAP que he dirigido o rescatado, el mayor error que veo es no planificar bien desde el principio. La SOW es donde esa planificación se vuelve vinculante, y el tiempo que se le dedica es barato al lado de las solicitudes de cambio en disputa.

El siguiente paso concreto: tome la SOW que tiene delante y enumere cada supuesto y cada exclusión en una sola página. Junto a cada uno, escriba qué ocurre si resulta erróneo y quién paga. Si no puede rellenar esa columna, la SOW no está lista para firmar.

Si quiere una lectura independiente de una declaración de trabajo de SAP antes de la firma, ayudo a los clientes con esto durante la contratación. Puede contactarme aquí.

¿Qué debe incluir una declaración de trabajo de SAP?

Alcance, supuestos detallados, exclusiones, enfoque y fases, esfuerzo estimado por fase y por rol, entregables con criterios de aceptación, recursos nombrados, responsabilidades del cliente, control de cambios y gobierno. La parte que con más frecuencia queda escasa son los supuestos y las exclusiones, y es la parte que decide el costo final.

¿Qué diferencia hay entre supuestos y exclusiones en una SOW de SAP?

Un supuesto es una condición sobre la que el socio ha cotizado, como el número de sociedades o de objetos WRICEF. Una exclusión es trabajo que el socio no ha cotizado en absoluto, como la depuración de datos heredados. Cada supuesto debe indicar qué ocurre si resulta falso, y cada exclusión debe nombrar quién hace el trabajo en su lugar.

¿Es mejor el precio cerrado o tiempo y materiales para una implementación de SAP?

Recomiendo tiempo y materiales con el esfuerzo cuantificado: el esfuerzo estimado por fase y por rol escrito en el contrato y controlado cada mes. Un precio cerrado solo se sostiene mientras se cumplen todos los supuestos, y un programa de SAP pone a prueba la mayoría de los supuestos durante la fase Explore.

¿Cómo se definen los criterios de aceptación de los entregables de SAP?

Nombre cada entregable, describa cómo es cuando está completo y fije un plazo de revisión para su equipo. Vincúlelos a las puertas de calidad de SAP Activate al final de cada fase, y libere el pago solo cuando el entregable esté aceptado.

¿Debe la SOW de SAP nombrar a los consultores?

Sí, para los roles clave: arquitecto de soluciones, director del programa y los responsables funcionales y técnicos. Añada su dedicación, su derecho a entrevistar a los sustitutos y su aprobación para cualquier sustitución. Verifique las certificaciones mediante los distintivos de SAP en Credly en lugar de fiarse del currículo.

¿Quién debe redactar la declaración de trabajo de SAP?

El socio la redacta, pero el alcance y los supuestos deben venir de usted. Redacte su alcance antes de salir al mercado, y haga que alguien independiente del socio revise los supuestos, las exclusiones y los entregables antes de la firma.