Cómo cambiar de socio de implementación de SAP a mitad del proyecto

Para cambiar de socio de implementación de SAP a mitad del proyecto, confirme primero que el problema es el socio y después asegure todos los documentos, diseños, piezas de código y accesos a los sistemas antes de decírselo. Solo entonces seleccione al sustituto y dirija un traspaso planificado con un periodo de solapamiento.

Respuesta corta: cambie cuando el socio no pueda darle personas de calidad y no sea capaz de corregirlo. No cambie para escapar de problemas que están de su lado, porque un socio nuevo los hereda.

Este artículo forma parte de mi guía sobre cómo elegir un socio de implementación de SAP. Esa guía trata la elección del socio al principio. Esta trata qué hacer cuando el socio que eligió no está funcionando.

He cambiado de socio en mitad de un programa. El desencadenante fue la calidad de los recursos: el socio no podía aportar personas de calidad cuando el programa las necesitaba.

Esa es la señal que pondría en primer lugar. Un programa puede recuperarse de una mala fase, de una fecha incumplida o de un diseño débil. Le cuesta recuperarse de un socio que no puede poner a personas capaces en el trabajo.

Estas son las señales que justifican actuar, más o menos en el orden en que yo las pondero:

1. Baja calidad de las personas en el proyecto. Los consultores que hacen el trabajo no son las personas que le presentaron, o no saben responder a preguntas básicas sobre su propia área.
2. Incapacidad repetida para sustituir a personas. Alguien se va y el sustituto tarda semanas en llegar, o llega con menos experiencia.
3. Nadie sabe explicar la arquitectura y el plan. Pida al responsable del socio que le explique el diseño objetivo y el camino hasta el go-live. Si no puede, nadie está dirigiendo la entrega.
4. Entregables que no resisten una revisión. Diseños, guiones de prueba y documentos de construcción escasos, copiados de otro cliente o inexistentes.
5. Respuestas genéricas a problemas concretos. La misma señal de alarma que en la selección: respuestas que podrían aplicarse a cualquier empresa.

Una fase retrasada, un desvío en Explore o un comité directivo tenso no son, por sí solos, motivos para cambiar.

Antes de sustituir a nadie, averigüe si el socio es realmente la causa. Mi guía sobre la recuperación de programas SAP expone las tres comprobaciones que hago primero: el estado del programa, el diseño y lo que realmente está desplegado en el sistema.

Ese diagnóstico a menudo muestra que el problema es compartido. Los presupuestos se resienten en Explore a medida que crece la lista WRICEF (flujos de trabajo, informes, interfaces, conversiones, ampliaciones y formularios). Si dejó que el socio controlara el alcance, o si sus usuarios clave nunca se liberaron para el programa, un socio nuevo cae en el mismo agujero.

Así que hágase dos preguntas con honestidad:

1. ¿Lo resolvería un equipo sólido de este socio? Si la respuesta es sí, y el socio puede aportar ese equipo con rapidez, un cambio de personas puede bastar.
2. ¿Se enfrentaría un socio distinto a los mismos problemas? Si la respuesta es sí, corrija primero el alcance, las decisiones y el gobierno de su lado.

Si la respuesta a la primera pregunta es no, porque el socio no encuentra a las personas, ya tiene su respuesta. La disponibilidad de personas de calidad no se arregla con una modificación del contrato.

Esta es la parte en la que la mayoría de los clientes se equivoca. Anuncian la decisión, y su poder de negociación desaparece con ella.

El socio saliente tiene el conocimiento que usted necesita para sustituirlo. Hasta que ese conocimiento esté en sus manos, mantenga la decisión dentro de un grupo reducido: el patrocinador, el CFO, el director del programa y su responsable jurídico o de compras.

Empiece por su contrato actual. Lea la cláusula de resolución, el plazo de preaviso, la propiedad de los entregables y todo lo relativo a la transferencia de conocimiento o a la asistencia en la salida. Si su declaración de trabajo no dice nada sobre la salida, mi artículo sobre qué debe contener una declaración de trabajo de SAP explica qué incluir en la siguiente.

Esto es lo que debe asegurar, y dónde suele estar:

Qué asegurar	Por qué importa	Dónde debería estar	Cómo protegerlo
Diseños y decisiones firmados	El socio nuevo construye sobre ellos en lugar de empezar de cero	Su repositorio de documentos o SAP Cloud ALM	Copie ahora las últimas versiones aprobadas, con los registros de aprobación
Lista WRICEF y especificaciones	La línea base del alcance y el backlog de construcción	SAP Cloud ALM o su propio repositorio	Exporte la lista con el estado de cada objeto
Código a medida y configuración	El trabajo real hecho hasta ahora	Sus sistemas de desarrollo y de pruebas	Confirme que todo está en sus sistemas, no en equipos del socio
Guiones y resultados de pruebas	Evidencia de lo que realmente funciona	Su herramienta de pruebas o SAP Cloud ALM	Exporte los guiones, los resultados y los defectos abiertos
Trabajo de migración de datos	Mapeos, reglas de depuración, programas de carga	Unidades compartidas y sus sistemas	Recoja del equipo de datos los documentos de mapeo y los programas de carga
Accesos a los sistemas y al soporte de SAP	Control de su entorno de sistemas y de su cuenta de soporte de SAP	Sus sistemas y SAP for Me	Haga una lista de todos los usuarios del socio, lista para darlos de baja ese día
Incidencias y riesgos abiertos	Lo que el siguiente equipo debe retomar primero	Registro RAID e informes de estado	Haga una copia fechada del registro RAID

