Substituí 3 Relatórios Manuais de SAP por Agentes de IA – Veja o ROI no Brasil

Os Relatórios Que Consumiam a Semana da Minha Equipe

Toda segunda-feira de manhã, três analistas da minha equipe abriam o SAP GUI e iniciavam um ritual que consumia aproximadamente 22 horas de trabalho coletivo por semana. Eles executavam a transação MB52 para obter os valores de estoque do almoxarifado em 14 unidades, exportavam para o Excel, faziam referência cruzada com pedidos de compra em aberto (ME2M) e, em seguida, construíam manualmente uma análise de cobertura. Um segundo analista puxava os itens em aberto de clientes via FBL5N para a análise de envelhecimento de contas a receber, limpava os dados, aplicava regras de negócio para categorias de escalonamento e enviava os resultados por e-mail aos gerentes regionais. O terceiro gerava um relatório de conformidade de compras comparando os pedidos de compra do ME2M com os preços de contrato negociados no ME33K.

Estes não eram relatórios de vaidade. O departamento financeiro dependia da análise de envelhecimento de AR para projeções de fluxo de caixa. A cadeia de suprimentos usava o relatório de cobertura de estoque para tomar decisões diárias de reabastecimento. A área de compras precisava do relatório de conformidade para auditorias trimestrais. Os relatórios eram importantes — o que não fazia sentido era ter analistas qualificados gastando suas manhãs copiando dados entre SAP e Excel.

No terceiro e quarto trimestre de 2025, substituí todos os três relatórios por agentes de IA que puxam dados diretamente do SAP, aplicam a lógica de negócios, geram a análise e distribuem os resultados automaticamente. Veja exatamente como cada um funciona, quanto custou e o ROI mensurável.

Relatório #1: Análise de Cobertura de Estoque de Almoxarifado (MB52 + ME2M)

Como Era o Processo Manual

O analista fazia login no SAP GUI toda segunda e quarta-feira, executava a transação MB52 (Estoques de Almoxarifado) filtrada por centro e local de armazenamento. Para nossa configuração, isso significava 14 centros, cada um com 3 a 8 locais de armazenamento. Ele executava o relatório, exportava para uma planilha local usando a função de exportação da grade ALV (Lista > Exportar > Planilha) e depois fazia o mesmo para o próximo centro.

Após coletar todos os dados de estoque, ele mudava para o ME2M (Pedidos de Compra por Material) para puxar os pedidos de compra em aberto com datas de entrega nos próximos 30 dias. Isso exigia outra rodada de exportações — filtrando por centro, tipo de documento (NB para pedidos de compra padrão, UB para pedidos de transferência de estoque) e removendo itens concluídos.

Em seguida, vinha a análise propriamente dita: cálculo dos dias de cobertura dividindo o estoque atual pelo consumo médio diário (que ele puxava do MC.9 — estatísticas de consumo de material), sinalizando itens abaixo dos limites de estoque de segurança e destacando materiais sem suprimento de entrada no pipeline.

Tempo total: aproximadamente 8 horas por semana.

O Agente de IA Que o Substituiu

O agente é executado em um backend Python com execução agendada via APScheduler. Ele se conecta ao SAP via RFC usando a biblioteca PyRFC, que oferece acesso direto a BAPIs e módulos de função — muito mais eficiente do que raspar a GUI ou usar OData para extração de dados de alto volume.

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)

