La puesta en marcha de SAP Business One se firma un día, pero se paga en el primer cierre de mes. Si la empresa acepta el paso a producción sin haber probado sus procesos de punta a punta, con sus propios datos, los errores no desaparecen: se trasladan al equipo de finanzas, a bodega y a la primera conversación difícil con un cliente. Esta nota es una lista de lo que conviene revisar antes de decir que sí.
Por qué la firma de la puesta en marcha pesa tanto
En casi todo proyecto ERP hay un momento en que el calendario aprieta. El partner tiene la fecha comprometida, el equipo interno está cansado y la sensación general es que «lo que falte se ajusta en producción». Esa frase es razonable para detalles menores. Es peligrosa cuando lo que falta es probar un proceso completo.
SAP lo dice en su propia metodología. En SAP Activate, la fase de construcción y pruebas (Realize) incluye «una prueba de integración completa y una prueba de aceptación del usuario» antes de pasar a la fase de despliegue (Deploy). No es un trámite: es la condición para avanzar. Cuando esa prueba se acorta o se reemplaza por una demostración, la empresa firma algo que no vio funcionar.
Lo vimos de cerca en un proyecto al que nos llamaron cuando faltaban pocos días para partir. La empresa tenía un sistema de bodega (WMS) desarrollado a medida, recién terminado e integrado con SAP Business One. Las pruebas integrales no se habían hecho y el equipo daba por cierto todo lo que se declaraba como listo. Lo primero fue exigir una prueba real: completa, con carga de datos de verdad, con los usuarios trabajando al mismo tiempo y con un volumen de transacciones parecido al de un día normal. No la prueba conveniente que se suele hacer. La fecha se movió respecto del plan original, y en esa prueba aparecieron los errores que de otra forma habrían salido en producción. La empresa partió después, partió bien y hoy opera estable, con el mismo implementador. Sin esa prueba, la puesta en marcha no habría resistido.
Qué revisar antes de aceptar
1. Procesos de punta a punta, no pantallas sueltas
Ver que la orden de venta se graba no prueba nada. Lo que hay que ver es el recorrido completo: cotización, orden, entrega, factura electrónica aceptada, cobro y su efecto en la contabilidad. Lo mismo en compras: solicitud, orden, recepción, factura del proveedor y pago. Si una etapa del recorrido no se probó, el proceso no está probado.
2. Con datos reales de la empresa
Los datos de demostración siempre funcionan. Los tuyos tienen artículos con unidades de medida distintas, clientes con condiciones especiales, listas de precios que se cruzan y bodegas que no se comportan igual. La prueba de aceptación tiene que correr sobre una copia con tus maestros cargados, no sobre la base de ejemplo.
3. Los casos que fallan, no solo los que funcionan
Un acta de aceptación firmada con los casos que funcionan es un documento incompleto. Conviene preparar a propósito los casos difíciles: una nota de crédito sobre una factura parcialmente pagada, una devolución de mercadería con lote, una compra en moneda extranjera, un documento rechazado por el SII. Si nadie los probó, alguien los va a descubrir en producción.
4. Saldos iniciales cuadrados contra la contabilidad
Antes de partir, los saldos de clientes, proveedores, inventario y cuentas contables cargados en SAP Business One tienen que cuadrar contra los estados financieros del sistema anterior a la fecha de corte. Cuadrar después es posible, pero cuesta el doble y mezcla errores de carga con errores de operación.
5. Informes que la gerencia va a pedir el primer mes
El primer informe de ventas, el primer cierre y el primer reporte de inventario valorizado son la prueba más visible del proyecto. Pide verlos generados en la base de prueba, con datos reales, antes de la puesta en marcha. Si el informe que la gerencia usa todos los meses no existe todavía, no está listo.
6. Usuarios capacitados en su propio trabajo
No basta con que el equipo haya asistido a la capacitación. Cada usuario clave tiene que haber hecho su trabajo diario en la base de prueba, sin ayuda del consultor. Si todavía pregunta dónde se hace algo básico, el riesgo se traslada al soporte de las primeras semanas.
7. Un plan de corte y un plan de vuelta atrás
La puesta en marcha necesita una fecha de corte, una lista de qué se carga y en qué orden, quién valida cada carga y qué pasa si algo falla. También necesita una respuesta escrita a una pregunta incómoda: si el primer día no funciona la facturación, ¿qué hace la empresa?
8. Pendientes escritos, con responsable y fecha
Siempre quedan pendientes. Lo que no puede quedar es la lista en la memoria de alguien. Cada pendiente tiene que estar escrito en el acta, con su responsable, su fecha y si bloquea o no la operación. Y conviene no cerrar formalmente el proyecto mientras esa lista siga abierta. En otro proyecto que acompañamos, la puesta en marcha fue hace casi un año y todavía quedan pendientes por resolver: cerrar el proyecto antes de tiempo es entregar la única palanca que la empresa tiene para que se terminen.
Tres señales de que conviene esperar
Hay situaciones en que la mejor decisión es mover la fecha unos días. La primera: el acta de pruebas solo registra casos exitosos y ninguno rechazado. La segunda: los saldos iniciales todavía tienen diferencias «por explicar» contra la contabilidad del sistema anterior. La tercera: los usuarios clave no han trabajado solos en la base de prueba y siguen dependiendo del consultor para tareas básicas. Cualquiera de las tres, por separado, ya justifica preguntar qué se gana partiendo igual.
Mover una fecha tiene un costo visible: el plan se reordena y alguien tiene que explicarlo. Partir sin estar listo tiene un costo menos visible y mucho mayor: semanas de correcciones en producción, cierres que se atrasan y un equipo que pierde la confianza en el sistema antes de aprender a usarlo.
Quién revisa, y para quién
Hay un punto que suele pasar inadvertido. Quien construyó la solución es también quien prepara las pruebas y quien declara que todo está listo. No es mala fe; simplemente sus incentivos están puestos en cerrar la etapa dentro del plazo comprometido. La empresa necesita a alguien que revise con criterio propio si lo que se va a firmar está realmente probado.
Eso es el Control de Calidad en un proyecto SAP Business One: revisar los casos de prueba, exigir los recorridos completos con datos reales, verificar los saldos y dejar por escrito qué está listo y qué no, antes de la firma. No reemplaza al partner implementador: le da a la empresa una segunda lectura independiente.
La pregunta antes de firmar
Antes de aceptar la puesta en marcha, conviene hacerse una sola pregunta: ¿vi funcionar con mis datos cada proceso que mi empresa va a usar el lunes? Si la respuesta es no, la firma puede esperar unos días. El primer cierre de mes no.
Porque la puesta en marcha se firma un día, pero se paga en el primer cierre de mes.
Si esto te está pasando en tu empresa, así lo abordamos nosotros: control de calidad en proyectos SAP Business One.
