Observação: Fiori é qualquer aplicativo que siga as diretrizes de design Fiori (Fiori Design Guidelines) e utilize tecnologia SAP, como UI5, Fiori Elements, MDK, Fiori SDK nativo ou Analytics.

Participei do SAP Fiori Innovation Day em Heidelberg. Um dos tópicos discutidos foi como implementar o Fiori nos clientes. Existem diversas abordagens possíveis, como: começar por aplicativos lighthouse, envolver os key users, deixar a Fiori UX falar por si só, reduzir custos ou aumentar a produtividade.

Para que essas abordagens funcionem melhor, um cenário positivo deve servir como ponto de partida. Ou seja, um aplicativo padrão que já funcione bem ou que possa ser facilmente ajustado, e que ofereça um benefício imediato ao usuário com a experiência Fiori. Normalmente, a satisfação gerada por esse primeiro contato se espalha para outros processos, apps e áreas da organização, impulsionando a adoção do Fiori como um todo.

Um exemplo comum de app usado nessa estratégia pode ser um inbox app (para gestores) ou um time reporting app (para colaboradores). Esses aplicativos atacam uma dor real de usuários específicos: gestores podem aprovar fluxos de trabalho diretamente do celular; colaboradores podem registrar suas horas com menos cliques. O acesso aos apps pode até incluir SSO (Single Sign-On) e ser feito diretamente do smartphone, sem necessidade de abrir o laptop ou iniciar uma VPN manualmente.

Como resultado, os usuários ficam mais do que satisfeitos em utilizar o Fiori e acabam se tornando embaixadores de outros projetos Fiori. Essa é uma abordagem comprovada e eficaz — e a SAP apoia totalmente essa estratégia. A Fiori App Library inclusive já conta com uma seção especial dedicada a apps lighthouse e cenários.

App Lighthouse

O problema é: isso funciona muito bem no início, mas não escala tão bem. O limite é alcançado quando se mira em uma gama mais ampla de processos, usuários e aplicativos. Quando se sai do mundo “feliz” dos apps lighthouse e se chega aos aplicativos que fazem parte de um processo comum. Simplesmente não há apps lighthouse suficientes para cobrir todos os processos e tarefas. Focar em alguns poucos apps lighthouse leva, no início, a uma experiência do usuário fragmentada. O usuário pode acabar tendo que trabalhar com diferentes tecnologias. Às vezes, ele recebe Fiori para um caso de uso interessante, mas que não é crítico para ele.

Processos A e B são baseados em SAP GUI nos sistemas SAP A e B, respectivamente, e são os que o usuário precisa utilizar diariamente. O app Fiori está disponível em um novo sistema S/4HANA, com acesso via SAP Build Work Zone. O usuário não tem nenhum benefício direto com o app Fiori em relação ao trabalho diário realizado nos processos A e B. Em vez disso, um novo sistema e cliente (navegador web em vez do SAP GUI) foram introduzidos. O usuário até pode executar o app a partir de um launchpad central, como o SAP Build Work Zone. No entanto, para executar o processo A, ainda é necessário usar o SAP GUI e se conectar ao sistema A; para o processo B, é preciso fazer login no sistema B. Isso resulta no fato de que o usuário precisa utilizar 3 sistemas diferentes para executar todos os aplicativos.

Embora os colaboradores possam, por exemplo, registrar seu tempo usando um app Fiori, o trabalho diário com o SAP nos processos A e B continua inalterado: lidar com ordens, materiais, notificações etc. O app lighthouse funciona em paralelo aos outros apps. O app Fiori se destaca — mas nem sempre da forma desejada. Ele acaba ficando isolado: em termos de sistema, acesso e tecnologia. A abordagem de implementação do Fiori baseada em apps lighthouse pode inclusive gerar carga de trabalho adicional para o usuário. Em vez de simplesmente utilizar uma transação no SAP GUI para registrar o tempo no sistema SAP, o usuário agora pode ter que usar um navegador. Isso implica alternar entre clientes, ambientes e experiências de uso. Embora o app Fiori ofereça uma experiência de usuário superior, em um primeiro momento ele representa uma interrupção a mais para quem está na ponta.

Extensão de processo

O sentimento negativo de ter um app Fiori separado e isolado pode ser minimizado com a criação de um app que faça parte de um processo. Esse app pode não ser necessariamente parte integral de um único processo, mas sim oferecer uma funcionalidade reutilizável. Um exemplo é um app para workflows. Uma funcionalidade genérica é oferecida a uma ampla gama de usuários, não apenas em um contexto ou processo específico.

O benefício: o Fiori é introduzido e gera valor direto para os usuários que trabalham em tarefas que atravessam diferentes processos. Garantir a adoção do app é essencial. No entanto, o problema de múltiplos clientes e ambientes continua. E, caso o app Fiori seja apenas opcional — oferecendo, por exemplo, informações adicionais — ele pode acabar nem sendo utilizado ativamente pelo usuário.

Essa abordagem pode até dificultar a adoção do Fiori. Para o processo B, com um app Fiori obrigatório, o usuário agora precisa sair de seu cliente habitual e mudar para um navegador da web e um sistema diferente.

UX fragmentada no Fiori

Aplicativos Fiori isolados ainda não resolvem o problema geral de adoção. Não é o processo como um todo que está sendo transformado. Na verdade, ações devem ser tomadas para garantir que essa abordagem não se torne uma prática prejudicial: implementar o Fiori sem levar em consideração os usuários e seus processos. Esse caso ocorre quando aplicativos Fiori individuais são implementados. Nesse cenário, o usuário tem vários aplicativos Fiori disponíveis, que não estão conectados nem oferecem benefícios ao executar um processo.

Um aplicativo Fiori para pedir equipamentos pode estar disponível, mas pode não ter nada a ver com os processos A ou B. O usuário pode precisar pedir um novo laptop talvez apenas uma vez a cada três anos. No total, o aplicativo pode trazer benefícios para a empresa, mas não para o usuário individual.

Do ponto de vista de gestão ou do líder de projeto de implementação do Fiori, os alvos e KPIs definidos podem ser cumpridos. Existem vários aplicativos Fiori que são usados por um número suficiente de usuários. O conhecimento sobre como trabalhar com o Fiori é gerado. O relatório para a gestão é um sucesso. Mas e para os usuários?

Embora aplicativos Fiori selecionados possam – e devam – ser usados para começar a jornada Fiori, a perspectiva de ponta a ponta é importante. As empresas compram e utilizam o SAP para poderem conduzir seus negócios. E isso significa que os funcionários devem se concentrar em suas tarefas. Para garantir que os funcionários possam focar no seu trabalho, os clientes que implementam o Fiori devem levar em consideração duas definições:

Fiori Readiness

A Fiori Readiness indica se um processo pode ser executado completamente utilizando aplicativos Fiori.

Fiori Completeness

O Fiori Completeness indica se os aplicativos Fiori usados estão totalmente alinhados com as diretrizes atuais do Fiori.

Considerar ambos, Fiori Readiness e Fiori Completeness, deve ajudar na implementação do Fiori de maneira que ofereça benefícios suficientes para aproveitar ao máximo a solução. Isso é válido tanto do ponto de vista do usuário final quanto do ponto de vista do negócio.

Eu entrarei em mais detalhes sobre ambas as definições em posts futuros.

Deixe o mundo saber