Quando você deve manter o SAP GUI em vez de migrar para o Fiori?

Se a sua organização está executando um projeto S/4HANA, você provavelmente já ouviu alguma versão da mesma mensagem: SAP Fiori é o futuro, SAP GUI é o passado, e toda transação deve eventualmente se tornar um bloco no Launchpad.

A realidade dentro da maioria dos cenários SAP é mais nuanceada. O SAP Fiori é uma melhoria real para muitos cenários — aprovações em um telefone, solicitações de autoatendimento, visões gerais analíticas, tarefas guiadas para usuários ocasionais. Mas tratar o Fiori como uma substituição automática para toda transação SAP GUI é uma decisão de projeto, não uma decisão do usuário, e isso muitas vezes sai pela culatra. Equipes que forçam uma migração completa sem avaliar como o trabalho é realmente realizado tendem a ver os mesmos sintomas: escriturários de contas a pagar que discretamente pedem sua transação antiga de volta, supervisores de armazém alternando entre três aplicativos para fazer o que antes uma única tela fazia, centrais de atendimento inundadas com chamados do tipo “para onde foi minha transação?”, e relatórios de adoção que parecem piores três meses após a entrada em produção do que no primeiro dia.

Este artigo não é uma defesa do SAP GUI, e não é uma crítica ao SAP Fiori. É um guia prático para uma pergunta que toda equipe de S/4HANA e de modernização de interfaces acaba enfrentando: para este usuário, processo e tarefa específicos — qual interface realmente se encaixa?

SAP GUI e SAP Fiori resolvem problemas diferentes

Parte da confusão vem de comparar os dois como se fossem versões concorrentes da mesma coisa. Eles não são.

O SAP GUI é centrado em transações. Ele foi criado em torno da ideia de que um usuário treinado abre um código de transação — VA01, ME21N, MIGO, FBL1N — e trabalha em uma tela densa, orientada pelo teclado, que expõe quase tudo o que o objeto de negócio subjacente pode fazer. Abas, teclas de função, grades ALV, variantes de layout, entrada em lote: o design pressupõe conhecimento especializado e o recompensa. Para alguém que executa a mesma transação duzentas vezes por dia, essa densidade não é poluição visual. É produtividade.

O SAP Fiori é baseado em funções e orientado a tarefas. Em vez de perguntar "de qual transação eu preciso?", ele pergunta "o que esta função precisa realizar?" Um aplicativo Fiori normalmente isola uma tarefa — aprovar uma requisição de compra, criar uma solicitação de licença, verificar faturas de fornecedores — e a apresenta em uma interface moderna, responsiva e baseada em navegador, que funciona em um desktop, tablet ou telefone. Para alguém que usa o SAP duas vezes por mês, esse foco não é limitador. É o que torna a tarefa possível sem treinamento.

Enquadrada dessa forma, a pergunta "Qual é melhor?" não tem uma resposta útil. A pergunta útil é: qual deles se ajusta a este usuário, a este processo e a esta tarefa? O restante deste artigo divide essa pergunta em critérios de decisão concretos.

Quando o SAP GUI ainda pode ser a melhor escolha

Há cenários recorrentes em que o SAP GUI continua sendo a opção mais prática, mesmo em um ambiente S/4HANA maduro:

• Trabalho operacional de alto volume. Funções que processam grandes filas de documentos — verificação de faturas com MIRO, movimentações de mercadorias com MIGO, entrada de pedidos de venda com VA01 — dependem de repetição, memória muscular e do mínimo de cliques por documento. Uma reformulação de tela que adicione até mesmo dois segundos por documento custa horas por semana em escala.
• Usuários que trabalham por meio de códigos de transação e atalhos. Usuários experientes navegam no SAP digitando /n e um T-code, encadeando telas com teclas de função e alternando entre sessões. Substituir isso por navegação por blocos e pesquisa remove um método de trabalho que eles otimizaram por anos.
• Tarefas que precisam de muitos campos, abas, filtros ou grades de dados. Alguns objetos de negócio são simplesmente complexos. Uma ordem de produção, um elemento WBS ou um mestre de materiais completo (MM02 com suas dezenas de visões) não se torna mais simples porque a tela é mais simples — a complexidade apenas é dividida em mais etapas.
• Processos com transações GUI maduras e sem aplicativo Fiori equivalente. O catálogo Fiori da SAP é grande, mas não é completo, e a cobertura varia por módulo e versão. Quando a transação clássica é a única opção com funcionalidade completa, mantê-la não é resistência à mudança; é a única forma de realizar o trabalho.
• Transações altamente personalizadas. Z-transactions, screen exits, campos personalizados e processos com muitas ampliações frequentemente não têm nenhum equivalente em Fiori, e reconstruí-los como aplicativos Fiori personalizados é um projeto de desenvolvimento, não uma tarefa de configuração.
• Trabalho técnico e administrativo. Atividades de Basis, ABAP e suporte — SE38, SM37, ST22, SU01, SPRO — funcionam naturalmente no SAP GUI. Há pouco valor prático em mover o monitoramento de jobs ou a depuração para um bloco no navegador.
• Situações em que velocidade e densidade superam a simplicidade visual. Quando a medida de sucesso é documentos por hora, em vez de facilidade no primeiro uso, a interface mais densa frequentemente vence.

Quando o SAP Fiori pode ser a melhor escolha

A mesma lógica funciona no sentido oposto. Há cenários em que o SAP GUI é claramente a ferramenta errada e o Fiori entrega valor real e mensurável:

• Uso em dispositivos móveis e tablets. O SAP GUI nunca foi projetado para um telefone. O Fiori foi.
• Operações em campo. Técnicos confirmando ordens de manutenção, motoristas registrando entregas ou inspetores capturando resultados no local se beneficiam diretamente de aplicativos responsivos e fáceis de usar por toque.
• Usuários ocasionais. Um empregado que envia um relatório de despesas por mês nunca deveria precisar aprender um código de transação.
• Aprovações de gestores. Aprovar requisições de compra, solicitações de licença ou folhas de ponto a partir de um aplicativo de caixa de entrada — muitas vezes em segundos, de qualquer lugar — é um dos casos de uso mais fortes do Fiori.
• Cenários de autoatendimento. Autoatendimento de RH, solicitações de compras e gestão de viagens funcionam melhor como jornadas guiadas do que como transações para especialistas.
• Acesso baseado em funções. Apresentar a cada função apenas os blocos de que ela precisa reduz o ruído e simplifica a integração em comparação com um campo de comando GUI em branco.
• Tarefas focadas e de finalidade única. Quando uma tarefa tem um começo e um fim claros, um aplicativo dedicado é mais fácil de aprender e mais difícil de usar incorretamente.
• Visões gerais analíticas. Páginas de visão geral, blocos de KPI e análises incorporadas oferecem a gestores e usuários-chave insights rápidos que as transações clássicas nunca ofereceram.
• Jornadas de usuário simplificadas. Processos redesenhados em torno de menos etapas — tratamento de situações, fluxos de trabalho guiados — podem realmente reduzir o esforço, não apenas repintar a tela.
• Novos usuários. Pessoas que entram na organização sem histórico em SAP aprendem o modelo baseado em tarefas do Fiori muito mais rapidamente do que códigos de transação.

Uma estratégia de interface confiável reconhece ambas as listas. O erro é aplicar qualquer uma delas universalmente.

Cobertura funcional: o aplicativo Fiori realmente substitui a transação GUI?

O erro mais comum — e mais caro — em implantações do Fiori é presumir que um aplicativo com a mesma finalidade de uma transação tenha a mesma funcionalidade. Antes de desativar qualquer transação GUI, as equipes devem validar a cobertura ponto a ponto:

• Campos obrigatórios: Todos os campos que o negócio realmente usa estão disponíveis no aplicativo, incluindo aqueles adicionados ao longo dos anos?
• Ações obrigatórias: Os usuários conseguem executar todas as operações — não apenas criar e exibir, mas estornar, bloquear, liberar, reatribuir, alterar em massa?
• Variantes: Os usuários dependem de variantes de seleção ou variantes de layout que o aplicativo não consegue reproduzir?
• Filtros: Os usuários conseguem filtrar e classificar da forma como fazem hoje, especialmente em grandes conjuntos de resultados?
• Exportações: A exportação para planilha está disponível, completa e formatada de forma utilizável?
• Anexos: Os anexos de documentos estão visíveis, e os usuários conseguem adicioná-los?
• Aprovações: O aplicativo se integra ao mesmo workflow, agentes e regras de escalonamento?
• Exceções: Os usuários conseguem lidar com os cenários fora do caminho ideal — entregas parciais, diferenças de preço, documentos bloqueados?
• Campos personalizados: Os campos específicos do cliente aparecem, e são editáveis onde necessário?
• Relatórios: Os relatórios downstream e as transações de acompanhamento ainda se conectam naturalmente?
• Comportamento de autorização: O Fiori usa catálogos, grupos e serviços OData sobre objetos de autorização clássicos — o acesso efetivo corresponde ao que os usuários têm hoje?
• Etapas do processo ao redor: O usuário consegue navegar para a próxima etapa do processo, ou o aplicativo termina em um beco sem saída que obriga a voltar para a GUI de qualquer forma?

Um aplicativo Fiori que cobre 85% de uma transação parece estar próximo. Na realidade operacional, os 15% ausentes muitas vezes contêm exatamente o tratamento de exceções com que usuários experientes lidam diariamente. Se os usuários precisam abrir o SAP GUI para concluir o que o aplicativo iniciou, a migração adicionou uma etapa em vez de remover uma.

Perfil de usuário: usuário casual, usuário-chave ou usuário avançado?

As interfaces não são avaliadas de forma abstrata; elas são avaliadas por pessoas com relações muito diferentes com o sistema.

Um usuário casual avalia uma interface pela possibilidade de concluir a tarefa sem ajuda. Um gerente a avalia pela rapidez com que consegue agir sobre o que está aguardando sua atenção, muitas vezes a partir de um telefone entre reuniões. Um usuário-chave precisa de visibilidade suficiente para responder a perguntas de sua equipe e identificar problemas de processo. Um consultor ou analista de suporte precisa navegar profundamente por documentos, tabelas e logs para diagnosticar problemas. Um usuário avançado avalia a interface em pressionamentos de tecla e segundos, porque seu dia é composto por milhares de ambos.

A implicação prática: decisões de interface tomadas por função e tarefa terão desempenho melhor do que decisões tomadas por transação. O mesmo processo de pedido de compra pode usar Fiori para o solicitante, Fiori para o aprovador e GUI para o comprador que processa cinquenta pedidos por dia.

Frequência da tarefa e densidade de dados

Duas dimensões preveem a adequação da interface melhor do que quase qualquer outra coisa: com que frequência a tarefa é realizada e quantos dados ela envolve.

A frequência muda o que "usável" significa. Uma tarefa realizada uma vez por mês pode tolerar — e até se beneficiar de — orientações, etapas extras de confirmação e telas explicativas. O usuário esqueceu os detalhes desde a última vez. Uma tarefa realizada centenas de vezes por semana não pode tolerar nada disso. Cada etapa guiada que ajuda o usuário mensal é atrito para o usuário diário.

A densidade muda o que "simples" significa. Grandes grades ALV no SAP GUI permitem que os usuários examinem centenas de itens de linha, classifiquem, criem subtotais, filtrem e editem no próprio local. Telas de lista simplificadas que mostram menos colunas e paginam os resultados podem transformar uma revisão de dois minutos em uma rolagem de quinze minutos. Quando o trabalho é fundamentalmente percorrer muitos registros — compensar itens em aberto, revisar resultados de MRP, reconciliar diferenças de estoque — uma tela otimizada para a legibilidade de um único registro trabalha contra a tarefa.

Nenhum dos pontos é um argumento contra o Fiori em geral. Relatórios de lista do Fiori com tabelas inteligentes lidam com volumes substanciais de dados, e alguns cenários são drasticamente melhores no Fiori. O ponto é que a frequência e a densidade devem ser medidas para a tarefa real antes de decidir — não presumidas a partir de uma demonstração com dez registros de exemplo.

Desempenho e Produtividade

As discussões sobre desempenho em torno do Fiori muitas vezes permanecem teóricas até a entrada em produção e, então, tornam-se muito concretas. As equipes devem avaliar de forma realista:

• Tempo de carregamento do Launchpad, especialmente o primeiro carregamento do dia e após a invalidação do cache.
• Número de funções e aplicativos atribuídos a um usuário — Launchpads muito carregados, com centenas de blocos, carregam mais lentamente e são mais difíceis de navegar.
• Comportamento do navegador, incluindo políticas corporativas de navegador, extensões e limites de memória em máquinas cliente mais antigas.
• Condições de rede — o Fiori troca mais informações pela rede do que o protocolo otimizado do GUI, o que importa para fábricas remotas, usuários de VPN e locais com baixa largura de banda.
• Desempenho do backend e dos serviços OData, já que um aplicativo bem projetado em um gateway lento continua sendo um aplicativo lento.
• A diferença entre teste e produção — um aplicativo testado com 50 documentos se comporta de forma diferente com 50.000.
• Velocidade percebida vs. disponibilidade técnica — um sistema pode estar "no ar" e ainda assim parecer lento, e os usuários julgam a sensação, não o painel de monitoramento.

O desempenho merece atenção porque não é apenas uma métrica de TI. É uma variável de adoção. Usuários que experimentam um Launchpad lento em sua primeira semana formam uma opinião que o treinamento não desfará, e encontrarão o caminho de volta para o GUI — oficialmente ou não. Se a experiência do Fiori não puder ser tornada responsiva em condições reais para uma determinada tarefa, esse é um motivo legítimo para manter a transação no GUI até que isso seja possível.

Customização e processos legados

A maioria dos ambientes SAP com mais de alguns anos não é padrão. Eles carregam user exits, BAdIs, telas customizadas, campos Z, lógica de validação e transações Z inteiras criadas em torno de como o negócio realmente funciona. Essa base instalada altera significativamente a equação de migração. Antes de mover um processo customizado para o Fiori, as equipes devem avaliar:

• O processo segue as premissas padrão do SAP? Os aplicativos Fiori são criados para processos padrão. Quanto mais um processo se afastou do padrão, menor a probabilidade de o aplicativo se adequar sem modificação.
• O aplicativo oferece suporte aos tipos de documentos, campos, validações ou telas customizados em uso? Algumas extensões são transferidas por meio da extensibilidade no aplicativo ou de campos de usuário-chave; lógicas de tela profundamente incorporadas geralmente não são.
• A transação tem melhorias locais das quais os usuários dependem? Um botão customizado que automatiza uma correção de cinco etapas pode ser invisível na documentação, mas essencial no trabalho diário.
• Vale a pena reconstruir a experiência pelo esforço necessário? Recriar uma transação altamente customizada como um aplicativo Fiori customizado é desenvolvimento de verdade — design, serviços OData, trabalho com UI5 ou Fiori elements, testes e manutenção contínua.
• Manter o SAP GUI é simplesmente mais prático para este caso? Às vezes, a resposta honesta é sim, pelo menos para o horizonte de planejamento atual.

Há também uma versão estratégica dessa pergunta: se um processo é tão customizado que nenhum aplicativo padrão se adequa, o movimento correto de longo prazo pode ser redesenhar o processo em direção ao padrão, em vez de reconstruir a customização em uma nova interface. Mas essa é uma decisão de processo que merece seu próprio projeto — não um efeito colateral de uma migração de UI.

Dispositivos móveis nem sempre são o fator decisivo

"Fiori é móvel" é verdade, e é um dos argumentos mais fortes para a adoção — para os cenários que são realmente móveis. Confirmações de serviço de campo, tarefas de armazém em dispositivos portáteis, aprovações em telefones, rondas de manutenção de fábrica: estes são casos reais e de alto valor em que a mobilidade muda a forma como o trabalho é realizado.

Mas uma grande parte do trabalho em SAP é, e continuará a ser, trabalho em desktop. Um contador financeiro fechando o mês, um planejador de materiais revisando exceções de MRP, um agente de atendimento ao cliente com headset inserindo pedidos — esses usuários ficam sentados em mesas com monitores grandes e teclados completos. Para eles, "também funciona em um telefone" não traz benefício algum, e escolhas de design mobile-first (alvos de toque maiores, menos campos visíveis, layouts verticais) podem prejudicar a experiência no desktop.

