Por Que o UX do SAP Fiori Ainda Falha (e Como Copilotos de IA Podem Resolver)

Publicado em abril de 2026 · Pela Equipe PickGeniusLab

Passei a maior parte da última década implementando, personalizando e solucionando problemas do SAP Fiori em fábricas, centros de serviços compartilhados e redes de logística globais. Sentei ao lado de funcionários de contas a pagar que resmungavam baixinho toda vez que uma busca retornava zero resultados. Vi supervisores de armazém pegarem uma planilha – sim, uma planilha – porque o aplicativo Fiori no tablet travou pela terceira vez naquele turno. E tive a conversa desconfortável com um diretor de TI que havia passado dezoito meses implementando o Fiori para quatro mil usuários, apenas para descobrir que a adoção estava estagnada em trinta por cento.

O SAP Fiori deveria resolver o UX empresarial. Em 2013, quando a SAP o lançou, a proposta era convincente: uma interface consistente, baseada em funções e com qualidade de consumidor que faria o ERP parecer tão intuitivo quanto um smartphone. Em 2026, essa promessa ainda soa muito bem nas apresentações de vendas. A realidade no chão de fábrica é, educadamente, mais complicada.

Este artigo não é uma crítica destrutiva à SAP. Respeito a engenharia que é investida nesses produtos e o progresso genuíno que a empresa fez ao longo dos anos. Mas também acredito que a honestidade serve melhor aos consultores SAP e líderes de TI do que o otimismo exagerado. Então, deixe-me explicar exatamente onde o Fiori ainda decepciona os usuários em 2026, por que corrigi-lo de dentro da plataforma é tão difícil e – o mais importante – como os copilotos de IA estão começando a preencher essa lacuna de maneiras práticas, mensuráveis e implementáveis hoje.

A Promessa vs. a Realidade do SAP Fiori

Quando a SAP lançou o Fiori, a filosofia de design era baseada em cinco princípios: baseado em funções, responsivo, simples, coerente e agradável. Estes são bons princípios. São os princípios certos. O problema é que o software empresarial não existe em laboratório – ele existe dentro de organizações com décadas de dívida de customização, hierarquias de autorização complexas, restrições de desempenho de hardware on-premise e requisitos de integração que nunca foram projetados com uma UI mobile-first em mente.

Na minha experiência trabalhando com mais de trinta clientes SAP empresariais na Europa e no Oriente Médio, posso contar nos dedos de uma mão o número de implementações Fiori onde os usuários descreveram sua experiência diária como genuinamente fluida. A maioria dos usuários descreve o Fiori da mesma forma que descreve seu trajeto diário: leva-os aonde precisam ir, na maioria das vezes, mas não é algo que eles esperam com entusiasmo.

A lacuna entre a narrativa de marketing do Fiori e a experiência vivida pelo usuário se resume a algumas tensões estruturais que a SAP nunca resolveu totalmente:

• O Fiori foi projetado para a pureza do S/4HANA, mas a maioria das organizações não é puramente S/4HANA. Ambientes híbridos — ECC ao lado de S/4HANA, nuvem ao lado de on-premise — criam falhas que a UI não consegue esconder com elegância.
• A personalização quebra a coerência. No momento em que um cliente começa a adaptar tiles, workflows e campos do Fiori para corresponder aos seus processos de negócio, a experiência "consistente" começa a se fragmentar. Manter essa coerência entre as atualizações é caro e muitas vezes é despriorizado.
• O desempenho do Fiori depende de uma infraestrutura na qual muitas organizações subinvestem. O servidor front-end, os serviços OData, o backend ABAP — cada camada pode introduzir latência, e essa latência se acumula.

Nada disso significa que o Fiori é um fracasso. É, na maioria das medidas, uma melhoria significativa em relação ao SAP GUI que substituiu para muitos tipos de transações. Mas melhoria significativa não é o mesmo que um problema resolvido, e em 2026 o nível para o UX empresarial aumentou drasticamente. Os usuários agora comparam seu software de trabalho a ferramentas como Notion, Slack e Copilot no Microsoft 365. O Fiori, mesmo no seu melhor, não pode competir nessa dimensão sem aumento externo.

Os 5 Principais Padrões de Falha no UX do Fiori

