Una auditoría de SAP Business One es una revisión técnica y funcional de una instalación que ya existe: cómo está configurada, qué datos contiene, qué se desarrolló encima y qué tan bien sostiene la operación diaria. Su resultado es un diagnóstico escrito y un plan de acción. A menudo es también el primer paso para una reanudación de un proyecto de SAP Business One, es decir, retomar un proyecto atascado, o para cambiar de integrador de SAP Business One sin empezar desde cero.
Esta página es para el director general, el director de finanzas o el responsable de sistemas de una pyme mexicana que ya compró SAP Business One y siente que el sistema no cumple lo prometido. Si todavía está eligiendo, le conviene más la página sobre cómo elegir integrador de SAP Business One.
Señales de que su proyecto necesita una auditoría
Un sistema en problemas rara vez falla de golpe. Se degrada, y los síntomas se parecen de una empresa a otra, aunque las causas no.
- El cierre contable se alarga. El contador espera conciliaciones que deberían salir del sistema y las arma en hojas de cálculo.
- Los usuarios trabajan fuera del ERP. Ventas lleva sus propios libros de Excel, almacén cuenta aparte y compras negocia sin ver el inventario real.
- Los CFDI se corrigen a mano. Cancelaciones, complementos de pago o notas de crédito que obligan a intervenir con el PAC, o a rehacer documentos que el sistema debía generar bien.
- Nadie sabe explicar lo que hay. Campos, reportes y complementos que el integrador original creó y que ya nadie entiende.
- El integrador tarda o ya no contesta. Los tickets quedan abiertos, los consultores rotan y cada cambio menor se cotiza como proyecto.
- El sistema es lento. Reportes que tardan, procesos que se traban a ciertas horas o usuarios que se pelean por una sesión.
- Quedó pendiente la versión. El sistema sigue en una versión que SAP ya no mantiene.
Una sola de estas señales no obliga a nada. Varias a la vez justifican detenerse a revisar antes de seguir pagando horas de consultoría.
Qué se examina en una auditoría
Un buen auditor no empieza por criticar: empieza por entender cómo trabaja la empresa y compara eso con lo que el sistema hace. Los frentes habituales son seis.
Parametrización y procesos
Se revisan el plan de cuentas, las dimensiones, los grupos de artículos, las listas de precios, las series de documentos, los flujos de aprobación y los roles. La pregunta de fondo: ¿el sistema refleja la operación actual o la de hace años? Muchas instalaciones conservan decisiones tomadas para un negocio que ya cambió.
Datos maestros y calidad de la información
Clientes duplicados, artículos sin clasificar, proveedores con RFC incompleto, saldos que no concilian. Los datos sucios son la causa más común de que un informe no cuadre, y ningún ajuste de pantalla lo arregla. La auditoría mide el problema y propone un saneamiento ordenado.
Cumplimiento fiscal en México
Es un frente propio. Se verifica cómo se emiten, cancelan y concilian los CFDI con el PAC elegido, cómo se manejan los complementos y cómo se alimenta la contabilidad electrónica que se entrega al SAT. La guía sobre CFDI y ERP explica qué debe poder hacer un sistema en este terreno. Se revisa también la nómina, ya sea dentro de SAP o en un sistema aparte con su interfaz.
Desarrollos a la medida e integraciones
Aquí se esconden los mayores riesgos. El auditor inventaría los complementos, consultas, campos definidos por el usuario y conexiones con tiendas en línea, bancos, sistemas de almacén o de punto de venta. Para cada uno se pregunta: ¿quién lo mantiene, está documentado, existe el código fuente, resistiría una actualización? La página sobre desarrollo a la medida en SAP Business One detalla cómo debería construirse para no volverse una carga.
Rendimiento e infraestructura
Se examina dónde corre el sistema (servidor propio o alojamiento), cómo se respalda, cuánto tarda en procesos pesados y si el hardware o la red son el cuello de botella. Un respaldo que nunca se ha restaurado en una prueba no es un respaldo.
Seguridad y licencias
Se revisan usuarios activos que ya no trabajan en la empresa, permisos excesivos, contraseñas compartidas y el uso correcto de las licencias. Un detalle técnico merece atención: en la versión instalada en servidor propio, SAP crea al instalar un usuario de soporte para que el personal del integrador entre sin consumir licencia; viene bloqueado por defecto, queda registrado en bitácora y la conexión se rechaza si la plataforma de soporte remoto no ha enviado datos en los últimos siete días. Conviene saber si ese usuario está en uso y quién lo controla. La guía de licencias de SAP también autoriza que el usuario «manager» abra dos sesiones de Windows distintas para tareas programadas o para que un consultor se conecte sin licencia, pero no para un uso productivo duplicado; un auditor serio revisa que nadie lo esté usando así.
Versión y mantenimiento
SAP garantiza al menos cinco años de mantenimiento estándar por familia de versiones. Según su página de mantenimiento, la versión 10.0 está en mantenimiento estándar hasta el 31 de diciembre de 2028, con fechas sujetas a cambio, mientras que las versiones 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 y 9.3 ya terminaron su periodo. SAP también aclara que no ofrece mantenimiento extendido y que, al salir una nueva familia, la anterior deja de mantenerse. Desde la versión 10.0, la innovación llega en «feature packages» acumulativos, que incluyen correcciones, parches de seguridad y actualizaciones legales. Para el detalle, consulte versiones y ediciones de SAP Business One.
Tabla de diagnóstico: síntoma, causa probable, acción
| Síntoma | Causa probable | Acción típica |
|---|---|---|
| Reportes que no cuadran con contabilidad | Datos maestros sucios o configuración contable incompleta | Saneamiento de datos y revisión del plan de cuentas |
| CFDI rechazados o corregidos a mano | Mala configuración del timbrado, del complemento o del PAC | Revisar el proceso de emisión y la conexión con el PAC |
| Sistema lento | Servidor, base de datos o consultas mal construidas | Revisión de infraestructura y de desarrollos |
| Nadie entiende los complementos | Falta de documentación y de código fuente | Inventario, documentación o reconstrucción |
| Errores tras actualizar | Desarrollos no probados con la versión nueva | Pruebas de regresión y plan de actualización |
| Integrador que no responde | Contrato sin niveles de servicio claros | Cambio de integrador con traspaso ordenado |
Cambiar de integrador sin empezar de cero
Un cambio de integrador asusta porque se teme perder lo invertido. En realidad, lo que usted posee es su licencia, su base de datos y sus procesos. El integrador es quien los configuró y los atiende, y eso se puede transferir.
Hay una condición: recuperar el control antes de anunciar el cambio. Muchas relaciones se rompen en mal momento porque el cliente discute con el integrador sin tener sus propios accesos.
Documentos y accesos que debe recuperar
- Usuario de administrador de la base de datos y del sistema, con contraseñas en su poder y no en las del consultor.
- Datos de la licencia y del contrato de mantenimiento con SAP, a nombre de su empresa.
- Respaldos recientes, más una prueba de que se pueden restaurar.
- Documentación de la parametrización: plan de cuentas, series, roles, flujos de aprobación.
- Código fuente y documentación de cada complemento o desarrollo a la medida, así como las condiciones de propiedad en el contrato.
- Acceso a los servicios conectados: PAC, banco, tienda en línea, correo y servidores.
- Lista de tareas programadas, interfaces y procesos automáticos.
Si el contrato original no deja claro quién es dueño del código de los desarrollos, aclárelo con asesoría jurídica antes de decidir. Es una decisión comercial y legal que le corresponde a usted, no al nuevo integrador.
Cómo se hace la transición
- Auditoría independiente por el nuevo integrador, con acceso de solo lectura cuando sea posible.
- Decisión por frentes: qué se conserva, qué se corrige y qué se rehace.
- Traspaso ordenado, con un periodo en el que ambos equipos conviven y el saliente responde dudas.
- Cierre de la relación anterior una vez confirmados accesos, respaldos y documentación.
Para más contexto sobre lo que suele fallar, lea los errores más comunes en proyectos ERP.
Plan de recuperación: del diagnóstico a la operación estable
Una auditoría útil no termina en un informe de críticas. Termina en un plan que su equipo pueda ejecutar. Lo habitual es ordenarlo en cuatro etapas.
Estabilizar
Lo primero es cubrir lo que pone en riesgo a la empresa: respaldos verificados, cumplimiento fiscal (CFDI y contabilidad electrónica), usuarios y permisos, y acceso a un soporte que responda. SAP menciona soporte permanente para incidentes de paro del sistema, pero ese canal no sustituye un soporte cotidiano con su integrador; vea cómo debería funcionar en soporte y mantenimiento de SAP Business One.
Corregir
Se atacan los problemas de mayor efecto por menor esfuerzo: saneamiento de datos maestros, ajustes de parametrización, corrección de reportes y retiro de desarrollos que ya no se usan.
Reconstruir donde haga falta
Algunos elementos no se arreglan: un complemento sin código fuente, una integración frágil o un proceso mal diseñado desde el inicio. Se reemplazan por una solución mantenible, con documentación desde el primer día.
Sostener
Se define quién es responsable de qué, cómo se piden los cambios, cuándo se actualiza la versión y cómo se capacita a los usuarios nuevos. Un proyecto rescatado que vuelve a depender de una sola persona vuelve a fallar. Si la subida de versión es parte del plan, recuerde que SAP solo soporta subidas directas entre versiones consecutivas, por ejemplo de la 9.3 a la 10.0; una subida no consecutiva exige varias etapas. Los clientes con contrato de mantenimiento vigente reciben las actualizaciones de versión sin costo adicional, pero SAP no entrega correcciones ni parches de seguridad para feature packages, support packages, patches u hotfixes antiguos.
Cuándo la auditoría concluye que hay que cambiar de ERP
No siempre se rescata. Si el negocio cambió tanto que SAP Business One ya no le sirve, o si el costo de corregir supera lo razonable, la auditoría puede recomendar otra ruta. Entonces conviene revisar las alternativas a SAP Business One y la guía de migración de ERP. Es una conclusión legítima, y es mejor llegar a ella con un diagnóstico que por frustración.
El contexto mexicano
SAP afirma que Business One se usa en más de 170 países y que se distribuye a través de 850 socios, con más de 500 extensiones sectoriales y por país. Para una empresa mexicana, esto significa que existe un ecosistema amplio, pero también que la calidad de un integrador varía mucho. La página sobre SAP Business One en México explica cómo se ve ese mercado local, y cómo funciona nuestro servicio de conexión describe la manera en que presentamos su caso a integradores adecuados.
Somos un servicio gratuito de conexión: no ejecutamos la auditoría ni el rescate, y no estamos afiliados a SAP. Describimos su situación a integradores que tengan experiencia en rescates, y ellos le proponen el alcance.
Preguntas que conviene hacerse antes de empezar
- ¿Qué proceso duele más hoy: facturación, inventario, cierre contable o reportes?
- ¿Sabemos quién tiene las contraseñas de administrador?
- ¿Tenemos un respaldo que se haya restaurado alguna vez en prueba?
- ¿Qué desarrollos a la medida existen y quién los mantiene?
- ¿En qué versión estamos y cuándo termina su mantenimiento?
- ¿Qué parte del contrato con el integrador actual podemos terminar y con qué aviso?
Las respuestas, aunque sean incompletas, ya orientan la conversación con un nuevo integrador y reducen el tiempo de diagnóstico. Si apenas inicia la conversación, la página sobre la implantación de SAP Business One le ayuda a comparar lo que se hizo con lo que debió hacerse.
Preguntas frecuentes
¿Cuándo conviene hacer una auditoría de SAP Business One?
Cuando el cierre contable se alarga, los usuarios exportan a Excel para trabajar, los CFDI se corrigen a mano o el integrador ya no responde. También antes de una actualización de versión o de un cambio de integrador. Una auditoría da un diagnóstico escrito sobre el cual decidir.
¿Puedo cambiar de integrador de SAP Business One sin volver a implantar todo?
Sí, en la mayoría de los casos. La licencia, los datos y buena parte de la parametrización se conservan. Lo que cambia es el equipo que lo mantiene. Lo esencial es recuperar accesos, documentación y código de los desarrollos antes de anunciar la salida.
¿Qué debo exigirle al integrador saliente?
Los accesos de administrador, la documentación de la parametrización y de los desarrollos, el código fuente de los complementos a la medida, los respaldos y los datos de la licencia. Si el contrato no los menciona, conviene negociarlos antes de cerrar la relación.
¿Una versión antigua de SAP Business One es motivo para auditar?
Sí. SAP indica que las versiones 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 y 9.3 terminaron su mantenimiento estándar y que no ofrece mantenimiento extendido. Quien sigue en una de ellas no recibe correcciones ni parches de seguridad, y la auditoría debe planear la subida.
¿La auditoría la hace el mismo integrador que implantó el sistema?
Es preferible que no. Quien implantó el sistema difícilmente cuestiona sus propias decisiones. Un segundo integrador, sin interés en el proyecto original, revisa con más libertad y le da una opinión que usted puede comparar.
Fuentes
- SAP — Mantenimiento de SAP Business One
- SAP — Actualizaciones y parches de SAP Business One
- SAP — Guía de licencias de SAP Business One 10.0
Los nombres de software mencionados son marcas de sus respectivos editores y se citan únicamente a título informativo. Este sitio es independiente y no está afiliado a ningún editor.