Quando o aplicativo Fiori padrão cobre 80% — e os 20% restantes acabam com a adoção

O workshop fit-to-standard correu bem. O aplicativo padrão da Fiori Apps Reference Library foi demonstrado muito bem, o analista marcou a lista de requisitos, e o slide de resumo disse o que sempre diz: 80% de cobertura, lacunas restantes a serem abordadas em uma onda posterior.

Seis meses após o go-live, os aprovadores exportam a lista de trabalho para o Excel porque o único campo no qual eles realmente baseiam a decisão não está na object page. O empregado que libera duzentos documentos antes do almoço voltou discretamente para a transação GUI. A exceção de quinta-feira circula por e-mail.

Eis o paradoxo: os aplicativos Fiori padrão que mais fracassam raramente são aqueles que claramente não se encaixavam. Uma incompatibilidade óbvia é rejeitada cedo e a baixo custo. Um aplicativo que cobre 80% é aprovado, recebe treinamento e é celebrado — depois fracassa silenciosamente, porque percentuais de cobertura escondem um fato que toda planilha de fit-gap ignora: nem todos os requisitos têm o mesmo peso.

Por que "Adotar o padrão primeiro" ainda é o instinto certo

A posição merece sua versão mais forte, porque está em grande parte correta.

O fit-to-standard é a lição acumulada de duas décadas de ambientes ERP soterrados sob transações Z: o sistema em que uma atualização leva dezoito meses porque dez mil objetos personalizados precisam de testes de regressão, e em que o código personalizado agora dita como o processo funciona.

O princípio do clean core é a resposta sensata. Aplicativos Fiori padrão vêm com algo que nenhum desenvolvimento personalizado entrega plenamente: a SAP os mantém, testa-os em relação a cada versão e os entrega integrados aos objetos de negócio e às autorizações. Quando um aplicativo padrão realmente se ajusta, adotá-lo é a decisão de engenharia correta.

A crítica a seguir mira duas outras coisas: como se determina se algo "se ajusta" e o custo subestimado de fechar as lacunas que ficam para trás.

Por que "80% de cobertura" é um número sem sentido

Uma análise fit-gap típica produz uma lista: quarenta requisitos, trinta e dois cobertos, oito lacunas. Cobertura: 80%. O número parece rigoroso. É aritmética aplicada a um erro de categoria.

Os requisitos são contados como unidades intercambiáveis. Eles não são. "O aplicativo mostra a moeda do documento" e "o aprovador pode ver as disputas em aberto do fornecedor" contam ambos como uma linha — mas um é decoração e o outro é o motivo pelo qual a etapa de aprovação existe. Se os 20% ausentes incluem uma etapa que o usuário não pode pular, a adoção desmorona, independentemente de quão polido seja o restante.

A pergunta que prevê a adoção é diferente: cada usuário consegue concluir seu trabalho diário real, incluindo os casos problemáticos, sem sair do aplicativo? Essa é uma pergunta de sim/não por função, e transformá-la em média percentual é como implementações fracassam educadamente. Cobertura é uma corrente, não uma pilha: um elo quebrado, e o usuário vivencia a ruptura.

Uma taxonomia dos 20% ausentes

O quinto ausente se agrupa em cinco famílias.

Dados ausentes na tela. A object page mostra os dados do cabeçalho que a SAP considerou universalmente relevantes — mas este aprovador decide com base na referência do contrato e no gasto em relação ao acordo-quadro, e nenhum dos dois aparece. Então ele abre o SAP GUI em uma segunda janela e, em pouco tempo, pula totalmente a etapa do Fiori. Um único campo ausente torna uma tela 95% completa 0% suficiente.

Validações e verificações de conformidade ausentes. A estrutura de controle exige uma verificação por quatro olhos acima de um determinado limite. O aplicativo padrão não tem espaço para isso, e uma política que pede aos usuários para “se lembrarem de” não é algo que auditores aceitem.

Operações em massa ausentes. O empregado que processava lotes em uma grade ALV — selecionar tudo, aplicar, F8 — encontra um list report projetado para revisar itens um por um. Doze minutos viram uma hora.

