¿Cuándo contratar consultoría SAP BTP externa (y cuándo no)?

Cada CIO que gestiona SAP BTP llega, tarde o temprano, al mismo cruce: un proyecto se ha estancado, el equipo interno no ha tocado nunca ese servicio concreto de la plataforma, y alguien en el comité pregunta si hace falta traer consultoría externa. La pregunta que de verdad importa no es “¿necesitamos ayuda?” — casi siempre la respuesta es sí, en algún punto. La pregunta es cuándo, para qué exactamente, y durante cuánto tiempo, porque contratar consultoría SAP BTP demasiado pronto cuesta presupuesto que no hacía falta gastar, y contratarla demasiado tarde cuesta un proyecto parado o, peor, uno que sigue avanzando sobre una base mal construida.

El marco de decisión: tres preguntas antes de firmar nada

Antes de pedir propuestas, conviene responder tres preguntas internamente. No son preguntas técnicas, son preguntas de alcance y de tiempo.

¿Es un problema de capacidad o de conocimiento? Si el equipo interno sabe cómo hacerlo pero no tiene horas, la solución es más horas (internas o subcontratadas de ejecución), no necesariamente consultoría senior. Si el equipo no ha operado nunca ese servicio concreto de BTP en producción — Integration Suite bajo carga real, FinOps de consumo, una migración de Cloud Foundry a Kyma — el problema es de conocimiento, y ahí sí hace falta criterio senior, no solo manos.

¿Es una decisión que se toma una vez, o una que se repite? Una migración puntual, una arquitectura de integración que se diseña una sola vez, un plan de gobernanza de consumo que se define y luego se ejecuta internamente: eso es candidato natural a un contrato acotado con un partner externo. Si en cambio es una competencia que el equipo va a necesitar todos los meses — dar soporte a integraciones nuevas, ajustar el consumo cada trimestre — la pregunta real no es a quién contratar, es a quién contratar y en paralelo formar, porque pagar consultoría externa de forma indefinida para algo recurrente sale más caro que construir la competencia adentro.

¿Qué pasa si esto sale mal? No toda decisión BTP pesa igual. Una automatización interna que falla se repara. Una arquitectura de FinOps mal diseñada, o una integración mal planteada entre S/4HANA y un sistema financiero externo, puede costar meses de retrabajo o, peor, quedar mal calculada durante un año entero de facturación de consumo antes de que alguien la revise. Cuanto más caro es el error y más difícil de revertir, menos margen hay para aprender sobre la marcha con el equipo interno, y más sentido tiene pagar por criterio ya probado.

Estas tres preguntas no sustituyen un análisis caso por caso, pero descartan rápido el error más común: pagar por consultoría SAP BTP genérica para un problema que en realidad es de capacidad, o intentar resolver con horas internas un problema que en realidad exige criterio nunca probado en producción.

Las señales reales de que necesitas ayuda externa senior

Más allá del marco general, hay señales concretas que, en la práctica, indican que vale la pena traer un partner externo especializado en SAP BTP:

El proyecto toca finanzas o cumplimiento, y nadie en el equipo lo ha certificado nunca en producción. Una integración de Integration Suite mal configurada que mueve datos financieros incorrectos, o un flujo de aprobación mal diseñado en Workflow que salta un control de cumplimiento, no se descubre en pruebas — se descubre en auditoría, meses después. Cuando el radio de error toca finanzas o cumplimiento regulatorio, la experiencia previa deja de ser un lujo.

El consumo de BTP ya sorprendió a alguien en la factura, más de una vez. El modelo de precios por consumo de BTP es fácil de subestimar en el diseño y caro de corregir después de construido. Si ya hubo una sorpresa de facturación este año, es una señal de que falta criterio de FinOps específico de la plataforma, no solo disciplina de monitoreo.

