Por Que o SAP Fiori Continua a Falhar os Utilizadores (E Como os Copilotos IA Resolvem)

Passei grande parte da última década a implementar, personalizar e resolver problemas do SAP Fiori em fábricas, centros de serviços partilhados e redes logísticas globais. Estive ao lado de assistentes de contas a pagar que resmungavam sempre que uma pesquisa devolvia zero resultados. Vi supervisores de armazém a puxar uma folha de cálculo — sim, uma folha de cálculo — porque a app Fiori no tablet tinha bloqueado pela terceira vez naquele turno. E tive a conversa desconfortável com um diretor de IT que acabava de investir dezoito meses a implementar o Fiori em quatro mil utilizadores, apenas para descobrir que a adoção tinha estagnado em trinta por cento.

O SAP Fiori deveria resolver a UX empresarial. Em 2013, quando a SAP o apresentou, o argumento era convincente: uma interface consistente, baseada em papéis e de nível consumer que tornaria o ERP tão intuitivo quanto um smartphone. Em 2026, essa promessa ainda aterra perfeitamente nos argumentários de vendas. A realidade no chão de fábrica é, educadamente, mais complicada.

Este artigo não é um ataque à SAP. Respeito a engenharia que existe por detrás destes produtos e o progresso genuíno que a empresa fez ao longo dos anos. Mas também acredito que a honestidade serve melhor os consultores SAP e os líderes de IT do que o entusiasmo acrítico. Deixem-me então explicar exatamente onde o Fiori ainda falha os utilizadores em 2026, porque é tão difícil corrigi-lo desde dentro da plataforma e — mais importante — como os copilotos IA estão a começar a preencher essa lacuna de formas 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 assentava em cinco princípios: baseado em papéis, responsivo, simples, coerente e satisfatório. São bons princípios. São os princípios certos. O problema é que o software empresarial não existe num laboratório — existe dentro de organizações com décadas de dívida de personalização, hierarquias de autorização complexas, restrições de desempenho de hardware on-premise e integrações que nunca foram concebidas a pensar numa UI mobile-first.

Na minha experiência a trabalhar com mais de trinta clientes empresariais SAP na Europa e no Médio Oriente, consigo contar pelos dedos de uma mão as implementações do Fiori onde os utilizadores descreveram a sua experiência diária como genuinamente fluida. A maioria descreve o Fiori da mesma forma que descreve o seu trajeto para o trabalho: leva-os onde precisam de ir, na maior parte do tempo, mas não é algo que esperem com entusiasmo.

A diferença entre o discurso de marketing do Fiori e a experiência real do utilizador resume-se a algumas tensões estruturais que a SAP nunca resolveu completamente:

• O Fiori foi concebido para a pureza do S/4HANA, mas a maioria das organizações não é puramente S/4HANA. Os landscapes híbridos — ECC ao lado do S/4HANA, cloud ao lado de on-premise — criam costuras 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 os tiles, workflows e campos do Fiori aos seus processos de negócio, a experiência "consistente" começa a fragmentar-se. Manter essa coerência entre atualizações é caro e frequentemente desvalorizado.
• O desempenho do Fiori depende de infraestrutura em que muitas organizações investem insuficientemente. O servidor frontend, os serviços OData, o backend ABAP — cada camada pode introduzir latência, e essa latência acumula-se.

Nada disto significa que o Fiori é um fracasso. É, pela maioria das métricas, 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 problema resolvido, e em 2026 o padrão para a UX empresarial subiu consideravelmente. Os utilizadores comparam agora o seu software de trabalho com ferramentas como o Notion, o Slack e o Copilot no Microsoft 365. O Fiori, mesmo no seu melhor, não consegue competir nessa dimensão sem aumentação externa.

Os 5 Padrões de Falha de UX do Fiori

Sejamos específicos. Queixas vagas sobre "má UX" não ajudam ninguém. Estes são os cinco padrões de falha que encontro de forma mais consistente ao longo dos projetos com clientes, com exemplos concretos de como se manifestam.

1. Tempos de Carregamento Lentos que Destroem a Produtividade

A queixa mais universal que ouço dos utilizadores do Fiori é o tempo de carregamento. Não falhas catastróficas — apenas lentidão. Um responsável de compras espera entre quatro e seis segundos para que a app Gerir Ordens de Compra seja renderizada. Um gestor espera três segundos para que o tile A Minha Caixa de Entrada carregue após aprovar um documento. Ao longo de um dia de trabalho completo, isto soma quinze a vinte minutos de espera passiva — tempo que corrói tanto a produtividade como a boa vontade para com o sistema.

