SAP Business One

Un sandbox de 5 usuarios valida integraciones, desarrollo a medida y costos de nube antes del go-live, reduciendo riesgos y sobrecostos hasta en un 50 %.

Historia de guerra — “Llámanos al final”

A todo vendedor le encanta un comprador motivado.
Dave, dueño de GVC Manufacturing, me llamó para pedir una “cotización competitiva de SAP B1”.
25 usuarios perpetuos, HANA, manufactura make-to-order ligera, nube del partner — todo ya especificado por un reseller “de al lado”.

“Necesitamos el mejor precio por 25 licencias upfront.”

Le hice una sola pregunta:
¿Por qué comprar todos los usuarios antes de haber definido completamente los requerimientos?

¿Por qué importa esto?
Porque los nuevos procesos aún no están configurados. Todas las suposiciones sobre licencias están ancladas a flujos antiguos, no integrados, que se rediseñarán durante requerimientos y UAT. Tratar de calcular el número exacto de usuarios antes de eso es como buscar una aguja en un pajar… con los ojos vendados.

Cuando le expliqué el flujo real del proyecto —
Requerimientos Funcionales → Configuración → Pruebas de Aceptación de Usuario (UAT) —
Dave vio el problema con claridad: comprar todas las licencias antes del UAT casi garantiza una mezcla incorrecta y pagos de hosting por usuarios ociosos.

Punto crítico: una simple hoja de trabajo le mostró que no estaba cambiando volumen por descuento, sino volumen por más riesgo y mayor quema de caja.
En la práctica, estaba pagando más por asumir más riesgo. Una señal clara de mala asesoría.

El giro

Vendimos solo cinco licencias genéricas.
¿Nube? Una instancia multi-tenant pequeña, barata mientras no es productiva.
Se completan requerimientos, se ejecuta UAT y después se definen los tipos exactos de licencias.

Giro inesperado: COVID

Semanas después, California cerró por completo.
Como GVC había reducido el riesgo, pausamos el proyecto, apagamos la nube y conservamos capital.
Sin costos hundidos forzando malas decisiones.

Lección: reduce el riesgo primero. Compra solo lo que puedes monetizar hoy — nada más.

GVC preservó:

• +USD 40k en CAPEX de licencias evitado
• USD 8k en mantenimiento no utilizado
• ~USD 30k en asientos de nube del partner que habrían quedado ociosos

Un colchón de USD 78k, justo cuando inició la pandemia.

Hook (resumen corto)

Un sandbox de 5 usuarios convierte requerimientos y UAT en hechos medibles antes de firmar el SOW.
Dos semanas. Todo real.

1 • ¿Qué es un Sandbox Pilot?

Una instancia acotada en tiempo, clon de producción — normalmente con 5 usuarios nominales — que ejecuta:

• Tu versión exacta de SAP B1 y parches
• Extensión base opcional (ej. Boyum UP) si se requiere para navegación mínima
• Subconjunto real de datos maestros (top 50 clientes, 20 SKUs, matriz de proveedores)
• Plataforma de hosting objetivo (nube del partner o VM on-prem)

Objetivo: validar integraciones, desempeño y flujo de usuario sin impactar producción.

2 • ¿Por qué 5 usuarios?

El número depende de cuántas personas necesitan acceso simultáneo durante las pruebas.
Cinco es un punto de partida práctico: suficientes para avanzar, pocos para limitar el capital en riesgo.

La clave es tratarlos como licencias genéricas hasta que el UAT confirme quién necesita qué.

Ejemplo eficiente en costos:

• 2 Professional
  • Una fija para el consultor
  • Una rota entre usuarios avanzados
• 3 Limited
  • Una de cada tipo (Logística, Finanzas, CRM)

Scott usa la de Logística en la mañana para Compras; Ted usa la misma después para Inventarios.

Si se forman cuellos de botella, se agrega otra licencia.
El objetivo es máxima cobertura con mínima exposición.

Cinco usuarios clave recorren ~80 % de los flujos transaccionales: suficiente para detectar fricciones sin ahogarse en datos.