O teste é simples: alguém realmente executa esta tarefa longe de uma mesa, ou executaria se pudesse? Se sim, a mobilidade é um argumento forte a favor do Fiori. Se não, a decisão deve se basear nos outros critérios deste artigo — cobertura, densidade, desempenho, perfil do usuário — com a mobilidade recebendo peso zero, em vez de ser presumida como um benefício.

Treinamento e Gestão de Mudanças

Mesmo quando o Fiori é claramente o destino certo, a transição falha sem uma gestão de mudanças deliberada. Várias realidades precisam ser planejadas, não descobertas:

Os usuários não devem ser forçados a entrar no Fiori sem entender a nova jornada. A mudança não é cosmética. A lógica de navegação, a terminologia e a forma do trabalho mudam.

Uma transação pode se tornar vários aplicativos. O que era uma única tela com abas — exibir fornecedor, alterar fornecedor, visualizar itens em aberto — agora pode ser três ou quatro blocos. Os usuários precisam saber que isso é intencional e para onde cada parte foi.

Os usuários precisam de um mapeamento do antigo para o novo. "Qual bloco substitui a VA02?" é a pergunta mais comum em uma implantação do Fiori. Um mapeamento publicado de transações para aplicativos, mantido atualizado, evita milhares de tickets de suporte.

Os usuários-chave precisam de um caminho de suporte claro. Quando um aplicativo não tem uma função ou se comporta de forma inesperada, os usuários-chave precisam saber se é um bug, uma lacuna de treinamento, uma autorização ausente ou uma limitação conhecida — e a quem perguntar.

O treinamento deve explicar o processo, não apenas a tela. Mostrar aos usuários para onde os botões foram movidos gera conformidade. Explicar como o processo de ponta a ponta agora flui — e por quê — gera adoção. Isso é especialmente verdadeiro quando a implantação do Fiori coincide com mudanças reais de processo no S/4HANA, o que geralmente acontece.

Uma Lista de Verificação Prática para Decisão

Lista de Verificação para Decisão entre SAP GUI e SAP Fiori

Passe cada transação ou tarefa significativa por estas perguntas antes de decidir:

1. Quem executa esta tarefa? Usuário ocasional, gerente, usuário-chave, suporte ou usuário avançado?
2. Com que frequência ela é executada? Mensalmente, diariamente ou centenas de vezes por semana?
3. A tarefa é móvel ou baseada em desktop? Alguém precisa executá-la longe de uma mesa?
4. O aplicativo Fiori cobre toda a funcionalidade necessária? Campos, ações, variantes, filtros, exportações, anexos, exceções?
5. Há campos personalizados ou melhorias? Eles são transferidos para o aplicativo?
6. O usuário precisa de alta densidade de dados? Grades grandes, processamento em massa, edição no local?
7. O aplicativo Fiori é rápido o suficiente em condições reais? Volumes reais de dados, rede real, máquinas cliente reais?
8. O usuário depende de códigos de transação ou atalhos de teclado? Removê-los tornaria o trabalho mais lento?
9. O processo exige vários aplicativos relacionados? Uma transação se tornaria uma jornada por múltiplos blocos?
10. Esta é uma transição temporária ou uma experiência-alvo de longo prazo? Espera-se um aplicativo melhor em uma versão futura?
11. De que treinamento e documentação os usuários precisarão? Quem irá produzi-los e mantê-los?
12. Qual é o custo de forçar a migração? Em produtividade, carga de suporte e confiança do usuário — versus o benefício obtido?

Se as respostas apontarem claramente em uma direção, a decisão é fácil. Se elas entrarem em conflito — uma necessidade móvel, mas cobertura incompleta; um usuário avançado, mas um aplicativo analítico forte — o próprio conflito é a constatação: essa tarefa pode precisar de ambas as interfaces, ou de um redesenho, em vez de uma escolha forçada.

Estratégia híbrida recomendada

Para a maioria das organizações, o objetivo realista e defensável não é usar apenas GUI ou apenas Fiori. É um híbrido deliberado:

• SAP Fiori para autoatendimento, aprovações, cenários móveis e de campo, análises e páginas de visão geral, e tarefas focadas realizadas por usuários ocasionais — os cenários em que o design do Fiori realmente se ajusta ao trabalho.
• SAP GUI para usuários especializados que realizam trabalho operacional denso, tarefas técnicas e administrativas, transações altamente personalizadas e processos para os quais ainda não existe um aplicativo Fiori adequado.
• O Fiori Launchpad como ponto de entrada comum quando apropriado — incluindo o lançamento de transações clássicas da GUI (via SAP GUI for HTML ou blocos WebGUI incorporados) juntamente com aplicativos nativos, para que os usuários tenham um único lugar para começar, mesmo quando a tecnologia subjacente for diferente.
• Documentação interna que torna a divisão explícita. Os usuários nunca devem ter que adivinhar qual interface usar para um determinado processo. A ambiguidade é onde hábitos paralelos e trabalho duplicado crescem.

Uma estratégia híbrida não é um compromisso nem um sinal de modernização incompleta. É assim que uma abordagem “consciente do processo” se apresenta na prática. A composição da combinação mudará ao longo do tempo à medida que a cobertura do Fiori crescer, os aplicativos amadurecerem e os processos forem redesenhados — exatamente por isso a estratégia deve ser documentada e revisitada, não decidida uma vez e congelada.

O que as equipes devem documentar

A diferença entre um cenário híbrido gerenciado e um acidental é a documentação. As equipes devem manter um catálogo interno de interfaces — um documento vivo, sob responsabilidade de alguém — com pelo menos:

• Processo de negócio (por exemplo, processamento de faturas de fornecedores)
• Transação SAP GUI (por exemplo, MIRO, FBL1N)
• Aplicativo ou bloco do Fiori (nome e ID do aplicativo, por exemplo, "Create Supplier Invoice", F0859)
• Tipo de aplicativo (SAPUI5 freestyle, Fiori elements, aplicativo clássico no WebGUI, Web Dynpro)
• Usuários-alvo / funções (quem deve usar qual interface)
• Limitações conhecidas (lacunas funcionais em comparação com a transação GUI, com detalhes específicos)
• Prontidão para dispositivos móveis (testado em quais dispositivos, para quais etapas)
• Notas de desempenho (tempos de carregamento em uso real, gargalos conhecidos, limites de volume de dados)
• Material de treinamento (link para o guia, vídeo ou material de apoio ao trabalho para cada interface)
• Responsável (quem decide e quem responde a perguntas)
• Decisão de migração: manter a GUI, migrar para o Fiori, usar ambos ou redesenhar o processo

Esse catálogo se paga rapidamente. Ele transforma "por que ainda estamos usando a GUI para isso?" de um debate recorrente em uma decisão documentada, com razões declaradas e uma data de revisão. Ele oferece às equipes de treinamento uma única fonte da verdade. E torna o movimento eventual e gradual em direção ao Fiori mensurável, em vez de anedótico.

Resposta Final

Mantenha o SAP GUI quando a tarefa exigir velocidade, profundidade, alta densidade de dados, funcionalidade transacional madura, controle técnico ou comportamento personalizado que o aplicativo Fiori disponível não suporte bem. Migre para o SAP Fiori quando o trabalho se beneficiar de acesso baseado em funções, interação guiada, acesso móvel, autoatendimento, análises ou uma experiência de usuário simplificada — e quando o aplicativo realmente cobrir a tarefa.

A melhor estratégia de interface SAP não é apenas GUI nem apenas Fiori. Ela é consciente do processo, consciente das funções e fundamentada em como o trabalho é realmente realizado. Equipes que avaliam cada tarefa por seus próprios méritos — perfil do usuário, frequência, densidade, cobertura, personalização, desempenho e mobilidade — acabam tendo maior adoção, menores custos de suporte e usuários que confiam nas interfaces que receberam, porque essas interfaces foram escolhidas para eles, não impostas a eles.

Perguntas frequentes

O SAP Fiori está substituindo o SAP GUI?

O SAP Fiori é a experiência de usuário estratégica da SAP para o S/4HANA, e novas funcionalidades são cada vez mais entregues como aplicativos Fiori. No entanto, o SAP GUI continua totalmente suportado e amplamente utilizado, e muitas transações não têm um equivalente completo no Fiori. Na prática, o Fiori está se expandindo, em vez de substituir instantaneamente o SAP GUI, e a maioria dos clientes S/4HANA usa ambos.

