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.
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.
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.