Reemplacé 3 Informes Manuales de SAP con Agentes de IA: Así Fue el Retorno de Inversión

Los Informes que Consumían la Semana de mi Equipo

Cada lunes por la mañana, tres analistas de mi equipo abrían SAP GUI y comenzaban un ritual que consumía aproximadamente 22 horas de trabajo colectivo cada semana. Ejecutaban la transacción MB52 para obtener los valores de stock de almacén en 14 plantas, exportaban a Excel, comparaban con órdenes de compra abiertas de ME2M y luego construían manualmente un análisis de cobertura. Un segundo analista extraía partidas abiertas de clientes a través de FBL5N para el envejecimiento de cuentas por cobrar, limpiaba los datos, aplicaba reglas de negocio para categorías de escalada y enviaba los resultados por correo electrónico a los controllers regionales. El tercero generaba un informe de cumplimiento de compras comparando las órdenes de compra de ME2M con los precios de contrato negociados en ME33K.

Estos no eran informes triviales. Finanzas dependía del envejecimiento de las cuentas por cobrar para las proyecciones de flujo de caja. La cadena de suministro utilizaba el informe de cobertura de stock para tomar decisiones diarias de reabastecimiento. Compras necesitaba el informe de cumplimiento para las auditorías trimestrales. Los informes eran importantes; lo que no tenía sentido era tener analistas cualificados dedicando sus mañanas a copiar datos entre SAP y Excel.

Durante el tercer y cuarto trimestre de 2025, reemplacé los tres informes con agentes de IA que extraen datos directamente de SAP, aplican la lógica de negocio, generan el análisis y distribuyen los resultados automáticamente. A continuación, te explico exactamente cómo funciona cada uno, su costo y el ROI medible.

Informe #1: Análisis de Cobertura de Stock de Almacén (MB52 + ME2M)

Cómo era el Proceso Manual

El analista iniciaba sesión en SAP GUI cada lunes y miércoles, ejecutaba la transacción MB52 (Stocks de Almacén) filtrada por planta y ubicación de almacenamiento. Para nuestra configuración, esto significaba 14 plantas, cada una con 3 a 8 ubicaciones de almacenamiento. Ejecutaba el informe, lo exportaba a una hoja de cálculo local usando la función de exportación de la cuadrícula ALV (Lista > Exportar > Hoja de cálculo), y luego lo hacía de nuevo para la siguiente planta.

Después de recopilar todos los datos de stock, cambiaba a ME2M (Órdenes de Compra por Material) para extraer las órdenes de compra abiertas con fechas de entrega en los próximos 30 días. Esto requería otra ronda de exportaciones, filtrando por planta, tipo de documento (NB para órdenes de compra estándar, UB para órdenes de traslado de stock) y eliminando los artículos completados.

Luego venía el análisis real: calcular los días de cobertura dividiendo el stock actual por el consumo diario promedio (que extraía de MC.9 – estadísticas de consumo de material), marcando los artículos por debajo de los umbrales de stock de seguridad y resaltando los materiales sin suministro entrante en el pipeline.

Tiempo total: aproximadamente 8 horas por semana.

El Agente de IA que lo Reemplazó

El agente se ejecuta en un backend de Python con ejecución programada a través de APScheduler. Se conecta a SAP vía RFC utilizando la librería PyRFC, lo que da acceso directo a BAPIs y módulos de función, mucho más eficiente que el "scraping" de la GUI o el uso de OData para la extracción de datos de alto volumen.

from pyrfc import Connection
import pandas as pd

def get_warehouse_stocks(conn, plants):
    # Pull stock data equivalent to MB52
    stocks = []
    for plant in plants:
        result = conn.call('BAPI_MATERIAL_STOCK_REQ_LIST',
            PLANT=plant,
            MATERIAL='',  # all materials
            RAW_DATA='X'
        )
        for item in result['STOCK_REQ_LIST']:
            stocks.append({
                'plant': plant,
                'material': item['MATERIAL'],
                'storage_loc': item['STGE_LOC'],
                'unrestricted': float(item['UNRESTRICTED']),
                'in_quality': float(item['QUAL_INSP']),
                'blocked': float(item['BLOCKED']),
                'unit': item['BASE_UOM']
            })
    return pd.DataFrame(stocks)

