Como Especialista de Datos Maestros en Camposol, mi objetivo fue resolver los cuellos de botella y las ineficiencias en el ciclo de vida de los datos de proveedores (Procure-to-Pay). Este proyecto se enfocó en rediseñar el proceso de alta y modificación de proveedores para asegurar la agilidad del negocio y la integridad de los datos financieros.
Parte 1: Rediseño del Gobierno y Flujos de Aprobación de Proveedores
- El Reto: La compañía gestionaba un alto volumen de solicitudes de creación y modificación de proveedores (~25 por semana) a través de un único flujo de trabajo manual y poco definido. Esta falta de gobierno generaba fricciones significativas:
Altas Tasas de Error: Se registraban 57 rechazos semanales por datos incorrectos o incompletos, como RUCs inválidos o números de cuenta bancaria erróneos.
Procesos Lentos: El tiempo promedio para aprobar un nuevo proveedor era de 3.5 días, retrasando compras críticas de insumos para el campo y la producción.
Baja Calidad a la Primera: Solo el 62% de las solicitudes se aprobaban en el primer intento sin necesidad de correcciones.
Impacto Financiero Directo: El área de Finanzas reportaba un promedio de 22 facturas por semana con diferencias, principalmente porque los datos bancarios del proveedor en el sistema no coincidían con los de la factura, causando reprocesos y retrasos en los pagos.
- Mi Solución: Mi estrategia se centró en segmentar, estandarizar y automatizar el proceso de gestión de proveedores.
- Diagnóstico y Categorización de Errores: Analicé las 57 devoluciones semanales y descubrí que el 40% se debían a datos bancarios incorrectos, el 35% a datos fiscales inválidos (RUC) y el 25% a información de contacto incompleta.
- Diseño de 3 Flujos de Aprobación Especializados: Reemplacé el flujo único por tres workflows optimizados en la plantilla de carga, cada uno con sus propios validadores y niveles de servicio (SLAs):
Flujo 1: Proveedores Estratégicos Nacionales/Extranjeros: Un flujo robusto con validaciones automáticas y aprobaciones secuenciales de los departamentos de Compras, Finanzas y Tesorería.
Flujo 2: Proveedores de Servicios y Menores: Un flujo ágil y simplificado para proveedores no críticos, reduciendo el número de aprobadores.
Flujo 3: Modificación de Datos Sensibles: Un flujo de alta seguridad, exclusivamente para actualizar datos bancarios o fiscales, que requería doble autenticación y aprobación para prevenir fraudes.
- Implementación de Validaciones Automáticas: Desarrollé y puse en marcha scripts de pre-validación. Por ejemplo, antes de que una solicitud ingrese al flujo, un script verificaba automáticamente que el RUC tuviera 11 dígitos y comenzara con “10” o “20”, y que el CCI (Código de Cuenta Interbancario) tuviera 20 dígitos.
- El Impacto: La implementación de estos flujos y controles transformó el proceso por completo.
Esta métrica mide la eficiencia y calidad del proceso desde el inicio. Es el porcentaje de solicitudes de alta de proveedores que fueron aprobadas directamente, sin ser rechazadas o devueltas para corrección.
Escenario “Antes” (62% de Aprobación)
El proceso carecía de guías y estándares claros. Los usuarios que solicitaban un nuevo proveedor a menudo cometían errores o dejaban información incompleta.
Universo de Análisis: Tomemos como referencia un volumen mensual de 100 solicitudes de alta de nuevos proveedores (consistente con las ~25 solicitudes/semana mencionadas anteriormente).
Línea Base: De esas 100 solicitudes mensuales, solo 62 eran aprobadas a la primera. Las otras 38 eran devueltas al solicitante por errores, creando un ciclo de reproceso.
Cálculo de la Tasa de Aprobación Inicial:
Escenario “Después” (81% de Aprobación)
La solución fue diseñar e implementar 3 flujos de aprobación especializados (para proveedores críticos, menores y modificaciones), con plantillas claras y validaciones automáticas.
Resultado: Estos nuevos flujos guiaron al usuario para enviar la información correcta desde el principio. En un mes posterior con un volumen similar de 100 solicitudes, 81 de ellas fueron aprobadas sin ninguna objeción.
Cálculo de la Tasa de Aprobación Final:
“Encontramos que casi el 40% de las solicitudes de nuevos proveedores eran rechazadas, lo que creaba una enorme carga de trabajo administrativo. Al reemplazar el proceso único con tres flujos de trabajo guiados y estandarizados, aumentamos la tasa de aprobación al primer intento del 62% al 81%, lo que significa que el proceso se hizo correcto y eficiente desde el inicio.”
Esta métrica mide la agilidad del proceso. Es el tiempo promedio que transcurre desde que se envía una solicitud hasta que el proveedor está 100% activo y listo para usarse en el sistema.
Escenario “Antes” (3.5 Días)
El tiempo de ciclo era largo por dos razones: el flujo de aprobación era largo y único para todos, y la alta tasa de rechazos obligaba a que muchas solicitudes pasaran por el flujo más de una vez.
El Proceso Lento: Una solicitud podía pasar un día en la bandeja de entrada de un aprobador, ser rechazada al día siguiente, tomar otro día para ser corregida y reenviada, y finalmente ser aprobada medio día después. El promedio de todo este ciclo era de 3.5 días.
Escenario “Después” (2 Días)
Los nuevos flujos especializados y la mayor tasa de aprobación al primer intento aceleraron todo el proceso.
El Proceso Ágil: Una solicitud para un proveedor no crítico ahora seguía un flujo corto de aprobaciones. Como las validaciones eran automáticas y las plantillas claras, la probabilidad de rechazo era mucho menor. Esto eliminó el tiempo muerto del ciclo de correcciones, reduciendo el tiempo promedio total a 2 días.
“Un proveedor tardaba en promedio 3.5 días en estar operativo, un retraso causado por un proceso burocrático y una alta tasa de errores. Al especializar los flujos de aprobación y mejorar la calidad de las solicitudes, eliminamos los reprocesos y redujimos el tiempo de alta a solo 2 días, permitiendo que el área de Compras pudiera actuar con mayor agilidad.”
Esta métrica es el reflejo, en números absolutos, de la mejora en la tasa de aprobación. Mide la cantidad total de “eventos de rechazo” que ocurrían cada semana.
Escenario “Antes” (57 Rechazos Semanales)
Este número tan alto indica un proceso en caos. No significa que 57 proveedores distintos fueran rechazados, sino que el volumen total de rechazos (incluyendo una misma solicitud rechazada varias veces) era de 57.
El Ciclo de Rechazo: Con una tasa de aprobación del 62%, una gran parte de las ~25 solicitudes semanales entraba en un bucle: Solicitar → Rechazar → Corregir → Volver a solicitar → Volver a rechazar… La suma de todos estos eventos de rechazo a lo largo de la semana llegaba a 57.
Escenario “Después” (16 Rechazos Semanales)
Al aumentar la tasa de aprobación al 81%, el ciclo de rechazos se rompió. La mayoría de las solicitudes ahora pasaban directamente.
El Proceso Controlado: Las solicitudes eran de mayor calidad, por lo que necesitaban muchas menos correcciones. El número total de eventos de rechazo semanales se desplomó a solo 16.
“El síntoma más claro de nuestro problema era el abrumador número de 57 rechazos semanales, que mantenía al equipo en un estado constante de revisión y corrección. Al mejorar la calidad de las solicitudes desde su origen, logramos reducir drásticamente este número a solo 16. Esto no solo es una mejora del 72% en el volumen de rechazos, sino que liberó al equipo para que pudiera enfocarse en tareas de mayor valor.”
Esta métrica mide un problema muy específico y costoso: el número de facturas de proveedores que el equipo de Cuentas por Pagar no podía procesar porque los datos del sistema no coincidían con los de la factura. El principal culpable suele ser un número de cuenta bancaria incorrecto.
Escenario “Antes” (22 Facturas con Diferencias Semanales)
El proceso para actualizar datos sensibles de un proveedor (como su cuenta bancaria) era informal e inseguro, a menudo a través de un simple correo electrónico.
La Causa Raíz: No existía un flujo de trabajo formal para validar y aprobar cambios en los datos bancarios. Esto llevaba a errores de digitación o a que el cambio no se realizara a tiempo antes del siguiente ciclo de pagos.
Línea Base: El equipo de Cuentas por Pagar reportaba que, en promedio, 22 facturas por semana eran detenidas y rechazadas porque la cuenta bancaria en la factura del proveedor no coincidía con la que estaba registrada en SAP. Cada uno de estos casos requería una investigación manual, contacto con el proveedor y una corrección urgente, retrasando los pagos.
Escenario “Después” (5 Facturas con Diferencias Semanales)
La solución fue el “Flujo 3: Modificación de Datos Sensibles”. Este flujo de trabajo dedicado y de alta seguridad aseguró que cualquier cambio en una cuenta bancaria fuera verificado y aprobado correctamente.
El Proceso Seguro: Este flujo exigía una solicitud formal, la presentación de un certificado bancario como evidencia y una doble aprobación (principio de “cuatro ojos”) antes de que el cambio se hiciera efectivo en SAP.
Resultado: Con datos bancarios mucho más confiables y actualizados, el número de facturas que rebotaban por esta causa se desplomó a solo 5 por semana.
“Los errores en los datos bancarios de los proveedores estaban causando el rechazo de 22 facturas semanales, lo que generaba retrasos en los pagos y tensiones con nuestros socios comerciales. Al implementar un flujo de trabajo seguro y con doble validación para la modificación de datos sensibles, garantizamos la exactitud de la información. Como resultado, redujimos las diferencias en facturas en un 77%, a solo 5 por semana, agilizando el proceso de pago.”
Un SLA (Acuerdo de Nivel de Servicio) es una promesa al negocio. En este caso, la promesa era sobre el tiempo máximo que tomaría crear un nuevo proveedor. Basado en la otra métrica (reducción del tiempo de alta a 2 días), un SLA razonable sería: “El 100% de las solicitudes de nuevos proveedores se completarán en un plazo máximo de 2 días hábiles”.
Esta métrica mide qué tan bien se cumplió esa promesa.
El Escenario
El cumplimiento se mide sobre el volumen total de solicitudes gestionadas.
Universo de Datos: Promedio de ~25 solicitudes semanales.
Línea Base “Antes”: Aunque el promedio era de 3.5 días, algunos casos podían tardar una semana. No había un SLA formal, pero si lo medimos con el objetivo de 2 días, el cumplimiento era muy bajo, probablemente alrededor del 40% (solo 10 de 25 solicitudes se completaban a tiempo).
Resultado “Después”: Con los nuevos flujos de trabajo optimizados y la drástica reducción de errores, el proceso se volvió predecible y rápido, permitiéndote establecer y cumplir un SLA formal.
Cálculo del Cumplimiento:
Esto significa que, de las 25 solicitudes que recibías cada semana, en promedio, 24 se completaban dentro del plazo de 2 días. Solo 1, por alguna complejidad excepcional, podía tardar un poco más.
“El negocio necesitaba previsibilidad. Antes, el proceso era tan variable que no se podía garantizar cuándo estaría listo un nuevo proveedor. Después de la optimización, pudimos comprometernos a un SLA de 2 días y alcanzar un cumplimiento del 95%. Esto significa que, de las 25 solicitudes que gestionábamos a la semana, 24 estaban listas a tiempo, dándole al área de Compras la confianza y velocidad que necesitaban para operar sin demoras.”
Parte 2: Migración de Datos Gobernados
El Reto: Como parte de la expansión de la compañía, se necesitaba consolidar una lista de 7,500 proveedores de la sucursal en Colombia. Un intento de carga inicial arrojó una tasa de error del 7%, lo cual era un riesgo para la integración operativa.
- Mi Solución: Reapliqué la misma lógica de validación desarrollada para el nuevo gobierno de datos. Adapté los scripts para analizar el conjunto de datos de migración completo, identificando de forma proactiva todos los registros que no cumplían con nuestro estándar de datos maestros. Esto permitió enfocar el esfuerzo de limpieza solo donde era necesario antes de la carga final.
- El Impacto: El enfoque de “validar primero” fue un éxito.
Esta métrica refleja la calidad de los datos al momento de la carga técnica. Mide el porcentaje de registros que el sistema de destino rechazó por no cumplir con las reglas de negocio o los formatos requeridos.
Escenario “Antes” (7% de Tasa de Error)
Esto representa el resultado de las pruebas de migración iniciales, antes de aplicar un filtro de calidad riguroso.
Universo de Datos: El proyecto consistía en migrar 7,500 registros de proveedores.
Línea Base: En las primeras pruebas, el sistema SAP de destino rechazaba 525 de esos 7,500 registros. Los errores se debían a que los datos de origen no cumplían con los nuevos estándares de calidad que se habían definido para el proceso de alta.
Cálculo de la Tasa de Error Inicial:
Escenario “Después” (3% de Tasa de Error)
La solución fue reutilizar los mismos principios de gobierno y validaciones automáticas que se diseñó para las altas diarias y aplicarlos a todo el conjunto de datos de la migración.
Acción Correctiva: Ejecuté un script de pre-validación que analizó los 7,500 registros e identificó los 525 que contenían errores. El equipo se enfocó en depurar esta lista específica, logrando corregir 300 de ellos antes de la carga final.
Resultado: Gracias a esta limpieza proactiva, en el intento de carga definitivo, el número de registros que el sistema rechazó fue de solo 225.
Cálculo de la Tasa de Error Final:
“Una migración exitosa depende de la calidad de los datos de origen. Las pruebas iniciales mostraban una alarmante tasa de error del 7%. Para mitigar esto, apliqué los nuevos estándares de gobierno a todo el set de datos, ejecutando un proceso de validación masiva que nos permitió identificar y corregir la mayoría de los errores de antemano. Gracias a esto, redujimos la tasa de error en la carga final a un manejable 3%.”
Esta métrica es el sello de garantía de una migración. No mide la calidad del contenido de los datos, sino la integridad del proceso: que la cantidad de registros que salieron del origen sea la misma que llegó al destino.
El Escenario
La reconciliación es el conteo final que certifica que no se perdió información en el proceso.
Registros en Origen: Se definió que el universo a migrar era de 7,500 registros de proveedores.
Registros en Destino: Una vez finalizado el proceso de carga (ETL), un conteo (
SELECT COUNT(*)) en la tabla de destino en SAP arrojó un total de 7,350 registros cargados exitosamente.Registros Faltantes: La diferencia, registros, corresponde a aquellos que, por errores críticos o por ser considerados obsoletos en la validación final, no fueron cargados. Crucialmente, estos 150 registros no se “perdieron”, sino que fueron documentados en un reporte de excepciones para ser revisados por el negocio.
El Cálculo
“Para asegurar la integridad de la migración, implementamos un control de reconciliación de registros. El resultado fue una tasa del 98%, lo que nos permitió certificar que 7,350 de los 7,500 registros planeados fueron cargados exitosamente. El 2% restante fue completamente trazado en un log de excepciones, garantizando cero pérdida de información y una transición confiable al nuevo sistema.”