Guarde el contenido del proyecto en sus propias herramientas

La protección más limpia es estructural. Guarde los documentos, los requisitos y las evidencias de prueba del programa en herramientas que sean suyas, desde el primer día de cualquier programa.

SAP Cloud ALM ayuda en esto. Los clientes con SAP Enterprise Support, o con RISE with SAP, pueden solicitar su propio tenant sin costo adicional, uno por número de cliente, según las preguntas frecuentes de SAP sobre Cloud ALM. Si la documentación del proyecto está en su tenant, se queda con usted cuando un socio se va.

Planifique el cambio de accesos para el día del anuncio

Los consultores del socio suelen tener S-user IDs en su cuenta de soporte de SAP, además de cuentas de usuario en sus sistemas. Sus propios administradores controlan los S-user IDs en SAP for Me.

La ayuda de SAP sobre la gestión de usuarios indica que los administradores del cliente son responsables de eliminar los IDs de los usuarios que se han ido. También indica que los IDs con funciones especiales, como destinatario de software o contacto técnico, no pueden eliminarse hasta que SAP transfiera esa función a otra persona. Averigüe ahora qué usuarios del socio tienen esas funciones y páselas primero a su propia gente.

Una vez asegurado el material y elegido el sustituto, comuníqueselo al socio saliente. Hágalo por escrito, conforme al contrato, y acuerde el plan de salida en la misma reunión.

Un traspaso funciona mejor en este orden:

Cambiar de socio de SAP a mitad del programa

1. 01

   Asegurar

   Documentos, diseños, código, accesos y el registro RAID en sus manos antes de decírselo a nadie.

2. 02

   Seleccionar

   Referencias de proyectos similares y el equipo real en las presentaciones orales, con el esfuerzo cuantificado.

3. 03

   Solapar

   Los responsables saliente y entrante trabajan codo con codo en una transferencia de conocimiento estructurada.

4. 04

   Revalidar

   El socio nuevo revisa diseños, construcción y pruebas frente a lo que está desplegado.

5. 05

   Nueva línea base

   Un único plan nuevo basado en la evidencia, aprobado antes de que empiece la siguiente fase.

Seleccione bien al sustituto

La tentación es correr, porque el programa está quemando dinero mientras usted elige. Una selección completa lleva unas 12 semanas según mi experiencia, con al menos tres socios en la lista corta. Una sustitución bajo presión puede ir más rápido, pero no se salte los pasos que le protegen.

Cuando elijo un socio para un cliente, lo que más peso tiene son las referencias de clientes. En las llamadas a referencias pregunto por la experiencia del socio en proyectos como el del comprador. A mitad del programa, eso significa preguntar a las referencias sobre la asunción de un trabajo que empezó otra empresa.

Hay dos cosas que me hacen descartar una oferta: una calidad baja en los recursos propuestos y un socio que no sabe explicar la arquitectura y el plan. Después de un cambio provocado por la calidad de los recursos, aplique ambas pruebas con más rigor, no con menos.

Pida a los candidatos los distintivos de certificación de las personas que proponen. SAP emite sus distintivos de certificación en Credly, como explica su página de ayuda sobre distintivos digitales. Un distintivo confirma que se aprobó un examen, así que compruebe también la experiencia mediante las referencias.

Mis guías para redactar una RFP de implementación de SAP y sobre los socios de implementación de SAP por niveles cubren el resto de la selección.

Contrate al socio nuevo de otra manera

El modelo comercial que recomiendo es tiempo y materiales, con el esfuerzo cuantificado. El contrato recoge el esfuerzo estimado por fase y por rol, para que pueda comparar cada mes el esfuerzo real con esa cifra.

La declaración de trabajo (SOW) también necesita supuestos y exclusiones detallados. Los clientes suelen omitirlos, y en una asunción de proyecto importan todavía más, porque el socio nuevo querrá excluir los problemas que hereda.

Nombre también a las personas clave en el contrato. Mis notas sobre la negociación de contratos de ERP explican la cláusula de recursos nombrados y por qué evita que las personas sénior desaparezcan después de la firma.

Solape y después revalide

Planifique un periodo en el que los responsables saliente y entrante trabajen juntos. El equipo saliente repasa cada área de diseño, cada defecto abierto y cada objeto a medio construir, mientras el equipo entrante hace preguntas.