As empresas ainda podem usar o SAP GUI com o S/4HANA?

Sim. O SAP GUI funciona com o S/4HANA (edições locais e de nuvem privada), e milhares de transações clássicas continuam disponíveis. Algumas transações foram removidas ou substituídas na simplificação do S/4HANA, mas o próprio SAP GUI é um método de acesso suportado, e transações clássicas podem até ser iniciadas como blocos a partir do Fiori Launchpad.

Quando o SAP GUI é melhor que o SAP Fiori?

O SAP GUI tende a ser melhor para trabalho operacional de alto volume, usuários avançados que dependem de códigos de transação e atalhos de teclado, tarefas com grades de dados densas e muitos campos, transações altamente personalizadas, atividades técnicas e administrativas, e qualquer processo em que o aplicativo Fiori disponível não cubra toda a funcionalidade da transação clássica.

Quando o SAP Fiori é melhor que o SAP GUI?

O SAP Fiori é melhor para cenários móveis e de campo, aprovações de gestores, tarefas de autoatendimento, usuários ocasionais que não conhecem códigos de transação, acesso baseado em funções, visões analíticas gerais e tarefas focadas de propósito único. Nesses cenários, o Fiori normalmente oferece conclusão mais rápida, menor esforço de treinamento e maior satisfação do usuário do que o SAP GUI.

Por que usuários avançados geralmente preferem o SAP GUI?

Usuários avançados otimizam o rendimento: códigos de transação, teclas de função, múltiplas sessões, variantes de layout e grades ALV densas permitem processar grandes volumes com o mínimo de cliques. Interfaces simplificadas e guiadas removem exatamente a densidade e o controle pelo teclado que tornam o trabalho deles rápido, portanto uma tela que ajuda um usuário ocasional pode tornar um especialista mais lento.

Toda transação do SAP GUI deve ser substituída por um aplicativo Fiori?

Não. Cada transação deve ser avaliada com base no perfil do usuário, frequência da tarefa, densidade dos dados, cobertura funcional, personalização, desempenho e necessidade móvel. Algumas transações se mapeiam claramente para aplicativos Fiori melhores; outras não têm equivalente adequado ou atendem usuários cujo trabalho é mais rápido no GUI. Forçar uma substituição completa geralmente prejudica a produtividade e a adoção.

As transações do SAP GUI podem ser iniciadas a partir do Fiori Launchpad?

Sim. Transações clássicas podem ser expostas como blocos do Launchpad usando o SAP GUI for HTML (WebGUI), para que os usuários tenham um único ponto de entrada mesmo quando a tela subjacente é uma transação clássica. Esta é uma técnica comum em estratégias híbridas, embora as equipes devam verificar se a transação específica se comporta bem no WebGUI antes de depender dela.

Como as equipes devem decidir entre SAP GUI e SAP Fiori?

Avalie cada tarefa, não a tecnologia: identifique quem a executa e com que frequência, se é em desktop ou móvel, se o aplicativo Fiori cobre todos os campos, ações e exceções necessários, se as personalizações são mantidas e se o desempenho se sustenta com volumes reais de dados e condições de rede. Documente a decisão por processo e revise-a à medida que a cobertura do Fiori melhora.

Uma estratégia híbrida de SAP GUI e Fiori é aceitável?

Sim — para a maioria das organizações, essa é a abordagem recomendada, não um compromisso. Uma estratégia híbrida bem gerenciada usa o Fiori para autoatendimento, aprovações, mobilidade e análises, mantém o SAP GUI para trabalho especializado, denso, técnico ou personalizado, e documenta claramente qual interface se aplica a cada processo. A combinação então evolui à medida que os aplicativos amadurecem.

O que deve ser documentado antes de migrar usuários do SAP GUI para o Fiori?

As equipes devem manter um catálogo que mapeie cada processo de negócio para sua transação GUI e aplicativo Fiori, incluindo tipo de aplicativo, usuários-alvo, lacunas funcionais conhecidas, prontidão móvel, observações de desempenho, material de treinamento, um responsável e a decisão de migração (manter GUI, migrar para Fiori, usar ambos ou redesenhar). Esse mapeamento evita sobrecarga de suporte e torna a transição mensurável.