Permita-me ser específico. Reclamações vagas sobre "UX ruim" não ajudam ninguém. Aqui estão os cinco padrões de falha que encontro com mais consistência nos meus clientes, com exemplos concretos de como eles se manifestam.

1. Tempos de Carregamento Lentos que Destroem a Produtividade

A reclamação mais universal que ouço dos usuários do Fiori é o tempo de carregamento. Não são travamentos catastróficos — apenas lentidão. Um oficial de compras espera de quatro a seis segundos para que o aplicativo Gerenciar Pedidos de Compra seja renderizado. Um gerente espera três segundos para que o tile Minha Caixa de Entrada carregue após aprovar um documento. Ao longo de um dia de trabalho completo, isso soma de quinze a vinte minutos de espera passiva — tempo que corrói tanto a produtividade quanto a boa vontade em relação ao sistema.

As causas raiz variam: serviços OData mal otimizados, índices ausentes em views CDS, configuração de cache insuficiente no SAP Web Dispatcher, ou simplesmente um servidor de aplicativos que está fazendo muito. A solução está quase sempre no lado da infraestrutura ou do backend, não na camada da UI — o que significa que ela foge da alçada da equipe Fiori e é despriorizada no backlog de lançamentos.

Certa vez, fiz uma auditoria de desempenho para um fornecedor automotivo alemão e descobri que o aplicativo Fiori mais usado por eles — uma tela personalizada de confirmação de recebimento de mercadorias — estava fazendo onze chamadas OData separadas no carregamento inicial. Os desenvolvedores originais o haviam construído dessa forma porque era o caminho de menor resistência no SAPUI5. Ninguém havia revisado isso de uma perspectiva de rede. Combinar essas chamadas em duas reduziu o tempo de carregamento de 5,2 segundos para 1,1 segundos. A correção levou três dias. O problema existia há dois anos.

2. Campos de Entrada Obrigatórios que Bloqueiam Buscas Significativas

A busca do Fiori — particularmente em aplicativos transacionais mais antigos — força os usuários a inserir valores de campo específicos antes que o sistema retorne resultados. Acesse o aplicativo Exibir Pedido de Compra em muitos sistemas S/4HANA e tente procurar por todos os pedidos de compra feitos nos últimos sete dias sem saber o número do fornecedor ou o número do documento antecipadamente. Em muitas configurações padrão, a busca não retorna nada, ou pior, força você de volta a uma tela de seleção que parece indistinguível da transação ME23N do SAP GUI.

Esta é uma falha de UX que está enraizada na arquitetura. Os serviços OData subjacentes frequentemente exigem que certos campos sejam preenchidos porque os módulos de função ABAP que eles chamam foram projetados para buscas precisas, não para buscas exploratórias. Relaxar essas restrições sem reescrever a lógica do backend arrisca problemas de desempenho em escala. Então, a restrição persiste, e os usuários desenvolvem soluções alternativas — geralmente envolvendo um colega que conhece os parâmetros de busca mágicos, ou um relatório personalizado que ignora o Fiori completamente.

3. Busca que Retorna Zero Resultados

Relacionado, mas distinto: a funcionalidade de busca do Fiori — tanto dentro dos aplicativos quanto na busca global — é frágil de maneiras que frustram os usuários diariamente. Correspondências parciais frequentemente falham. Erros de digitação são imperdoáveis. Buscar por "Müller" quando o sistema armazena "Mueller" não retorna nada. Buscar por um nome de fornecedor parcial em um sistema onde a busca difusa não foi habilitada não retorna nada. Buscar por um parceiro de negócios pelo seu endereço de e-mail em um aplicativo Fiori padrão não retorna nada, porque o índice de busca não foi configurado para incluir esse campo.

Vi usuários desenvolverem rituais de busca pessoais elaborados: eles mantêm um favorito do navegador para um relatório personalizado, mantêm uma planilha pessoal de números de fornecedores, ou perguntam a um colega que "conhece o sistema" toda vez que precisam encontrar um registro desconhecido. Essas soluções alternativas são invisíveis para a liderança de TI, mas profundamente custosas no agregado.

4. Falhas em Aplicativos Móveis e Falhas Offline

A SAP investiu pesadamente em seu portfólio mobile — SAP Mobile Start, SAP Fiori Client e vários aplicativos nativos construídos na pilha de SAP BTP Mobile Services. Em demonstrações controladas, eles funcionam bem. Em ambientes de produção, particularmente em indústrias onde o uso móvel é crítico (logística, serviço de campo, manufatura), a experiência é mais instável.