As causas raiz variam: serviços OData mal ajustados, índices em falta nas CDS views, configuração de cache insuficiente no SAP Web Dispatcher, ou simplesmente um servidor de aplicações sobrecarregado. A correção está quase sempre na infraestrutura ou no lado do backend, não na camada de UI — o que significa que fica fora do âmbito da equipa Fiori e é desvalorizado no backlog de versões.

Uma vez realizei uma auditoria de desempenho para um fabricante automóvel alemão e descobri que a sua app Fiori mais utilizada — um ecrã de confirmação de entrada de mercadorias personalizado — fazia onze chamadas OData separadas no carregamento inicial. Os programadores originais tinham-na construído assim porque era o caminho de menor resistência no SAPUI5. Ninguém a tinha revisto numa perspetiva de rede. Combinar essas chamadas em duas reduziu o tempo de carregamento de 5,2 segundos para 1,1 segundos. A correção demorou três dias. O problema existia há dois anos.

2. Campos Obrigatórios que Bloqueiam a Pesquisa Significativa

A pesquisa no Fiori — especialmente nas apps transacionais mais antigas — obriga os utilizadores a introduzir valores de campo específicos antes de o sistema devolver resultados. Vá à app Visualizar Ordem de Compra em muitos sistemas S/4HANA e tente pesquisar todas as ordens criadas nos últimos sete dias sem saber antecipadamente o número do fornecedor ou o número do documento. Em muitas configurações padrão, a pesquisa não devolve nada, ou pior, força o utilizador de volta para um ecrã de seleção indistinguível da transação ME23N do SAP GUI.

Esta é uma falha de UX integrada na arquitetura. Os serviços OData subjacentes frequentemente exigem que determinados campos estejam preenchidos porque os módulos de função ABAP que chamam foram concebidos para pesquisas precisas, não para pesquisas exploratórias. Relaxar essas restrições sem reescrever a lógica do backend arriscaria problemas de desempenho em escala. Assim, a restrição persiste e os utilizadores desenvolvem alternativas — habitualmente um colega que conhece os parâmetros de pesquisa mágicos, ou um relatório personalizado que contorna o Fiori completamente.

3. Pesquisa que Não Devolve Resultados

Relacionado mas distinto: a funcionalidade de pesquisa do Fiori — tanto dentro das apps como na pesquisa global — é frágil de formas que frustram os utilizadores diariamente. As correspondências parciais frequentemente falham. Os erros tipográficos são imperdoáveis. Pesquisar "Müller" quando o sistema armazena "Mueller" não devolve nada. Pesquisar por um nome de fornecedor parcial num sistema onde a pesquisa difusa não foi ativada não devolve nada. Pesquisar um business partner pelo seu endereço de email numa app padrão do Fiori não devolve nada, porque o índice de pesquisa não foi configurado para incluir esse campo.

Vi utilizadores a desenvolver elaborados rituais pessoais de pesquisa: guardam um marcador de browser para um relatório personalizado, mantêm uma folha de cálculo pessoal com números de fornecedor, ou perguntam a um colega que "conhece o sistema" sempre que precisam de encontrar um registo desconhecido. Estas alternativas são invisíveis para a liderança de IT mas enormemente dispendiosas no conjunto.

4. Falhas da App Móvel e Falhas Offline

A SAP investiu muito no seu portfolio móvel — SAP Mobile Start, o SAP Fiori Client e várias apps nativas construídas sobre o stack SAP BTP Mobile Services. Em demonstrações controladas funcionam bem. Em ambientes de produção, especialmente em setores onde a utilização móvel é crítica (logística, serviço de campo, fabricação), a experiência é mais instável.

Os modos de falha comuns que documentei em instalações de clientes incluem: a app SAP Fiori Client a bloquear ao alternar entre múltiplos sistemas backend; as capacidades offline a não sincronizar corretamente quando o dispositivo se volta a ligar à rede; notificações push para aprovações de workflow a chegar horas depois de a aprovação já ter sido concluída por outra pessoa; e o layout móvel de algumas apps Fiori a renderizar mal em tamanhos de ecrã não padrão porque os breakpoints responsivos nunca foram testados nos dispositivos reais utilizados no terreno.

Um cliente de logística meu nos Países Baixos implementou o Fiori móvel para os seus supervisores de armazém em 2024. Em três meses, dois terços dos supervisores tinham voltado a processos baseados em papel para as entradas de mercadorias porque a app era "pouco fiável". Isso não é uma falha tecnológica em abstrato — é um problema de continuidade de negócio com um custo mensurável.