def get_open_purchase_orders(conn, plants):
    # Pull open POs equivalent to ME2M
    pos = []
    for plant in plants:
        result = conn.call('BAPI_PO_GETITEMS',
            PLANT=plant,
            DOC_TYPE='NB',
            ITEMS_OPEN_ONLY='X'
        )
        for item in result['PO_ITEMS']:
            if float(item['STILL_TO_DL']) > 0:
                pos.append({
                    'plant': plant,
                    'po_number': item['PO_NUMBER'],
                    'material': item['PUR_MAT'],
                    'quantity_open': float(item['STILL_TO_DL']),
                    'delivery_date': item['DELIV_DATE'],
                    'vendor': item['VENDOR']
                })
    return pd.DataFrame(pos)

El componente de IA entra en la capa de análisis. En lugar de reglas codificadas para marcar problemas, entrené un modelo de clasificación con 18 meses de eventos históricos de desabastecimiento. El modelo considera los niveles de stock actuales, la velocidad de consumo, los tiempos de entrega del maestro de materiales (tabla MARC, campo PLIFZ para el tiempo de entrega planificado), patrones estacionales y la fiabilidad de las órdenes de compra abiertas (qué porcentaje de POs de cada proveedor llegan a tiempo, extraído de EKBE – historial de órdenes de compra).

def calculate_coverage_with_ai(stocks_df, orders_df, consumption_df, model):
    # AI-enhanced coverage analysis
    merged = stocks_df.merge(consumption_df, on=['plant', 'material'], how='left')
    merged = merged.merge(
        orders_df.groupby(['plant', 'material']).agg(
            incoming_qty=('quantity_open', 'sum'),
            earliest_delivery=('delivery_date', 'min')
        ).reset_index(),
        on=['plant', 'material'], how='left'
    )

    # Calculate basic coverage days
    merged['daily_consumption'] = merged['avg_monthly_consumption'] / 30
    merged['coverage_days'] = merged.apply(
        lambda r: r['unrestricted'] / r['daily_consumption']
        if r['daily_consumption'] > 0 else 999, axis=1
    )

    # AI prediction: probability of stock-out in next 14 days
    features = merged[['coverage_days', 'incoming_qty', 'vendor_reliability',
                        'seasonal_factor', 'consumption_volatility']].fillna(0)
    merged['stockout_probability'] = model.predict_proba(features)[:, 1]

    # Classify risk
    merged['risk_level'] = merged['stockout_probability'].apply(
        lambda p: 'CRITICAL' if p > 0.7 else ('WARNING' if p > 0.4 else 'OK')
    )

    return merged

El agente formatea los resultados como un informe HTML interactivo y lo envía por correo electrónico al equipo de cadena de suministro, con los elementos críticos resaltados en la parte superior. También envía los elementos CRÍTICOS a un canal de Microsoft Teams a través de un webhook.

ROI del Informe #1

La gran ganancia aquí no fue el ahorro de mano de obra, sino la reducción de desabastecimientos. El modelo de IA detecta patrones de riesgo que los humanos pasan por alto porque procesa las 14 plantas simultáneamente y considera las posibilidades de transferencia entre plantas. Cuando la Planta 1200 tiene poco material pero la Planta 1400 tiene un exceso, el agente señala la oportunidad de transferencia. El analista nunca tuvo tiempo de hacer un análisis inter-plantas manualmente.

Informe #2: Envejecimiento de Cuentas por Cobrar (FBL5N)

El Proceso Manual

Cada martes y jueves, un analista ejecutaba FBL5N (Partidas Individuales de Cliente) para cada sociedad (operamos cinco). Configuraba los parámetros para mostrar solo las partidas abiertas, ordenaba por fecha de vencimiento neta, exportaba a Excel y luego aplicaba un complejo conjunto de reglas de negocio:

• Partidas con 1-30 días de atraso: categoría "Recordatorio", sin escalada.
• Partidas con 31-60 días de atraso: categoría "Seguimiento", correo electrónico al representante de ventas.
• Partidas con 61-90 días de atraso: categoría "Escalada", correo electrónico al gerente de ventas + controller regional.
• Partidas con más de 90 días de atraso: categoría "Crítico", correo electrónico al VP de Ventas + Director de Finanzas.
• Reglas especiales: los clientes gubernamentales tienen 15 días de gracia adicionales, los clientes con acuerdos de plan de pago están excluidos, los artículos de menos de USD 500 se agrupan en un resumen separado.

También extraía el historial de pagos de la tabla BSAD (partidas de cliente compensadas) para calcular el comportamiento de pago promedio de cada cliente: ¿suelen pagar a tiempo, con 10 días de retraso, con 30 días de retraso?

Tiempo total: aproximadamente 6 horas por semana.

El Agente de IA

Este agente utiliza conexiones RFC para extraer datos directamente de las tablas de FI. Los datos principales provienen de BSID (partidas abiertas de cliente) y BSAD (partidas compensadas para el historial de pagos):

def get_ar_aging_data(conn, company_codes):
    # Pull AR data equivalent to FBL5N open items
    open_items = []
    for bukrs in company_codes:
        result = conn.call('RFC_READ_TABLE',
            QUERY_TABLE='BSID',
            DELIMITER='|',
            OPTIONS=[{'TEXT': f"BUKRS = '{bukrs}'"}],
            FIELDS=[
                {'FIELDNAME': 'BUKRS'}, {'FIELDNAME': 'KUNNR'},
                {'FIELDNAME': 'BELNR'}, {'FIELDNAME': 'BUZEI'},
                {'FIELDNAME': 'BLDAT'}, {'FIELDNAME': 'BUDAT'},
                {'FIELDNAME': 'ZFBDT'}, {'FIELDNAME': 'ZBD1T'},
                {'FIELDNAME': 'DMBTR'}, {'FIELDNAME': 'WAERS'},
                {'FIELDNAME': 'SGTXT'}
            ]
        )
        for row in result['DATA']:
            fields = row['WA'].split('|')
            # Parse and append...
            open_items.append(parse_bsid_row(fields, bukrs))
    return pd.DataFrame(open_items)

El componente de IA aquí hace dos cosas que el proceso manual no podía:

1. Predicción de pagos. Utilizando datos históricos de pagos de BSAD, el modelo predice cuándo se pagará realmente cada partida abierta. No solo "tiene 45 días de atraso" sino "según el patrón de comportamiento de este cliente, esta partida tiene un 78% de probabilidad de ser pagada en los próximos 7 días". Esto transforma el informe de envejecimiento de una instantánea retrospectiva a una proyección prospectiva.

from sklearn.ensemble import GradientBoostingClassifier
import numpy as np

def train_payment_predictor(historical_data):
    # Train model on cleared items to predict payment timing
    features = historical_data[[
        'customer_segment', 'invoice_amount_bucket',
        'historical_avg_days_late', 'historical_payment_count',
        'days_since_due', 'company_code', 'is_government',
        'has_payment_plan', 'credit_limit_utilization'
    ]]

    # Target: will pay within 7 days (1) or not (0)
    target = (historical_data['actual_days_to_payment'] <= 7).astype(int)

    model = GradientBoostingClassifier(
        n_estimators=200,
        max_depth=5,
        learning_rate=0.1
    )
    model.fit(features, target)
    return model

2. Enrutamiento inteligente de escaladas. En lugar de reglas rígidas basadas en rangos, el agente considera el contexto completo. Una factura de USD 50,000 de un cliente que siempre paga con 5 días de retraso no es el mismo riesgo que una factura de USD 50,000 de un cliente con patrones de pago deteriorados. La IA califica cada partida y envía correos electrónicos de escalada a la persona adecuada con el contexto correcto.