Modos de falha comuns que documentei em diversos clientes incluem: o aplicativo SAP Fiori Client travando ao alternar entre múltiplos sistemas de backend; recursos offline falhando ao sincronizar corretamente quando o dispositivo se reconecta à rede; notificações push para aprovações de workflow chegando horas depois que a aprovação já foi concluída por outra pessoa; e o layout mobile de alguns aplicativos Fiori simplesmente renderizando mal em telas de tamanhos não padrão porque os pontos de interrupção responsivos nunca foram testados em dispositivos reais usados em campo.

Um cliente de logística meu na Holanda implementou o Fiori mobile para seus supervisores de armazém em 2024. Em três meses, dois terços dos supervisores haviam voltado aos processos baseados em papel para recebimento de mercadorias porque o aplicativo era "não confiável". Isso não é uma falha tecnológica em abstrato — é um problema de continuidade de negócios com um custo mensurável.

5. Caos de Visibilidade de Tiles Baseado em Funções

O launchpad do Fiori deveria mostrar aos usuários exatamente os tiles relevantes para sua função. Em teoria, isso é elegante: um escriturário de compras vê aplicativos de compras, um gerente financeiro vê aplicativos financeiros, e ninguém vê nada que não deveria. Na prática, o acesso baseado em funções na maioria dos sistemas SAP empresariais é uma bagunça de legado que se acumulou ao longo de anos de mudanças organizacionais, adições de projetos e autorizações de contorno.

O que eu geralmente vejo: usuários com quinze a vinte tiles em seu launchpad, dos quais eles usam três regularmente. Usuários que não conseguem encontrar um aplicativo de que precisam porque foi atribuído a um nome de função ligeiramente diferente. Usuários que receberam acesso temporário a um tile durante um projeto e agora não conseguem removê-lo sem uma solicitação formal de mudança de TI. Usuários em funções compartilhadas que veem tiles que são relevantes apenas para um subconjunto de seus colegas, criando confusão sobre o que eles deveriam fazer com eles.

A sobrecarga administrativa de gerenciar atribuições de funções do Fiori — particularmente em grandes populações de usuários com hierarquias de funções complexas — é substancial, e a maioria das organizações não possui as ferramentas para fazer isso de forma inteligente em escala.

Por Que a SAP Luta Para Corrigir Isso Internamente

Quero ser justo aqui, porque os desafios que a SAP enfrenta para melhorar o UX do Fiori são realmente difíceis. Não se trata de indiferença corporativa — é um caso de restrições arquitetônicas que não têm soluções simples.

A lógica de negócios central da SAP reside no ABAP — uma linguagem e tempo de execução que é extraordinariamente capaz de processar grandes volumes de transações de negócios de forma confiável, mas que foi projetada em uma era em que a UI era uma reflexão tardia. Os serviços OData dos quais o Fiori depende são, na maioria dos casos, wrappers em torno de módulos de função ABAP e BAPIs que nunca foram projetados para suportar o tipo de interações flexíveis, exploratórias e de baixa latência que o UX moderno exige.

Reescrever esses serviços do zero — substituindo-os por APIs nativas da nuvem construídas no SAP BTP, por exemplo — é exatamente o que a SAP está fazendo com o S/4HANA Cloud e sua estratégia de Clean Core. Mas essa transição levará anos para a maioria das organizações, e, enquanto isso, as restrições de legado permanecem. A customização adiciona outra camada de complexidade: cada modificação do cliente em um aplicativo Fiori cria uma carga de manutenção que torna as atualizações mais arriscadas e retarda a adoção das próprias melhorias de UX da SAP.

O resultado é uma plataforma que está melhorando no ritmo de um grande fornecedor de software empresarial — medida, cuidadosa, compatível com versões anteriores — enquanto as expectativas dos usuários estão avançando no ritmo da tecnologia de consumo. A lacuna é estrutural e não será fechada apenas por meio de lançamentos incrementais da plataforma.

Como os Copilotos de IA Abordam Cada Padrão de Falha