Caminhos de exceção ausentes. O processo real inclui rejeitar com motivo e devolver à rota, solicitar esclarecimento, reatribuir porque o aprovador está de licença. Sem um vocabulário para a exceção, a exceção vai para o e-mail.

Integração ausente com a etapa adjacente. A saída precisa chegar a algum lugar que o aplicativo não alcança — um anexo em outro módulo, uma notificação que a próxima função nunca recebe — então o usuário executa uma segunda tarefa manual para fazer a primeira valer.

Cada uma parece pequena em uma linha de fit-gap. Cada uma é fatal no caminho crítico.

Por que a lacuna sobrevive ao projeto — e como a adoção entra em colapso silenciosamente

Se essas lacunas são tão previsíveis, por que chegam à produção? Quatro mecanismos estruturais.

As demonstrações mostram caminhos felizes. O workshop executa o cenário padrão com dados limpos. Ninguém demonstra a exceção de quinta-feira.

Os workshops selecionam os usuários errados. Os participantes são líderes funcionais e consultores que entendem o processo, mas não o executam duzentas vezes por dia. O empregado que sabe qual campo importa é representado por procuração.

A cobertura é validada em relação à documentação. O processo documentado raramente inclui as validações informais, consultas paralelas e tratamento de exceções que compõem o trabalho real.

"Onda 2" é uma ficção com um código de projeto. Após o go-live, a equipe se dispersa, o orçamento é encerrado e os usuários já criaram soluções alternativas. A solução alternativa se torna o processo.

E o colapso é silencioso. Ninguém abre um chamado intitulado "Eu me recuso a usar o aplicativo." A transação na GUI ainda está acessível, a exportação para Excel se torna a verdadeira lista de trabalho, e as aprovações são pré-acordadas por e-mail e apenas registradas no aplicativo depois — de modo que a trilha de auditoria documenta uma ficção. As contagens de lançamento continuam respeitáveis, porque os usuários ainda abrem o aplicativo para o clique final. É por isso que os 20% ausentes são mais perigosos do que 100% ausentes: a falha total é visível no workshop; a falha parcial é invisível até a auditoria.

O Espectro da Extensibilidade: Onde Cada Ferramenta Para

Nada disso significa que as lacunas não possam ser fechadas. A SAP oferece um verdadeiro espectro de opções, e uma avaliação honesta exige saber onde cada uma termina.

Extensibilidade para key users — os aplicativos Custom Fields e Custom Logic no S/4HANA — permite que um especialista de negócio treinado adicione campos personalizados a um contexto de negócio, exponha-os na interface padrão e anexe lógica limitada por meio de BAdIs liberadas. O limite é exatamente onde a SAP o definiu: pontos de extensão liberados. Um centímetro fora do que a SAP expôs, a ferramenta simplesmente termina — e o ajuste bloqueador exige um desenvolvedor que ninguém havia previsto no orçamento.

Adaptação de UI — adaptação em tempo de execução por key users, ou projetos de adaptação no SAP Business Application Studio para variantes de aplicativos SAPUI5 padrão estáveis em upgrades — corrige problemas de organização: o campo importante enterrado três seções abaixo. Ela move móveis; não adiciona cômodos. Uma verificação de conformidade ausente não é um problema de layout.

Extensibilidade para desenvolvedores — extensões baseadas em RAP, BAdIs liberadas, visões CDS personalizadas — implementa lógica real, validações e novas ações de forma compatível com clean core. Extensibilidade side-by-side no SAP BTP vai além: uma aplicação separada que consome o S/4HANA por meio de APIs e eventos, livre para criar o que o aplicativo padrão nunca modelou. Ambas são, inequivocamente, projetos de desenvolvimento: habilidades escassas em RAP ou CAP, transportes, regressão de upgrade e um responsável pelos próximos dez anos.

A questão nunca foi se os 20% podem ser fechados. É quanto isso custa — e quem arca com esse custo depois que o projeto termina.

A curva de custo que ninguém desenha

O custo da cobertura não é linear. Os primeiros 80% vieram essencialmente de graça — a SAP criou, testa e atualiza. Os últimos 20% são trabalho sob medida, e é totalmente normal que fechar “apenas” o quinto faltante custe mais do que a funcionalidade coberta teria custado para ser criada — porque você está pagando pela integração com a aplicação de outra pessoa, a taxas de serviços profissionais, com obrigações de ciclo de vida associadas.