5. Caos de Visibilidade de Tiles por Papéis

O launchpad do Fiori supostamente mostra aos utilizadores exatamente os tiles relevantes para o seu papel. Em teoria, é elegante: um assistente de compras vê as apps de compras, um gestor financeiro vê as apps de finanças, e ninguém vê o que não deveria. Na prática, o acesso baseado em papéis na maioria dos sistemas SAP empresariais é uma confusão herdada que se foi acumulando ao longo de anos de mudanças organizacionais, adições de projetos e autorizações de emergência.

O que tipicamente encontro: utilizadores com quinze a vinte tiles no launchpad, dos quais utilizam três regularmente. Utilizadores que não conseguem encontrar uma app de que precisam porque foi atribuída a um nome de papel ligeiramente diferente. Utilizadores que receberam acesso temporário a um tile durante um projeto e agora não o conseguem remover sem um pedido formal de mudança à IT. Utilizadores em papéis partilhados que veem tiles que só são relevantes para um subconjunto dos seus colegas, criando confusão sobre o que se supõe que devem fazer com eles.

A carga administrativa de gerir as atribuições de papéis no Fiori — especialmente em grandes populações de utilizadores com hierarquias de papéis complexas — é considerável, e a maioria das organizações carece de ferramentas para o fazer de forma inteligente em escala.

Porque é que a SAP Tem Dificuldade em Resolver Isto a Partir de Dentro

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

A lógica de negócio principal da SAP reside no ABAP — uma linguagem e runtime extraordinariamente capaz para processar grandes volumes de transações de negócio de forma fiável, mas concebido numa época em que a UI era uma reflexão tardia. Os serviços OData de que o Fiori depende são, na maioria dos casos, wrappers em torno de módulos de função ABAP e BAPIs que nunca foram concebidos para suportar o tipo de interações flexíveis, exploratórias e de baixa latência que a UX moderna exige.

Reescrever esses serviços do zero — substituí-los por APIs cloud-native construídas sobre o SAP BTP, por exemplo — é exatamente o que a SAP está a fazer com o S/4HANA Cloud e a sua estratégia Clean Core. Mas essa transição levará anos para a maioria das organizações, e entretanto as restrições herdadas permanecem. A personalização acrescenta outra camada de complexidade: cada modificação de um cliente a uma app Fiori cria uma carga de manutenção que torna as atualizações mais arriscadas e atrasa a adoção das próprias melhorias de UX da SAP.

O resultado é uma plataforma que melhora ao ritmo de um grande fornecedor de software empresarial — medido, cuidadoso, compatível com versões anteriores — enquanto as expectativas dos utilizadores avançam ao ritmo da tecnologia de consumo. A diferença é estrutural e não se fechará apenas através de versões incrementais da plataforma.

Como os Copilotos IA Abordam Cada Padrão de Falha

É aqui que as coisas se tornam genuinamente interessantes. Os copilotos IA — seja o próprio Joule da SAP, agentes LLM personalizados integrados via SAP BTP, ou soluções híbridas que combinam o ChatGPT ou o Gemini com APIs SAP — podem abordar as falhas de UX do Fiori de formas que não requerem reescrever a arquitetura subjacente. Trabalham em torno das restrições adicionando uma camada inteligente por cima.

Resolver Tempos de Carregamento Lentos com Pré-carregamento Preditivo

Os copilotos IA com acesso a dados de comportamento do utilizador podem prever quais as apps que um utilizador provavelmente vai abrir e pré-carregar os dados relevantes antes de o utilizador navegar até lá. Se um responsável de compras abre a app Gerir Ordens de Compra todas as manhãs às 8h15 e filtra por um grupo de compras específico, um agente preditivo pode disparar essa chamada OData em segundo plano às 8h10, de modo que os dados estejam em cache e prontos quando o utilizador chegar.

// 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();

  const prediction = await prefetchModel.predict({
    userId,
    currentHour,
    lastVisitedApp: sessionStore.get(userId)?.lastApp
  });

  if (prediction.confidence > 0.75) {
    prefetchCache.warmAsync(prediction.entitySetUrl, userId);
  }

  next();
});

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

Quando uma pesquisa requer um número de fornecedor e o utilizador não o conhece, um copiloto IA pode resolver a restrição conversacionalmente. Em vez de o utilizador chegar a um beco sem saída, escreve "mostra-me ordens de compra da Siemens na semana passada" e o copiloto resolve "Siemens" para o número de fornecedor, infere o intervalo de datas, preenche os campos obrigatórios e submete a pesquisa em nome do utilizador.