Es una migración puntual que no se va a repetir en dos o tres años. Mover Cloud Foundry a Kyma, o consolidar subcuentas antes de una reorganización, es trabajo que se hace una vez y no vuelve a hacer falta. Construir esa competencia adentro para usarla una sola vez no amortiza; contratarla para ese proyecto concreto, con alcance cerrado, sí.

El proyecto es greenfield y no hay ningún precedente interno en esa parte de BTP. La primera integración real sobre Integration Suite, o la primera app CAP que sale a producción, no tiene contra qué compararse dentro de la casa. Sin un caso interno previo de referencia, cada decisión de diseño se toma sobre supuestos, no sobre experiencia, y ahí un partner que ya lo ha visto fallar en otro cliente vale más que cualquier documentación oficial.

Hay una fecha límite regulatoria o contractual fija. Cuando el plazo no lo pone el equipo sino un auditor o un cliente, no hay margen para que alguien aprenda BTP sobre la marcha en ese proyecto concreto. La curva de aprendizaje del equipo interno es una inversión legítima, pero no en el mismo proyecto que tiene una fecha que no se puede mover.

Qué preguntarle a un partner antes de firmar

Antes de firmar cualquier propuesta, hay cuatro preguntas que separan un partner senior de uno que solo dice “hacemos BTP”:

• Experiencia real en producción con los servicios exactos que vas a tocar. No “hacemos BTP” en general, sino ese servicio concreto — Integration Suite bajo carga real, FinOps de consumo, una migración de Cloud Foundry a Kyma — con proyectos que se puedan nombrar, aunque sea de forma anonimizada.
• Alcance cerrado, no abierto. Un contrato que define qué termina el proyecto y cuándo, no una bolsa de horas que se puede estirar indefinidamente. El alcance abierto es la señal más común de que el partner no tiene claro el problema, o prefiere no tenerlo claro.
• Transferencia de conocimiento documentada, no informal. Que la documentación y el criterio de diseño queden en la casa, por escrito, como entregable — no solo en la cabeza del consultor que se va al terminar el contrato. Sin esto, la consultoría puntual se convierte en dependencia permanente.
• Referencias verificables de proyectos de tamaño y sector comparable. No un logotipo en una slide, sino un contacto real al que se pueda llamar y que haya vivido un proyecto de escala parecida, en un sector con las mismas restricciones (regulación, volumen, criticidad).

Cuándo NO conviene contratar consultoría externa

Para cumplir la pregunta del título hasta el final: no todo caso justifica traer un partner. Si el problema es acotado, no se va a repetir el mes que viene, y el radio de error es bajo — una extensión Clean Core puntual, un primer contacto con el modelo de extensibilidad de S/4HANA Cloud, una duda de arquitectura que no compromete nada en producción todavía — la alternativa de bajo costo suele ser suficiente: el curso S/4HANA Cloud: Modelo de extensibilidad Clean Core o el libro S/4HANA: Extensibilidad con Clean Core cubren ese terreno con criterio aplicado, no solo teoría, y cuestan una fracción de un contrato de consultoría.

La diferencia con las señales de la sección anterior no es el tema (BTP en ambos casos), es el radio de error y la recurrencia. Formar al equipo tiene sentido cuando el problema se va a repetir y el coste de un error inicial es bajo. Contratar tiene sentido cuando no se va a repetir, o cuando un error sale caro de deshacer. Confundir los dos casos es la forma más común de gastar de más o de gastar de menos.

La decisión, en una frase

Contratar consultoría SAP BTP externa no es una apuesta de todo o nada: es un cálculo concreto entre lo que cuesta el error si algo sale mal y lo que cuesta formar al equipo para que no vuelva a pasar. Cuando ese cálculo pesa hacia el error caro y no recurrente, conviene hablar con alguien que ya lo haya resuelto antes — nuestro equipo de consultoría lo ha hecho, entre otros casos, en un monitor de consumo y costes de BTP para anticipar exactamente el tipo de sorpresa de facturación descrito arriba.