E o custo se repete. Cada atualização do S/4HANA significa testes de compatibilidade das extensões. Extensões em contextos liberados são projetadas para sobreviver a atualizações, e em geral sobrevivem — mas “estável por contrato” ainda significa “teste todas as vezes”.

Este não é um argumento contra estender. É um argumento a favor de precificar a decisão com honestidade. Quando o verdadeiro custo do ciclo de vida está sobre a mesa, alternativas que pareciam derrota começam a soar como engenharia.

Duas alternativas honestas: manter o SAP GUI ou redesenhar o processo

A primeira alternativa é a coexistência. Para a função de processamento em massa, a pergunta madura não é "como fazemos para levá-los ao Fiori", mas "que problema isso resolveria, e para quem?" Se a extensão para tornar o aplicativo rápido for uma construção significativa e a transação GUI for suportada e dominada, manter o SAP GUI para essa função é uma alocação correta de esforço. O Fiori conquista seu lugar onde é genuinamente melhor — aprovações em dispositivos móveis, autoatendimento para usuários ocasionais, páginas de lista analíticas. A versão honesta da coexistência nomeia a decisão, delimita-a à função e a revisita; a versão desonesta é descobri-la em uma auditoria.

A segunda alternativa é redesenhar o processo. Às vezes, os 20% ausentes não são uma deficiência do aplicativo, mas um fóssil do processo: a aprovação paralela nascida de um incidente em 2017. Antes de financiar uma extensão para codificar uma exceção, pergunte se a exceção deveria existir. "Apenas simplifique" pode ser tão superficial quanto "apenas estenda" — mas o redesenho do processo pertence à mesma lista de opções que a extensão.

Uma estrutura de decisão: pese as lacunas, não as conte

Primeiro, pese cada lacuna em três eixos:

• Severidade: bloqueante (o usuário não consegue concluir a tarefa corretamente sem ela) versus inconveniente.
• Frequência: com que frequência a lacuna ocorre e para quantos usuários.
• Raio de impacto: quem é afetado — uma função operacional central, um usuário ocasional, um auditor.

Uma lacuna bloqueante que ocorre cinquenta vezes por dia supera qualquer quantidade de lacunas cosméticas. Pontue as lacunas; não faça uma média delas. Em seguida, escolha um caminho para cada lacuna — não um único caminho para o aplicativo:

1. Aceitar a lacuna — itens de baixa severidade e baixa frequência.
2. Adaptar a interface do usuário — problemas de organização e adequação à tela.
3. Extensão de key user — campos ausentes e lógica restrita dentro de pontos de extensão liberados.
4. Extensão de desenvolvedor (RAP/BAdI) — lógica real, validações e ações, precificadas como um projeto de desenvolvimento.
5. Side-by-side na BTP — lacunas grandes o suficiente para serem sua própria aplicação.
6. Manter o SAP GUI para a função — fluxos de trabalho de usuários avançados que o aplicativo atende pior.
7. Redesenhar o processo — exceções que merecem ser eliminadas.

Para qualquer caminho escolhido, nomeie o proprietário da manutenção. Uma extensão sem proprietário é dívida técnica com data de entrega.

Como conduzir o Fit-Gap para que isso não aconteça

O lugar mais barato para identificar os 20% fatais é antes do go-live, e o formato padrão de workshop é estruturalmente ruim para isso. Quatro ajustes mudam as probabilidades:

Valide com os operadores reais. Coloque o usuário de maior volume da transação atual diante do aplicativo padrão e faça com que ele execute sua terça-feira real com volumes semelhantes aos de produção. O campo que ele verifica silenciosamente aparecerá em dez minutos.

Teste explicitamente os casos complicados. Roteirize a rejeição com retrabalho, a delegação, o pico de fim de mês. Um aplicativo validado apenas contra o caminho feliz foi validado contra um processo que não existe.

Execute um teste cronometrado de um dia na vida. Uma lentidão de 5x encontrada aqui é um insumo de design; encontrada após o go-live, já é uma solução alternativa em andamento.