El agente genera informes individualizados para cada controller regional, mostrando solo sus clientes. Los representantes de ventas reciben un correo electrónico matutino con sus partidas específicas de seguimiento, incluyendo puntos de conversación sugeridos basados en el historial de pagos del cliente. "El Cliente XYZ tiene 3 facturas por un total de USD 127,000 con más de 45 días de atraso. Su retraso promedio de pago ha aumentado de 12 a 28 días en el último trimestre; sugiera discutir los términos de pago en la próxima reunión."

ROI del Informe #2

La reducción del DSO por sí sola justificó el proyecto entero diez veces. Cuando puedes predecir qué clientes están a punto de caer en mora antes de que realmente incumplan el plazo, tu equipo de cobranzas puede hacer llamadas proactivas en lugar de reactivas. La mejora de 8 días en el DSO sobre USD 40M en ingresos anuales se traduce en casi USD 900K en capital de trabajo liberado, dinero que antes estaba en facturas impagas.

Informe #3: Verificación de Cumplimiento de Compras (ME2M + ME33K)

El Proceso Manual

Este era el más doloroso. El analista de cumplimiento extraía todas las órdenes de compra creadas en el último mes de ME2M, luego verificaba manualmente cada una contra el contrato relevante en ME33K para comprobar que el precio de la PO coincidía con el precio del contrato negociado. Para los materiales sin contrato, verificaba contra el precio del registro info en ME13.

La lógica de verificación era sorprendentemente compleja:

• Tolerancia de precio: el precio de la PO puede ser hasta un 3% superior al precio del contrato para materiales, 5% para servicios.
• Tolerancia de cantidad: la cantidad de la PO debe estar dentro del período de validez del contrato y por debajo de la cantidad restante del contrato.
• Coincidencia de proveedor: el proveedor de la PO debe coincidir con el proveedor del contrato (obvio, pero ocurren violaciones cuando alguien escribe manualmente un número de proveedor diferente).
• Términos de pago: los términos de pago de la PO deben coincidir o ser más favorables que los términos del contrato.
• Gasto "Maverick": Órdenes de compra de materiales que tienen un contrato activo pero que se solicitaron fuera del contrato (proveedor diferente o sin referencia de contrato).

Compilaba todas las violaciones en una hoja de cálculo, las categorizaba por gravedad y departamento, y las enviaba al Jefe de Compras mensualmente. El informe también alimentaba la auditoría interna trimestral.

Tiempo total: aproximadamente 8 horas por semana (con una carga de trabajo muy alta a fin de mes).

El Agente de IA

Este agente extrae datos de varias tablas de SAP: EKKO/EKPO (cabecera/posición de PO), EKKO (cabecera de contrato a través de la categoría de documento "K"), EINE/EINA (registros info de compras) y LFA1 (maestro de proveedores).

def check_procurement_compliance(conn, company_code, date_from, date_to):
    # Check POs against contracts and info records

    # Get all POs in date range
    po_data = get_purchase_orders(conn, company_code, date_from, date_to)

    # Get all active contracts
    contracts = get_active_contracts(conn, company_code)

    # Get info records for fallback pricing
    info_records = get_info_records(conn)

    violations = []
    for _, po in po_data.iterrows():
        # Find matching contract
        contract = find_matching_contract(
            contracts,
            material=po['material'],
            vendor=po['vendor'],
            plant=po['plant'],
            date=po['doc_date']
        )

        if contract is not None:
            # Check price compliance
            price_deviation = (po['net_price'] - contract['contract_price']) / contract['contract_price']
            tolerance = 0.05 if po['item_category'] == 'D' else 0.03  # services vs materials

            if price_deviation > tolerance:
                violations.append({
                    'type': 'PRICE_OVERRUN',
                    'severity': 'HIGH' if price_deviation > 0.10 else 'MEDIUM',
                    'po_number': po['po_number'],
                    'material': po['material'],
                    'po_price': po['net_price'],
                    'contract_price': contract['contract_price'],
                    'deviation_pct': price_deviation * 100,
                    'financial_impact': (po['net_price'] - contract['contract_price']) * po['quantity']
                })

            # Check quantity against remaining contract quantity
            if po['quantity'] > contract['remaining_qty']:
                violations.append({
                    'type': 'QUANTITY_EXCEED',
                    'severity': 'MEDIUM',
                    'po_number': po['po_number'],
                    'material': po['material'],
                    'po_qty': po['quantity'],
                    'remaining_contract_qty': contract['remaining_qty']
                })

        else:
            # No contract found — check for maverick spending
            available_contract = find_any_contract_for_material(
                contracts, material=po['material']
            )
            if available_contract is not None:
                violations.append({
                    'type': 'MAVERICK_SPEND',
                    'severity': 'HIGH',
                    'po_number': po['po_number'],
                    'material': po['material'],
                    'vendor_used': po['vendor'],
                    'contract_vendor': available_contract['vendor'],
                    'contract_number': available_contract['contract_number'],
                    'financial_impact': po['net_price'] * po['quantity']
                })

    return pd.DataFrame(violations)