É aqui que as coisas ficam realmente interessantes. Os copilotos de IA — sejam eles o Joule da própria SAP, agentes LLM personalizados integrados via SAP BTP, ou soluções híbridas que combinam ChatGPT ou Gemini com APIs SAP — podem abordar as falhas de UX do Fiori de maneiras que não exigem a reescrita da arquitetura subjacente. Eles contornam as restrições adicionando uma camada inteligente por cima.

Resolvendo Tempos de Carregamento Lentos com Pré-busca Preditiva

Copilotos de IA com acesso a dados de comportamento do usuário podem prever quais aplicativos um usuário provavelmente abrirá e pré-buscar os dados relevantes antes que o usuário navegue até lá. Se um oficial de compras abre o aplicativo Gerenciar Pedidos de Compra todas as manhãs às 8:15 e filtra por um grupo de compras específico, um agente preditivo pode acionar essa chamada OData em segundo plano às 8:10, para que os dados estejam em cache e prontos quando o usuário chegar.

Esta não é uma capacidade hipotética — é um padrão que foi implementado usando o Application Router do SAP BTP combinado com um modelo ML leve treinado em logs de sessão do usuário. A implementação se parece aproximadamente com isto:

// BTP Application Router: predictive prefetch middleware
app.use('/sap/opu/odata/', async (req, res, next) => {
  const userId = req.user?.id;
  const currentHour = new Date().getHours();

  // Query prediction model for likely next navigation
  const prediction = await prefetchModel.predict({
    userId,
    currentHour,
    lastVisitedApp: sessionStore.get(userId)?.lastApp
  });

  if (prediction.confidence > 0.75) {
    // Warm the OData cache for the predicted next app
    prefetchCache.warmAsync(prediction.entitySetUrl, userId);
  }

  next();
});

Em uma implementação que revisei em uma empresa de manufatura holandesa, essa abordagem reduziu o tempo de carregamento percebido para os três aplicativos mais usados em uma média de 2,8 segundos — não tornando os aplicativos mais rápidos, mas tornando a espera invisível.

Resolvendo Restrições de Campos Obrigatórios com Preenchimento de Formulários Assistido por IA

Quando uma busca requer um número de fornecedor e o usuário não o sabe, um copiloto de IA pode resolver a restrição conversacionalmente. Em vez de o usuário chegar a um beco sem saída, ele digita "mostrar pedidos de compra da Siemens na semana passada" e o copiloto resolve "Siemens" para o número do fornecedor, infere o intervalo de datas, preenche os campos obrigatórios e envia a busca em nome do usuário.

O SAP Joule faz exatamente isso para um conjunto crescente de aplicativos padrão. Para aplicativos personalizados, o mesmo padrão pode ser implementado usando um LLM de chamada de função que recebeu acesso a um conjunto de APIs SAP:

# Exemplo: Definição de função LLM para busca de fornecedor
functions = [
  {
    "name": "resolve_vendor",
    "description": "Resolve um nome de fornecedor ou nome parcial para um número de fornecedor SAP",
    "parameters": {
      "type": "object",
      "properties": {
        "vendor_name": {
          "type": "string",
          "description": "O nome do fornecedor ou nome parcial fornecido pelo usuário"
        },
        "company_code": {
          "type": "string",
          "description": "Código da empresa opcional para refinar a busca"
        }
      },
      "required": ["vendor_name"]
    }
  }
]

# O LLM resolve a intenção do usuário, chama a função,
# então preenche os campos de busca do Fiori programaticamente
# via API SAP UI5 ou um agente de automação no lado BTP

Resolvendo Busca com Zero Resultados com Correspondência Semântica e Difusa

Camadas de busca alimentadas por IA podem se posicionar na frente da busca nativa do Fiori e traduzir consultas de usuário em buscas estruturadas que realmente retornam resultados. Um usuário que busca por "faturas Mueller acima de 50k" obtém resultados porque a camada de IA lida com a resolução da variante do nome ("Mueller" / "Müller"), entende o filtro de valor como uma restrição numérica e mapeia "faturas" para o tipo de documento apropriado no SAP.

A própria Enterprise Search da SAP e a interface de linguagem natural Joule movem-se nessa direção para conteúdo padrão. Para organizações que precisam estender isso para objetos personalizados e tabelas Z, construir uma camada de busca semântica no BTP usando embeddings vetoriais de dados mestre SAP — indexados diariamente do S/4HANA — é uma abordagem prática que vários dos meus clientes estão agora executando em produção.