O componente de IA entra na camada de análise. Em vez de regras codificadas para sinalizar problemas, treinei um modelo de classificação com 18 meses de eventos históricos de falta de estoque. O modelo considera os níveis de estoque atuais, a velocidade de consumo, os prazos de entrega do cadastro de materiais (tabela MARC, campo PLIFZ para tempo de entrega planejado), padrões sazonais e a confiabilidade dos pedidos de compra em aberto (qual porcentagem de pedidos de cada fornecedor realmente chega no prazo, puxado do EKBE — histórico de pedidos 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

O agente formata os resultados como um relatório HTML interativo e o envia por e-mail para a equipe de cadeia de suprimentos, com itens críticos destacados no topo. Ele também envia itens CRÍTICOS para um canal do Microsoft Teams via webhook.

ROI para o Relatório #1

O grande ganho aqui não foi a economia de mão de obra — foi a redução de falta de estoque. O modelo de IA identifica padrões de risco que os humanos não percebem porque processa todas as 14 unidades simultaneamente e considera possibilidades de transferência entre unidades. Quando a Unidade 1200 está com pouco material, mas a Unidade 1400 tem excesso, o agente sinaliza a oportunidade de transferência. O analista nunca teve tempo para fazer a análise entre unidades manualmente.

Relatório #2: Envelhecimento de Contas a Receber (FBL5N)

O Processo Manual

Toda terça e quinta-feira, um analista executava o FBL5N (Itens de Linha do Cliente) para cada empresa (operamos cinco). Ele definia os parâmetros para mostrar apenas itens em aberto, classificava por data de vencimento líquida, exportava para o Excel e, em seguida, aplicava um conjunto complexo de regras de negócio:

• Itens com 1-30 dias de atraso: categoria "Lembrete", sem escalonamento
• Itens com 31-60 dias de atraso: categoria "Acompanhamento", e-mail para o representante de vendas
• Itens com 61-90 dias de atraso: categoria "Escalonamento", e-mail para o gerente de vendas + gerente regional
• Itens com mais de 90 dias de atraso: categoria "Crítico", e-mail para o VP de Vendas + Diretor Financeiro
• Regras especiais: clientes governamentais recebem 15 dias extras de carência, clientes com acordos de plano de pagamento são excluídos, itens abaixo de R$ 2.500 são agrupados em um resumo separado

Ele também puxava o histórico de pagamentos da tabela BSAD (itens de cliente compensados) para calcular o comportamento médio de pagamento de cada cliente — eles geralmente pagam no prazo, com 10 dias de atraso, 30 dias de atraso?

Tempo total: aproximadamente 6 horas por semana.

O Agente de IA

Este agente usa conexões RFC para puxar dados diretamente das tabelas FI. Os dados principais vêm de BSID (itens de linha de cliente em aberto) e BSAD (itens compensados para histórico de pagamentos):

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)

O componente de IA aqui faz duas coisas que o processo manual não conseguia:

1. Previsão de pagamento. Usando dados históricos de pagamento do BSAD, o modelo prevê quando cada item em aberto será realmente pago. Não apenas "está 45 dias atrasado", mas "com base no padrão de comportamento deste cliente, este item tem 78% de chance de ser pago nos próximos 7 dias". Isso transforma o relatório de envelhecimento de um instantâneo retrospectivo em uma projeção 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. Roteamento inteligente de escalonamento. Em vez de regras rígidas baseadas em faixas, o agente considera o contexto completo. Uma fatura de R$ 250.000 de um cliente que sempre paga com 5 dias de atraso não é o mesmo risco que uma fatura de R$ 250.000 de um cliente com padrões de pagamento em deterioração. A IA pontua cada item e encaminha e-mails de escalonamento para a pessoa certa com o contexto certo.

O agente gera relatórios individualizados para cada gerente regional, mostrando apenas seus clientes. Os representantes de vendas recebem um e-mail matinal com seus itens de acompanhamento específicos, incluindo pontos de discussão sugeridos com base no histórico de pagamentos do cliente. "O Cliente XYZ tem 3 faturas totalizando R$ 635.000 com mais de 45 dias de atraso. Seu atraso médio de pagamento aumentou de 12 para 28 dias no último trimestre — sugira discutir os termos de pagamento na próxima reunião."

ROI para o Relatório #2

A redução do DSO sozinha justificou todo o projeto dez vezes. Quando você pode prever quais clientes estão prestes a se tornar inadimplentes antes que realmente percam o prazo, sua equipe de cobrança pode fazer chamadas proativas em vez de reativas. A melhoria de 8 dias no DSO sobre R$ 200 milhões em receita anual se traduz em quase R$ 4,4 milhões em capital de giro liberado — dinheiro que antes estava parado em faturas não pagas.