La IA añade valor aquí de tres maneras:

1. Detección de patrones para problemas sistemáticos de cumplimiento. El modelo identifica patrones que sugieren problemas organizacionales, no solo violaciones individuales. "El Departamento 4200 ha tenido 23 instancias de gasto 'maverick' en los últimos 90 días, todas del mismo comprador. 18 de ellas son para materiales cubiertos por el contrato 4600012345 con el proveedor 100234." Esto no es algo que se detectaría revisando POs individuales.

2. Reducción de falsos positivos. Muchas violaciones aparentes tienen razones legítimas: compras de emergencia, enmiendas de contrato aún no reflejadas en el sistema, sustituciones de proveedores aprobadas por la gerencia de compras. El modelo de IA aprende de los datos históricos de disposición (qué violaciones se marcaron como "justificadas" en auditorías anteriores) y asigna un puntaje de confianza. Las violaciones que coinciden con patrones de excepciones históricamente justificadas son despriorizadas, lo que ahorra al equipo de cumplimiento la revisión de cientos de casos sin problema.

3. Pronóstico del impacto financiero. En lugar de solo mostrar "esta PO está un 7% por encima del precio del contrato", el agente calcula el impacto anual total si esta desviación de precios persiste en todos los pedidos de este material. Un exceso del 7% en un material que se pide dos veces al año es de USD 200. El mismo exceso en un material que se pide semanalmente podría ser de USD 50,000 anualmente.

def calculate_annualized_impact(violation, historical_orders):
    # Project annual financial impact of a compliance violation
    material = violation['material']
    vendor = violation['vendor_used'] if 'vendor_used' in violation else violation.get('vendor')

    # Get order frequency for this material
    mat_orders = historical_orders[
        (historical_orders['material'] == material) &
        (historical_orders['doc_date'] >= pd.Timestamp.now() - pd.Timedelta(days=365))
    ]

    annual_quantity = mat_orders['quantity'].sum()
    order_frequency = len(mat_orders)

    if violation['type'] == 'PRICE_OVERRUN':
        unit_overrun = violation['po_price'] - violation['contract_price']
        annualized = unit_overrun * annual_quantity
    elif violation['type'] == 'MAVERICK_SPEND':
        # Estimate savings if contract had been used
        annualized = violation['financial_impact'] * (order_frequency / max(len(mat_orders), 1))
    else:
        annualized = 0

    return {
        'annual_quantity': annual_quantity,
        'order_frequency': order_frequency,
        'annualized_financial_impact': annualized
    }

ROI del Informe #3

La tasa de recuperación saltó del 15% al 40% porque el agente de IA presenta cada violación con el contexto completo: los detalles del contrato, el patrón histórico, el impacto anualizado y una acción recomendada. Cuando un gerente de compras recibe un informe que dice "El comprador X ha realizado USD 890,000 en pedidos fuera de contrato en el último trimestre, aquí están los 5 patrones principales y las correcciones sugeridas", puede tomar medidas inmediatas en lugar de pasar días investigando.

La Infraestructura Técnica Detrás de los Tres Agentes

Los tres agentes comparten una infraestructura común:

• Tiempo de ejecución: Python 3.11 en una VM de Ubuntu con 4 núcleos y 8 GB de RAM.
• Conectividad SAP: PyRFC con SAP NetWeaver RFC SDK, conectándose a través de un usuario RFC dedicado con autorizaciones mínimas (acceso de solo lectura a las tablas y BAPIs específicas necesarias).
• Programación: APScheduler con un almacén de trabajos PostgreSQL para persistencia.
• Framework de ML: scikit-learn para los modelos de clasificación y predicción, reentrenados mensualmente con datos frescos de SAP.
• Generación de informes: Plantillas Jinja2 que producen correos electrónicos HTML, con pandas para la manipulación de datos.
• Monitoreo: Métricas de Prometheus exportadas a Grafana: tiempo de ejecución, recuento de registros, tasas de error.

El costo total de infraestructura para los tres agentes es de aproximadamente USD 6,000 por año. El beneficio anual combinado supera los USD 1.5 millones. Eso es un retorno de 250 veces.

Lo que Aprendí al Construirlos

Comienza con el informe que tu equipo más detesta. No elijas el más fácil; elige el que cause más frustración. Ahí es donde obtendrás la adopción más rápida y la menor resistencia de los stakeholders. Nadie discutió la automatización del informe de cumplimiento porque todos odiaban producirlo y recibirlo tarde.

La IA no es la parte difícil; la extracción de datos sí lo es. Obtener datos de SAP de forma fiable, manejar las peculiaridades de RFC_READ_TABLE (¿límite de 65,535 filas por llamada, alguien?), lidiar con la conversión de moneda, las diferencias de año fiscal y los formatos de fecha únicos de SAP, ahí es donde se invierte el 70% del tiempo de desarrollo. Los modelos de ML reales son problemas sencillos de clasificación y regresión.

Mantén al humano en el circuito, pero cámbialo de "productor" a "revisor". Ninguno de estos agentes funciona de forma completamente autónoma. Cada uno produce un informe que un humano revisa antes de su distribución. Pero revisar un informe terminado y contextualizado lleva de 15 a 30 minutos. Producirlo desde cero tomaba de 6 a 8 horas. Esa es la ganancia de eficiencia.

RFC es mejor que OData para operaciones por lotes. Inicialmente intenté usar APIs de OData para todo. Para el informe de cobertura de stock, extraer datos de stock de 14 plantas a través de OData tardó 12 minutos y con frecuencia se agotaba el tiempo de espera. Los mismos datos a través de RFC tardan 45 segundos. OData es excelente para operaciones transaccionales e integración de interfaz de usuario, pero para análisis por lotes, RFC es simplemente más rápido.

Construye el bucle de retroalimentación desde el primer día. Cada agente tiene un mecanismo simple para que los usuarios reporten problemas: un enlace "reportar problema" en el correo electrónico que crea un ticket. Esta retroalimentación alimenta el reentrenamiento del modelo. El modelo de envejecimiento de cuentas por cobrar mejoró su precisión de predicción de pagos del 71% al 89% en seis meses puramente a partir de las correcciones de los usuarios.

Los Números Combinados

Un período de recuperación de 11 días. Eso no es un error tipográfico. Los beneficios financieros de la reducción de desabastecimientos, la mejora del DSO y la recuperación del gasto "maverick" superan con creces tanto los costos de desarrollo como los continuos.

¿Deberías Hacer Esto?

Si tu equipo dedica más de 4 horas a la semana a cualquier informe recurrente de SAP que implique exportar datos, manipularlos en Excel y distribuir los resultados, la respuesta es sí. El patrón es siempre el mismo: extraer vía RFC, analizar con Python (con o sin ML según la complejidad), formatear con plantillas, distribuir vía correo electrónico o Teams, monitorear con herramientas estándar.

Los tres informes que elegí no son especiales. El mismo enfoque funciona para el análisis de excepciones de MRP (MD04), informes de variación de órdenes de producción (CO03), resultados de inspección de calidad (QA32), informes de gestión de transporte (VT02N) y docenas de otros informes recurrentes de SAP que actualmente se producen manualmente.

Deja de exportar a Excel. Construye un agente. Mide los resultados. El ROI hablará por sí mismo.