Resolvendo Falhas Móveis com Agentes de IA Offline-First

As falhas do Fiori mobile são frequentemente falhas de sincronização: o aplicativo não sabe o que fazer quando perde a conectividade, ou faz suposições incorretas sobre o estado dos dados quando se reconecta. Agentes de IA podem gerenciar isso de forma mais inteligente, mantendo um modelo de estado local, enfileirando ações feitas offline com lógica de resolução de conflitos e alertando proativamente os usuários quando um problema de sincronização requer julgamento humano, em vez de falhar silenciosamente.

Os SAP BTP Mobile Services agora incluem hooks de resolução de conflitos que podem ser estendidos com lógica personalizada. Uma camada de IA pode classificar conflitos — "este recebimento de mercadorias foi lançado por um colega enquanto você estava offline; você deseja cancelar o seu ou escalar?" — em vez de deixar o usuário com uma mensagem de erro criptografada.

Resolvendo o Caos da Visibilidade de Tiles com Recomendações de Funções por IA

A gestão de funções no Fiori é fundamentalmente um problema de dados: a maioria das organizações não possui dados limpos e atualizados sobre quais funções os usuários realmente precisam versus quais funções lhes foram atribuídas. A IA pode ajudar analisando padrões de uso reais — quais tiles cada usuário abre, com que frequência e em que contexto — e apresentando recomendações tanto para usuários quanto para administradores.

Para os usuários, isso se parece com um launchpad personalizado que exibe os três aplicativos que eles provavelmente precisarão no momento, com base na hora do dia, carga de trabalho atual e comportamento histórico. Para os administradores, isso se parece com um painel de detecção de anomalias que sinaliza usuários com funções atribuídas que nunca usaram (potenciais candidatos a desprovisionamento) e usuários que frequentemente navegam para fora do Fiori para realizar tarefas que sugerem uma atribuição de tile ausente.

Falha de UX do Fiori vs. Solução de Copiloto de IA: Uma Comparação

O Caso do Fechamento Mensal: De 40 Cliques para 3 Comandos

O exemplo mais instrutivo que posso dar sobre o que um copiloto de IA realmente faz no UX do Fiori vem de uma controladora com quem trabalhei em uma empresa de manufatura de médio porte na Alemanha — 1,4 bilhão de euros em receita anual, S/4HANA on-premise, três códigos de empresa para gerenciar.

Sua rotina de fechamento mensal era uma ilustração clássica da falha do Fiori em escala. A sequência específica que cronometrei: verificar acréscimos em aberto, verificar se todas as contas de compensação GR/IR estavam reconciliadas e identificar quaisquer itens grandes não lançados antes que o período fosse bloqueado.

No Fiori, isso significava navegar por quatro aplicativos separados — Visão Geral de Relatórios Financeiros, um tile de acréscimos personalizado, Análise de Compensação GR/IR e o Monitor de Fechamento de Período. Cada aplicativo exigia sua própria configuração de filtro, e cada um exigia que a controladora transportasse manualmente o contexto de um para o próximo. Contei 22 minutos por código de empresa, 66 minutos para todos os três — feito duas vezes ao dia durante os últimos três dias úteis de cada mês.

Isso representa 6 horas por mês de tempo de um profissional financeiro sênior gasto clicando na navegação do aplicativo. Não analisando, não decidindo, não se comunicando com o negócio. Apenas clicando.

A Implementação do Copiloto de IA

A camada do copiloto levou três semanas para ser construída: um middleware Python chamando APIs OData para acréscimos (via serviço OData personalizado), itens GR/IR (API_PURCHASING_DOCUMENT_SRV) e status de período aberto (wrapper BAPI personalizado). O LLM recebeu um prompt de sistema específico para finanças e os esquemas de função para cada API. Aqui está a interação que substituiu 66 minutos de navegação no Fiori:

Usuário: "Executar minha verificação de fechamento mensal para as empresas 1000, 2000, 3000"

[Copiloto chama 4 endpoints OData sequencialmente, ~12 segundos no total]

Resposta:
------------------------------------------------------------------
STATUS DO FECHAMENTO MENSAL | 28/03/2026 | 3 dias para o fechamento do período