# Example: LLM function definition for vendor lookup
functions = [
  {
    "name": "resolve_vendor",
    "description": "Resolve a vendor name or partial name to an SAP vendor number",
    "parameters": {
      "type": "object",
      "properties": {
        "vendor_name": {"type": "string"},
        "company_code": {"type": "string"}
      },
      "required": ["vendor_name"]
    }
  }
]

Resolver a Pesquisa Sem Resultados com Correspondência Semântica e Difusa

As camadas de pesquisa impulsionadas por IA podem posicionar-se à frente da pesquisa nativa do Fiori e traduzir as consultas dos utilizadores em pesquisas estruturadas que realmente devolvem resultados. Um utilizador que pesquisa "faturas da Mueller mais de 50k" obtém resultados porque a camada IA gere a resolução de variantes de nome, compreende o filtro de montante como restrição numérica e mapeia "faturas" para o tipo de documento correspondente no SAP.

Resolver Falhas Móveis com Agentes IA Offline-First

As falhas do Fiori móvel são frequentemente falhas de sincronização. Os agentes IA podem gerir isto de forma mais inteligente mantendo um modelo de estado local, colocando em fila as ações realizadas offline com lógica de resolução de conflitos e alertando proativamente os utilizadores quando um problema de sincronização requer julgamento humano em vez de falhar silenciosamente.

Resolver o Caos de Tiles com Recomendações de Papéis por IA

A IA pode ajudar analisando padrões de utilização reais — quais os tiles que cada utilizador abre, com que frequência e em que contexto — e apresentando recomendações tanto para utilizadores como para administradores. Para os utilizadores, isto parece um launchpad personalizado que apresenta as três apps que é mais provável que precisem agora mesmo. Para os administradores, parece um painel de deteção de anomalias que sinaliza utilizadores com papéis atribuídos que nunca utilizaram.

O Caso do Fecho Mensal: De 40 Cliques para 3 Prompts

O exemplo mais ilustrativo que posso dar do que um copiloto IA faz realmente à UX do Fiori vem de uma controller com quem trabalhei numa empresa de fabricação de média dimensão na Alemanha — 1,4 mil milhões de EUR de faturação anual, S/4HANA on-premise, três códigos de empresa a gerir.

A sua rotina de fecho mensal era uma ilustração perfeita das falhas do Fiori em escala. A sequência específica que cronometrei: verificar acréscimos em aberto, verificar que todas as contas de compensação EM/RF estavam reconciliadas e identificar quaisquer partidas grandes não contabilizadas antes de o período ser bloqueado.

No Fiori, isso implicava navegar por quatro apps separadas. Contei 22 minutos por código de empresa, 66 minutos para os três — feito duas vezes por dia durante os últimos três dias úteis de cada mês. São 6 horas por mês do tempo de um profissional financeiro sénior a clicar na navegação de aplicações.

A Implementação do Copiloto IA

User: "Run my month-end close check for company codes 1000, 2000, 3000"

Response:
------------------------------------------------------------------
MONTH-END STATUS | 2026-03-28 | 3 days to period close

COMPANY 1000 (DE): ACTION REQUIRED
  Unconfirmed accruals: 3 items (largest: EUR 340,000 — Vendor 100234)
  GR/IR uncleared: 12 items, EUR 89,450 (oldest: 45 days)

COMPANY 2000 (AT): OK
COMPANY 3000 (CH): OK
------------------------------------------------------------------

Três entradas do utilizador. Menos de dois minutos. Anualizado, isto recuperou aproximadamente 72 horas de tempo de profissional financeiro sénior por ano para este único processo — a 110 EUR por hora com custo total, são 7.920 EUR em tempo produtivo recuperado anualmente. A camada do copiloto custou aproximadamente 15.000 EUR a construir e 2.400 EUR por ano a operar. O retorno do investimento foi positivo em 26 meses para este único caso de uso.

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

O cliente é um grupo de fabricação pan-europeu com aproximadamente 4.200 utilizadores do Fiori em compras, finanças e logística. A adoção do Fiori tinha estagnado em cerca de 38% da sua população de utilizadores prevista.

Fase 1: Camada de Pesquisa Impulsionada por IA (T1 2025)