Escreva a lista de lacunas em linguagem de severidade. Substitua "80% de cobertura" por uma frase por função: "A função X consegue / não consegue concluir o trabalho diário no aplicativo; as lacunas bloqueadoras são A e B; o caminho escolhido é Y, sob responsabilidade de Z." Essa frase sobrevive ao contato com a realidade.

Opções para fechar lacunas comparadas

Perguntas frequentes

O que é extensibilidade key user no SAP S/4HANA?

Ela permite que especialistas de negócio treinados estendam aplicativos padrão do S/4HANA sem um projeto de desenvolvimento — adicionando campos personalizados por meio do aplicativo Custom Fields e lógica restrita por meio de BAdIs liberadas no aplicativo Custom Logic. Ela funciona estritamente dentro dos pontos de extensão que a SAP liberou.

Qual é a diferença entre extensibilidade in-app e side-by-side?

A extensibilidade in-app é executada dentro da pilha do S/4HANA (ferramentas de key user, RAP, BAdIs), estendendo objetos padrão diretamente. A side-by-side cria um aplicativo separado no SAP BTP que consome o S/4HANA por meio de APIs e eventos liberados. A in-app é mais barata para pequenas lacunas; a side-by-side é adequada para capacidades maiores, ao custo de um segundo aplicativo a ser operado.

Por que os usuários voltam para o SAP GUI após implantações do Fiori?

Porque uma parte específica e de alta frequência do trabalho deles é pior no aplicativo: um campo crítico para decisão ausente da tela, operações em massa mais lentas do que o antigo fluxo de trabalho ALV, ou caminhos de exceção que o aplicativo não modela. Como as transações GUI continuam acessíveis, os usuários retornam discretamente a elas.

Como você avalia se um aplicativo Fiori padrão se adequa ao seu processo?

Pondere as lacunas em vez de contá-las. Faça com que os usuários reais de maior volume executem sua carga de trabalho diária real, incluindo exceções, em um sandbox, e classifique cada lacuna como bloqueadora ou inconveniente. A pergunta decisiva é se cada função consegue concluir o trabalho real sem sair do aplicativo.

As extensões do Fiori sobrevivem às atualizações do S/4HANA?

Extensões criadas em pontos de extensão liberados — extensões key user, projetos de adaptação, extensões de desenvolvedor contra APIs liberadas — são projetadas para serem estáveis em atualizações e, em geral, são. "Estável" ainda significa "faça teste de regressão a cada atualização", e qualquer coisa que toque objetos não liberados representa um risco constante.

É melhor estender um aplicativo Fiori padrão ou criar um personalizado?

Uma ou duas lacunas em nível de campo dentro de pontos de extensão liberados favorecem a extensão. Um conjunto de lacunas bloqueadoras em torno de lógica, processamento em massa ou fluxos de exceção pode tornar um aplicativo criado para uma finalidade específica — via RAP ou side-by-side no BTP — mais barato ao longo de seu ciclo de vida do que empilhar extensões em um floorplan projetado para um trabalho diferente.

A lacuna mais cara é aquela que seus usuários encontram

Os aplicativos SAP Fiori padrão merecem consideração inicial — essa parte da sabedoria convencional permanece intacta. O que não permanece é a forma como a cobertura é medida. Um índice de 80% produzido pela contagem de requisitos não responde a nenhuma pergunta que realmente importa; o que prevê a adoção é se cada função consegue concluir seu trabalho diário real, incluindo os casos difíceis, sem sair do aplicativo.

Equipes que avaliam as lacunas uma a uma, antes do go-live, e nomeiam um responsável por cada caminho de fechamento obtêm o que o fit-to-standard promete. Equipes que marcam "80% — coberto pelo padrão" e seguem em frente obtêm um aplicativo que relata um uso respeitável, enquanto o trabalho real migra silenciosamente para o Excel, o e-mail e a transação que nunca deixou de existir.

A lacuna mais barata é aquela que você fecha em um workshop. A mais cara é aquela que seus usuários descobrem depois do go-live — porque, a essa altura, eles já a resolveram sem você.