EMPRESA 1000 (DE): AÇÃO NECESSÁRIA
  Acréscimos não confirmados: 3 itens (maior: EUR 340.000 — Fornecedor 100234)
  GR/IR não compensado: 12 itens, EUR 89.450 (mais antigo: 45 dias)
  --> Revisar acréscimo 900001234 antes do corte

EMPRESA 2000 (AT): OK
  GR/IR não compensado: 4 itens, EUR 12.300 (dentro da tolerância)
  Nenhum acréscimo exigindo ação

EMPRESA 3000 (CH): OK
  1 acréscimo pendente (EUR 15.000) — baixo risco

Próximo passo: Mostrar detalhes do acréscimo para a Empresa 1000, ou exportar lista completa de GR/IR?
------------------------------------------------------------------

Usuário: "Mostrar detalhes do acréscimo para 1000"

[Mais uma chamada de API, 3 segundos]

Resposta: Acréscimo 900001234 | EUR 340.000 | Pedido de Serviço 4500089234
  Fornecedor: Logistics Partner AG | Lançado: 01/03/2026
  Prazo de confirmação: 29/03/2026 (amanhã)
  Contato: comprador.nome@empresa.com
  Ação sugerida: Enviar e-mail ao comprador para confirmar ou reverter até o final do dia de amanhã
------------------------------------------------------------------

Três entradas do usuário. Menos de dois minutos. A controladora revisou as mesmas informações que antes levavam 66 minutos de navegação no Fiori, e o fez com maior confiança porque o resumo destacou a exceção que exigia atenção humana, em vez de exigir que ela a encontrasse em quatro telas de aplicativo separadas.

Anualizado, isso recuperou aproximadamente 72 horas de tempo de um profissional financeiro sênior por ano para este único processo — a EUR 110 por hora totalmente carregada, isso representa EUR 7.920 em tempo produtivo recuperado anualmente. A camada do copiloto custou aproximadamente EUR 15.000 para ser construída e EUR 2.400 por ano para operar em custos de API LLM e hospedagem. O retorno sobre o investimento foi positivo em 26 meses neste único caso de uso, com a mesma infraestrutura disponível para outros processos sem custo adicional de construção.

Por Que Isso Funciona: O Princípio de Design

A razão pela qual este estudo de caso é repetível é o princípio de design subjacente: o copiloto de IA lida com a recuperação de dados e o reconhecimento de padrões; o humano faz todo o julgamento e toma todas as ações. O copiloto não lança acréscimos, não compensa itens GR/IR, não bloqueia o período. Ele destaca as exceções que exigem atenção humana e as apresenta em um formato que reduz a carga cognitiva de encontrá-las.

Este é o enquadramento correto para copilotos de IA em ambientes SAP. Não é a automação do julgamento. É a automação da navegação que sempre foi o custo indireto do julgamento.

Implementação Real: Antes e Depois com Métricas

Quero compartilhar um estudo de caso composto baseado em trabalhos nos quais estive envolvido nos últimos dezoito meses — detalhes anonimizados, mas os números são reais.

O cliente é um grupo de manufatura pan-europeu com aproximadamente 4.200 usuários Fiori nas áreas de compras, finanças e logística. Eles concluíram sua migração para S/4HANA em 2023 e estavam frustrados porque a adoção do Fiori havia estagnado em cerca de 38% de sua população de usuários pretendida. O restante estava usando uma combinação de transações SAP GUI, relatórios personalizados e soluções alternativas. A liderança de TI identificou três causas raiz: frustração com a busca, desempenho lento nos aplicativos de pedidos de compra e confusão sobre o launchpad para usuários cujas funções haviam mudado recentemente durante uma reorganização.

Fase 1: Camada de Busca Alimentada por IA (Q1 2025)

Implementamos uma camada de busca semântica construída no SAP BTP, usando embeddings vetoriais indexados diariamente de dados mestres de fornecedor, material e cliente. A interface de busca foi exposta como um tile Fiori personalizado no launchpad — uma única caixa de busca, sem campos obrigatórios, suportando consultas em linguagem natural.

Antes: Sessão de busca média resultando em um registro encontrado com sucesso: 3 minutos e 40 segundos. Os usuários relatavam 2,1 buscas falhas por dia, em média.

Depois (90 dias após a implementação): Sessão de busca bem-sucedida média: 48 segundos. Buscas falhas por usuário por dia: 0,4. Tickets de suporte relacionados a "não consigo encontrar fornecedor/material/cliente": redução de 62%.