3 • Por qué el Sandbox es clave

Le llamamos sandbox, pero en realidad es tu preproducción:
el prototipo vivo que se convertirá en productivo cuando pase todas las pruebas.

Objetivo: llevar el plan en papel a una ejecución real y correr cada proceso de punta a punta — pedidos, producción, embarques, reportes, incluso impresión.

• Requerimientos capturan ~80 %
• Pruebas en sandbox descubren otro ~15 %
• Queda ≤ 5 % para ajustes post go-live

¿Por qué no buscar el 100 %?
Porque la perfección rompe tiempos y presupuesto. El sandbox permite corregir lo crítico cuando es barato y mover lo fino a mejora continua: revisiones a 1, 3 y 6 meses.

Las empresas evolucionan. Tu configuración también debe hacerlo.
El sandbox es el primer checkpoint, no el último.

4 • Modelo de SOW por fases — compromiso compartido, caja controlada

Los proyectos ERP grandes fallan cuando una parte se sobrecompromete y la otra persigue 100 % de utilización.
Dividimos el trabajo en fases lógicas que alinean alcance, efectivo y responsabilidad.

Requerimientos & Sandbox Pilot

Cliente

• Compra solo 5 licencias genéricas
• Provisiona 5 asientos hospedados
• Financia workshops y construcción del sandbox
• Entrega subset de datos maestros y usuarios clave

Partner

• Asigna BA y líder técnico
• Levanta sandbox, enmascara datos, instala herramientas base
• Entrega especificación funcional + reporte del piloto
• Reserva recursos para la siguiente fase (derecho de primera opción)

Sprint de Implementación

Cliente

• Firma SOW al aprobar la especificación
• Compromete SMEs para configuración y UAT
• Libera horas en tramos (ej. bloques de 100 hrs) solo tras checkpoints
• Compra solo las licencias probadas en el sandbox

Partner

• Configura módulos, migra datos, instala add-ons
• Facilita UAT con registro de pass/fail
• Reporte semanal de burn rate
• Actualiza matriz de licencias y costos de nube

Go-Live & Estabilización

Cliente

• Aprueba checklist de corte
• Proporciona acceso de fin de semana y equipo de soporte

Partner

• Ejecuta el cutover
• 30 días de hypercare
• Pausa facturación si hay desvíos; replanea en conjunto

Movimiento experto — incentivo por desempeño

En lugar de pelear descuentos upfront que sobrecomprometen al cliente, se integra un rebate por desempeño:
si el partner falla un hito acordado, un porcentaje del tramo se devuelve o se acredita.

Esto cambia la conversación de “hazlo barato” a “hazlo bien”.

Los hitos no son subjetivos:
o el entregable cumple la especificación funcional (pasa) o no (falla).
Si hay disputa, el trabajo se detiene y el efectivo deja de fluir hasta resolverlo.

Ventas y entrega quedan alineadas: el siguiente SOW solo se cierra cuando el anterior demuestra valor.

5 • Calendario típico del piloto (30 días)

(Ajustable entre on-site y remoto)

• Días 1–2: kickoff, provisionamiento del sandbox
• Semana 1: carga de BD enmascarada, add-ons, SSO
• Semana 2: walkthroughs con Finanzas, Ventas, Almacén, Producción
• Semana 3: pruebas de carga, MRP, latencia
• Semana 4: correcciones, validación de reportes e impresión
• Días 25–26: demo ejecutiva y firma funcional
• Días 27–30: matriz final de licencias, modelo de costos, SOW siguiente fase

Nota: si el equipo tiene poco tiempo, se extienden walkthroughs.
El sandbox sigue activo y las licencias permanecen genéricas hasta que UAT confirme el mix.

6 • Llamado a la acción

¿Listo para medir antes de cortar?

Agenda una llamada de scoping de 20 minutos.
Te llevas un checklist de sandbox y una cotización clara — sin costo.

Benjamin Carter
Especialista en rescate de proyectos SAP B1 huérfanos.
Enemigo declarado del scope creep.