Relatório #3: Verificação de Conformidade de Compras (ME2M + ME33K)

O Processo Manual

Este era o mais doloroso. O analista de conformidade puxava todos os pedidos de compra criados no mês anterior do ME2M, então verificava manualmente cada um contra o contrato relevante no ME33K para verificar se o preço do pedido correspondia ao preço do contrato negociado. Para materiais sem contrato, ela verificava contra o preço do registro de informações no ME13.

A lógica de verificação era surpreendentemente complexa:

• Tolerância de preço: o preço do pedido pode ser até 3% acima do preço do contrato para materiais, 5% para serviços
• Tolerância de quantidade: a quantidade do pedido deve estar dentro do período de validade do contrato e abaixo da quantidade restante do contrato
• Correspondência de fornecedor: o fornecedor do pedido deve corresponder ao fornecedor do contrato (óbvio, mas violações acontecem quando alguém digita manualmente um número de fornecedor diferente)
• Condições de pagamento: as condições de pagamento do pedido devem corresponder ou ser mais favoráveis do que as condições do contrato
• Gastos irregulares (Maverick spending): pedidos para materiais que têm um contrato ativo, mas foram pedidos fora do contrato (fornecedor diferente ou sem referência de contrato)

Ela compilava todas as violações em uma planilha, as categorizava por gravidade e departamento e as enviava ao Chefe de Compras mensalmente. O relatório também alimentava a auditoria interna trimestral.

Tempo total: aproximadamente 8 horas por semana (muito concentrado no final do mês).

O Agente de IA

Este agente puxa dados de várias tabelas SAP: EKKO/EKPO (cabeçalho/item do pedido), EKKO (cabeçalho do contrato via categoria de documento "K"), EINE/EINA (registros de informações de compra) e LFA1 (cadastro de fornecedores).

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)

A IA agrega valor aqui de três maneiras:

1. Detecção de padrões para problemas sistemáticos de conformidade. O modelo identifica padrões que sugerem problemas organizacionais, não apenas violações individuais. "O Departamento 4200 teve 23 instâncias de gastos irregulares nos últimos 90 dias, todas do mesmo comprador. 18 delas são para materiais cobertos pelo contrato 4600012345 com o fornecedor 100234." Isso não é algo que você pegaria revisando pedidos de compra individuais.

2. Redução de falsos positivos. Muitas violações aparentes têm razões legítimas — compras de emergência, emendas contratuais ainda não refletidas no sistema, substituições de fornecedores aprovadas pela gerência de compras. O modelo de IA aprende com dados históricos de disposição (quais violações foram marcadas como "justificadas" em auditorias anteriores) e atribui uma pontuação de confiança. Violações que correspondem a padrões de exceções historicamente justificadas são despriorizadas, economizando o tempo da equipe de conformidade de revisar centenas de não-problemas.

3. Previsão de impacto financeiro. Em vez de apenas mostrar "este pedido está 7% acima do preço do contrato", o agente calcula o impacto anual total se essa variação de preço persistir em todos os pedidos para este material. Uma variação de 7% em um material que você pede duas vezes por ano é de R$ 1.000. A mesma variação em um material que você pede semanalmente pode ser de R$ 250.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 para o Relatório #3

A taxa de recuperação saltou de 15% para 40% porque o agente de IA apresenta cada violação com contexto completo — os detalhes do contrato, o padrão histórico, o impacto anualizado e uma ação recomendada. Quando um gerente de compras recebe um relatório dizendo "O comprador X fez R$ 4,45 milhões em pedidos fora dos contratos no último trimestre, aqui estão os 5 principais padrões e correções sugeridas", ele pode tomar medidas imediatas em vez de gastar dias investigando.

A Infraestrutura Técnica Por Trás dos Três Agentes

Todos os três agentes compartilham uma infraestrutura comum:

• Tempo de execução: Python 3.11 em uma VM Ubuntu com 4 cores e 8 GB de RAM
• Conectividade SAP: PyRFC com SAP NetWeaver RFC SDK, conectando-se via um usuário RFC dedicado com autorizações mínimas (acesso somente leitura às tabelas e BAPIs específicas necessárias)
• Agendamento: APScheduler com um armazenamento de tarefas PostgreSQL para persistência
• Framework de ML: scikit-learn para os modelos de classificação e previsão, retreinados mensalmente a partir de dados SAP atualizados
• Geração de relatórios: Templates Jinja2 produzindo e-mails HTML, com pandas para manipulação de dados
• Monitoramento: Métricas Prometheus exportadas para Grafana — tempo de execução, contagem de registros, taxas de erro

O custo total de infraestrutura para os três agentes é de aproximadamente R$ 30.000 por ano. O benefício anual combinado é de mais de R$ 7,5 milhões. Isso é um retorno de 250x.

O Que Aprendi Construindo Isso

Comece com o relatório que sua equipe mais odeia. Não escolha o mais fácil — escolha aquele que causa mais frustração. É aí que você obterá a adoção mais rápida e a menor resistência dos stakeholders. Ninguém discutiu a automação do relatório de conformidade porque todos odiavam produzi-lo e recebê-lo com atraso.

A IA não é a parte difícil — a extração de dados é. Obter dados do SAP de forma confiável, lidar com as peculiaridades do RFC_READ_TABLE (limite de 65.535 linhas por chamada, alguém?), lidar com conversão de moeda, diferenças de ano fiscal e formatos de data exclusivos do SAP — é aí que 70% do tempo de desenvolvimento é gasto. Os modelos de ML reais são problemas diretos de classificação e regressão.

Mantenha o humano no ciclo, mas mova-o de "produtor" para "revisor". Nenhum desses agentes funciona de forma completamente autônoma. Cada um produz um relatório que um humano revisa antes da distribuição. Mas revisar um relatório finalizado e contextualizado leva de 15 a 30 minutos. Produzi-lo do zero levava de 6 a 8 horas. Esse é o ganho de eficiência.

RFC é melhor que OData para operações em lote. Inicialmente, tentei usar APIs OData para tudo. Para o relatório de cobertura de estoque, puxar dados de estoque de 14 unidades via OData levava 12 minutos e frequentemente estourava o tempo limite. Os mesmos dados via RFC levam 45 segundos. OData é ótimo para operações transacionais e integração de UI, mas para análise em lote, RFC é simplesmente mais rápido.

Construa o ciclo de feedback desde o primeiro dia. Cada agente tem um mecanismo simples para os usuários sinalizarem problemas — um link "relatar problema" no e-mail que cria um ticket. Esse feedback alimenta o retreinamento do modelo. O modelo de envelhecimento de AR melhorou sua precisão de previsão de pagamento de 71% para 89% em seis meses puramente a partir de correções do usuário.

Os Números Combinados

Um período de retorno de 11 dias. Isso não é um erro de digitação. Os benefícios financeiros de redução de falta de estoque, melhoria do DSO e recuperação de gastos irregulares superam tanto os custos de desenvolvimento quanto os custos contínuos.

Você Deveria Fazer Isso?

Se sua equipe gasta mais de 4 horas por semana em qualquer relatório SAP recorrente que envolve exportar dados, manipulá-los no Excel e distribuir resultados, a resposta é sim. O padrão é sempre o mesmo: extrair via RFC, analisar com Python (com ou sem ML, dependendo da complexidade), formatar com templates, distribuir via e-mail ou Teams, monitorar com ferramentas padrão.

Os três relatórios que escolhi não são especiais. A mesma abordagem funciona para análise de exceções de MRP (MD04), relatórios de variação de ordem de produção (CO03), resultados de inspeção de qualidade (QA32), relatórios de gerenciamento de transporte (VT02N) e dezenas de outros relatórios SAP recorrentes que atualmente são produzidos manualmente.

Pare de exportar para o Excel. Crie um agente. Meça os resultados. O ROI falará por si.