Fase 2: Pré-busca Preditiva para os 10 Principais Aplicativos (Q2 2025)

Instrumentamos o SAP BTP Application Router para registrar eventos de navegação anonimizados e treinamos um modelo leve de gradient boosting (atualizado semanalmente) para prever o próximo aplicativo para o qual um usuário navegaria, dado seu papel, hora atual e os três últimos passos de navegação. A pré-busca foi acionada para previsões com confiança acima de 70%.

Antes: Tempo médio de carregamento para os cinco aplicativos mais usados: 4,1 segundos.

Depois: Tempo de carregamento percebido (tempo do clique até a interatividade): 1,3 segundos para carregamentos pré-buscados, que representaram 67% de todas as navegações. Tempo médio de carregamento percebido geral: 1,9 segundos.

Fase 3: Personalização do Launchpad Alimentada por IA (Q3 2025)

Implementamos um motor de personalização que analisou 90 dias de histórico de uso para cada usuário e reordenou seus tiles do launchpad por relevância prevista, exibindo uma seção de "Acesso Rápido" com os três aplicativos mais contextualmente relevantes no topo do launchpad. Os usuários podiam substituir as recomendações com um único clique.

Antes: Número médio de cliques para chegar ao aplicativo correto a partir do launchpad: 3,2 (incluindo tiles errados clicados e navegação de volta).

Depois: 1,4 cliques em média. Pontuação de satisfação do usuário para o launchpad (escala de 1 a 5, medida por micro-pesquisas incorporadas): de 2,1 para 3,8.

Impacto Combinado Após 12 Meses

A adoção do Fiori entre a população de usuários aumentou de 38% para 71%. A equipe de TI estimou que isso representou aproximadamente €1,2 milhão em recuperação anual de produtividade — com base no tempo anteriormente gasto em soluções alternativas e buscas falhas, valorizado pelos custos totais de pessoal. As três camadas de IA custaram aproximadamente €180.000 para serem construídas e implementadas ao longo do período de doze meses, mais €40.000 por ano em infraestrutura e manutenção contínuas do BTP. O cálculo do ROI foi direto o suficiente para que o CFO aprovasse um roteiro da Fase 2 em trinta dias após ver os números de doze meses.

Joule, Integrações ChatGPT-SAP e Agentes LLM Personalizados: O Que Realmente Muda

Vale a pena ser preciso sobre o cenário de ferramentas de IA em 2026, porque o ruído de marketing é considerável e as capacidades reais diferem significativamente.

SAP Joule é o copiloto de IA generativa nativo da SAP, incorporado em S/4HANA Cloud, SuccessFactors, Ariba e outros produtos SAP na nuvem. Sua principal vantagem é a integração nativa e estreita com dados e processos SAP — ele entende o modelo de dados da SAP, respeita as autorizações SAP e pode realizar ações em fluxos de trabalho SAP sem exigir código de integração de API personalizado. Sua limitação é o escopo: em 2026, as capacidades de linguagem natural do Joule são excelentes para um conjunto definido de cenários padrão e mais fracas para objetos personalizados, transações Z e processos altamente específicos da indústria. Também requer licenciamento SAP Business AI além da sua assinatura SAP existente.

Integrações ChatGPT-SAP (e padrões equivalentes usando Claude, Gemini ou LLMs de código aberto) oferecem muito mais flexibilidade no que você pode fazer, mas exigem significativamente mais trabalho de integração. Você está construindo a "cola": APIs SAP, middleware BTP, autenticação, controles de privacidade de dados e a própria interface conversacional. A vantagem é que você pode adaptar o comportamento da IA precisamente aos processos e ao modelo de dados da sua organização. O risco é que você seja responsável pela manutenção de uma pilha de integração personalizada em um cenário de fornecedores que está evoluindo rapidamente.

Agentes LLM personalizados no BTP — um padrão cada vez mais comum entre grandes clientes SAP — situam-se entre esses dois extremos. Você hospeda o LLM no SAP BTP (ou chama uma API LLM externa do BTP), o envolve com os serviços de segurança e conectividade do BTP e constrói integrações de chamada de função contra seus serviços OData S/4HANA. Isso oferece uma profundidade de integração semelhante ao Joule com a flexibilidade de um LLM personalizado. O custo operacional é maior do que usar o Joule, mas para organizações com