Antes: Sessão de pesquisa média bem-sucedida: 3 minutos e 40 segundos. 2,1 pesquisas falhadas por utilizador por dia.
Depois: 48 segundos. 0,4 pesquisas falhadas. Tickets de suporte relacionados com pesquisa: menos 62%.

Fase 2: Pré-carregamento Preditivo para as 10 Apps Mais Usadas (T2 2025)

Antes: Tempo de carregamento médio para as cinco apps mais usadas: 4,1 segundos.
Depois: 1,9 segundos de média geral percebida.

Fase 3: Personalização do Launchpad Impulsionada por IA (T3 2025)

Antes: Média de 3,2 cliques para chegar à app correta.
Depois: 1,4 cliques. Pontuação de satisfação: de 2,1 para 3,8.

Impacto Combinado Após 12 Meses

A adoção do Fiori aumentou de 38% para 71%. A equipa de IT estimou aproximadamente 1,2 milhões de EUR em recuperação anual de produtividade. As três camadas de IA custaram aproximadamente 180.000 EUR para construir e 40.000 EUR por ano em infraestrutura e manutenção. O CFO aprovou um roadmap de Fase 2 em trinta dias.

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

SAP Joule é o copiloto IA generativo nativo da SAP, integrado no S/4HANA Cloud, SuccessFactors, Ariba e outros produtos cloud SAP. A sua vantagem chave é a integração nativa e estreita com os dados e processos SAP. A sua limitação é o âmbito: 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 e transações Z. Também requer licenciamento SAP Business AI adicional.

As integrações ChatGPT-SAP (e padrões equivalentes usando Claude, Gemini ou LLMs open-source) oferecem muito mais flexibilidade mas requerem significativamente mais trabalho de integração. A vantagem é que pode adaptar o comportamento da IA precisamente aos processos e ao modelo de dados da sua organização.

Os agentes LLM personalizados no BTP — um padrão cada vez mais comum entre os grandes clientes SAP — situam-se entre estes dois extremos, combinando a profundidade de integração do Joule com a flexibilidade de um LLM personalizado.

O Que Procurar ao Avaliar Extensões IA para o Fiori em 2026

1. Consciência de Autorizações

Qualquer camada IA que interaja com dados SAP deve respeitar o modelo de autorização da SAP. Pergunte especificamente aos fornecedores: como é que a sua solução gere os objetos de autorização SAP?

2. Explicabilidade

Quando um copiloto IA realiza uma ação, os utilizadores e os auditores precisam de entender o que aconteceu. As boas extensões IA do Fiori apresentam o seu raciocínio.

3. Degradação Elegante

Uma boa extensão IA do Fiori degrada-se de forma elegante quando o seu componente IA não está disponível — voltando ao comportamento padrão do Fiori em vez de apresentar uma interface quebrada.

4. Residência e Privacidade de Dados

Se o seu copiloto IA envia dados SAP para uma API LLM externa, tem uma questão de residência de dados para responder, especialmente sob o RGPD.

5. Baseline Mensurável e Estrutura de KPIs

Antes de implementar qualquer extensão IA, estabeleça uma linha de base. Sem uma linha de base, não pode demonstrar o ROI.

6. Compatibilidade com Atualizações

Pergunte a qualquer fornecedor de extensões IA para o Fiori como gerem as atualizações da SAP. Esta questão separa os fornecedores com produtos maduros dos que têm demonstrações impressionantes.

O Caminho a Seguir

O SAP Fiori não vai desaparecer. Com todas as suas frustrações, é a base de UX para o maior ecossistema de software empresarial do mundo. O que mudou em 2026 é que as ferramentas IA necessárias para aumentar o Fiori se tornaram genuinamente acessíveis.

A minha recomendação prática: não espere que a SAP resolva os problemas de UX do Fiori de forma nativa. Identifique os dois ou três padrões de falha que causam mais fricção na sua organização específica e construa uma camada IA direcionada para abordar esses problemas específicos. Comece com uma prova de conceito limitada a um grupo de utilizadores. Meça rigorosamente. Depois escale o que funciona.

As organizações que vejo a ter sucesso com o Fiori em 2026 não são as que esperam que a próxima versão da SAP resolva a UX. São as que tratam o Fiori como uma base sobre a qual construir, não como um produto acabado a aceitar. Essa é a mudança de mentalidade que transforma uma taxa de adoção de trinta e oito por cento em setenta e um por cento.

Tem um problema de UX no Fiori que resiste às soluções padrão? Interessa-me saber o que está a ver na sua organização — contacte através da página de contacto ou conecte-se no LinkedIn.