SAP no celular: o projeto trava em identidade, não na tela

O pedido de SAP no celular chega quase sempre como pedido de app: “queremos aprovar pelo telefone”. E o projeto começa escolhendo ferramenta. Erro de ordem.

Aprovar pelo telefone é a parte fácil — o SAP entrega isso pronto há anos. O que trava não está na tela: está em como aquele telefone prova quem é, e no que acontece quando ele fica sem rede no meio da transação.

Em uma frase — SAP mobile é projeto de identidade e de conectividade, não de interface. Quem começa pela tela entrega um piloto bonito que não passa na revisão de segurança, e quem começa pela identidade entrega algo mais feio que entra em produção.

Os três caminhos, e o que cada um custa

Existem três formas de colocar SAP no celular, e elas não competem — resolvem problemas diferentes.

Fiori responsivo no navegador. O caminho mais barato: a aplicação que já existe, aberta no navegador do telefone. Funciona bem para aprovação e consulta. Não funciona offline, não usa câmera nem leitor de código de barras, e depende de o usuário lembrar o endereço.

SAP Mobile Start. O aplicativo da SAP que serve de porta: entrega o launchpad no telefone, com notificação e biometria. É o meio-termo honesto — pouco esforço, ganho real de adoção, e resolve a parte do “lembrar o endereço”.

Aplicativo nativo ou híbrido, com SAP Mobile Services no BTP. O caminho caro, e o único que resolve offline de verdade — inventário no galpão sem sinal, ordem de serviço em campo, coleta em planta. Se o requisito não é offline, quase nunca se justifica.

Identidade é onde o projeto trava

O celular corporativo raramente está no domínio. Isso significa que a autenticação que funciona no desktop — integrada, silenciosa — não existe ali. E a alternativa preguiçosa é usuário e senha, que hoje não passa em nenhuma revisão de segurança séria.

O caminho que funciona passa por três peças, e nenhuma é opcional.

Um provedor de identidade no meio. O SAP delega a autenticação para o Entra ID, o SAP IAS ou equivalente. É isso que permite exigir MFA sem ensinar o SAP a fazer MFA.

MFA resistente a phishing. Passkey ou chave de segurança. Código por SMS em aprovação financeira é convite — a troca de chip é ataque comum e barato no Brasil.

Gestão do dispositivo. Sem uma camada de MDM ou de proteção de aplicativo, o celular perdido leva a sessão junto. E a pergunta que ninguém quer responder no comitê é quanto tempo aquele token continua válido.

Ponto de atenção — biometria no aparelho não é segundo fator do SAP. O rosto ou a digital destrava o telefone, e o telefone apresenta um token que já estava lá. Se esse token não expira e não pode ser revogado à distância, a biometria é conforto, não controle. É a confusão mais comum nessas conversas.

Offline é uma decisão de negócio, não técnica

A palavra “offline” na reunião costuma significar coisas diferentes para cada pessoa da mesa, e vale desempatar antes de estimar.

Consulta offline — ver o que já foi baixado, sem alterar nada. É barato e resolve boa parte dos casos de campo.

Registro offline com envio depois — anotar agora, sincronizar quando houver sinal. Aqui aparece a primeira pergunta difícil: e se dois técnicos registrarem contra o mesmo objeto?

Transação offline completa — com regra de negócio validando no aparelho. É o mais caro, e obriga a responder o que fazer quando a validação local diz sim e o servidor diz não.

Essa terceira categoria é onde projetos param. Não por dificuldade técnica: por não haver decisão de quem manda quando os dois discordam. E essa decisão é do processo, não da TI.

Onde a IA ajuda de verdade aqui

Na triagem do que vale virar móvel. Cruzar o log de transações com o horário e o local de uso mostra rapidamente o que já é usado fora do escritório — e essa lista costuma ser bem diferente da lista que o comitê imaginou.

Onde ela não entra é na regra de conflito de sincronização. Isso é política, e política tem dono.

O limite honesto

Nem tudo deveria ir para o celular. Transação com muitos campos obrigatórios, em tela pequena, produz dado ruim — e dado ruim custa mais caro que a espera que ele economizou.

A régua que costuma funcionar: o celular é bom para decidir e para registrar; é ruim para elaborar. Aprovar, consultar, apontar, fotografar — sim. Montar um pedido de compra com trinta linhas — não.

Na Inove esse desenho entra junto com workplace moderno e práticas SAP, porque é exatamente onde os dois se encontram: identidade de um lado, autorização do outro.

Perguntas frequentes

O que é SAP mobile na prática?

São três caminhos distintos: Fiori responsivo no navegador do telefone, o aplicativo SAP Mobile Start como porta de entrada, ou um aplicativo próprio com SAP Mobile Services no BTP. Só o terceiro resolve trabalho offline de verdade, e é o único que se justifica pelo custo quando o requisito é campo sem sinal.

Preciso do BTP para usar SAP no celular?

Não para aprovar e consultar — Fiori responsivo e o Mobile Start resolvem isso sem BTP. O BTP entra quando há requisito de offline com sincronização, notificação própria ou integração com recurso do aparelho, como câmera e leitura de código.

A biometria do celular serve como segundo fator?

Não por si só. A biometria destrava o aparelho, e o aparelho apresenta um token que já estava guardado. Sem expiração curta e revogação remota desse token, a biometria é conforto de uso, não controle de acesso — e é a confusão mais comum nessas discussões.

O que costuma travar o projeto?

Identidade e conflito de sincronização. O celular raramente está no domínio, então a autenticação silenciosa do desktop não existe ali; e quando há registro offline, alguém precisa decidir quem vence se o aparelho e o servidor discordarem. As duas são decisões de negócio, não de TI.

Toda transação deveria ir para o celular?

Não. Tela pequena com muitos campos obrigatórios produz dado ruim, e dado ruim custa mais que a espera que ele economizou. A régua prática: o celular é bom para decidir e registrar, e ruim para elaborar.