Después deje que el socio nuevo revalide lo que existe. Cuente con que encontrará huecos, y con que algunos de esos hallazgos serán una posición negociadora para pedir más esfuerzo. Aquí es donde merece la pena tener una opinión independiente sobre los entregables del socio saliente.

Relacione la asunción con la fase de SAP Activate en la que está. SAP describe seis fases: Discover, Prepare, Explore, Realize, Deploy y Run (SAP Activate).

Un cambio durante Explore cuesta sobre todo retrabajo de diseño. Un cambio durante Realize cuesta además retrabajo de construcción y de pruebas, porque el código hay que entenderlo antes de poder terminarlo.

Ningún cambio sale gratis. No voy a ponerle una cifra, porque depende de la fase, de la calidad de lo entregado y de cuánto coopere el socio saliente.

Estos son los costos que debe presupuestar:

1. Solapamiento. Paga a dos equipos durante el traspaso.
2. Revalidación y retrabajo. El socio nuevo revisa los diseños, la configuración y el código, y parte se rehace.
3. Salida del contrato. Plazos de preaviso, condiciones de resolución y cualquier pago por trabajo en curso, según establezca su contrato.
4. Esfuerzo de selección. El tiempo de su propio equipo dedicado a la RFP, las presentaciones orales y las llamadas a referencias.
5. El tiempo de su gente. Los usuarios clave repiten talleres y pruebas que creían terminados.
6. Retraso. Cada semana de retraso mantiene en marcha durante más tiempo los sistemas antiguos y a su equipo interno.

Compárelos con el costo de quedarse. Un socio que no puede dotar de personal al programa no se abarata a medida que el programa se complica, y Realize, las pruebas y el cutover son más difíciles que lo anterior.

Aconsejo a los clientes incorporar a un consultor independiente en tres momentos: la contratación, el diseño y la evaluación de los documentos y entregables del socio. Un cambio de socio toca los tres a la vez.

Un revisor independiente puede decirle lo que realmente valen los entregables del socio saliente antes de que el socio nuevo cotice el retrabajo. También puede revisar el contrato del socio entrante y su visión del diseño. Mi artículo sobre socio de SAP o consultor independiente explica quién hace qué.

Esta semana, averigüe dónde están realmente sus diseños firmados, su lista WRICEF, sus evidencias de prueba y su código a medida, y quién controla el acceso a cada uno. Hágalo tanto si piensa cambiar como si no. Si algo de eso está solo en manos de su socio, pase una copia a sistemas que sean suyos.

Si está valorando un cambio de socio y quiere una opinión independiente sobre los entregables o el contrato, puede hablar conmigo aquí.

¿Se puede cambiar de socio de implementación de SAP en mitad de un proyecto?

Sí. Revise primero las condiciones de resolución, preaviso y propiedad de los entregables de su contrato. Asegure los diseños, el código, las evidencias de prueba y los accesos a los sistemas antes de anunciar la decisión, y después dirija un traspaso planificado con un periodo de solapamiento.

¿Cuándo hay que cambiar de socio de implementación de SAP?

Cambie cuando el socio no pueda aportar personas de calidad y no sea capaz de corregirlo, o cuando sus responsables no sepan explicar la arquitectura y el plan. No cambie solo porque una fase se haya retrasado. Diagnostique primero, porque los problemas de control del alcance o de sus propias decisiones le seguirán a un socio nuevo.

¿Qué debe obtener de su socio de SAP antes de resolver el contrato?

Los diseños firmados y los registros de decisiones, y la lista WRICEF con el estado de cada objeto. El código a medida y la configuración en sus propios sistemas, los guiones y resultados de pruebas, los mapeos de la migración de datos y el registro RAID. Haga también una lista de todos los usuarios del socio en sus sistemas y en su cuenta de soporte de SAP, para poder retirar los accesos ese mismo día.

¿Cuánto cuesta cambiar de socio de SAP a mitad del proyecto?

No hay una cifra estándar. Presupueste el solapamiento entre los dos equipos, la revalidación y el retrabajo, las condiciones de salida del contrato, su propio esfuerzo de selección y el retraso. Cuanto más avanzada esté la fase, más retrabajo hay, porque el código y las pruebas hay que entenderlos antes de poder terminarlos.

¿Cuánto se tarda en sustituir a un socio de implementación de SAP?

Una selección completa de socio lleva unas 12 semanas según mi experiencia, con al menos tres socios en la lista corta. Una sustitución bajo presión puede ir más rápido, pero mantenga las llamadas a referencias y las presentaciones orales con el equipo real.

¿De quién son los documentos y el código de una implementación de SAP?

Lo decide su contrato, así que revise la cláusula de propiedad de los entregables. En la práctica, protéjase guardando los documentos en su propio repositorio o en su tenant de SAP Cloud ALM, y el código y la configuración en sus propios sistemas SAP y no en servidores del socio.