Voltar ao standard é o princípio condutor em todo projeto do S/4HANA. Uma pergunta comum em reuniões é: isso pode ser alcançado usando o padrão SAP? Mas por quê? Todos os envolvidos em um projeto SAP, e principalmente os clientes*, sabem que não é possível continuar a utilizar as soluções SAP como antes. Cada funcionalidade fornecida pela SAP como padrão é uma funcionalidade a mais que o cliente não precisa desenvolver. Isso não apenas reduz os custos de desenvolvimento, mas também elimina a necessidade de manutenção dessa funcionalidade. Seu uso contínuo exige menos testes, menos esforço humano e, é claro: novas funcionalidades são introduzidas pela SAP e o uso não deve ser afetado por atualizações futuras.

A SAP dedica grande esforço para garantir que suas soluções padrão sejam discutidas pelos clientes. O esforço é um sucesso e clientes, usuários-chave, consultores e desenvolvedores estão discutindo como usar o máximo possível do padrão SAP. Agora, é entendido que cada linha de código personalizado é um fardo. É um código que deve ser mantido, ajustado a novos requisitos e consome recursos. Desenvolvedores ocupados em corrigir código antigo em vez de se envolverem em soluções que agregam valor à empresa são problemáticos. Os desenvolvedores são recursos raros. Alocá-los em coisas que podem ser obtidas prontas é um mau investimento.

Com essas restrições em vigor, raramente faz sentido não usar uma solução padrão só porque não se encaixa 100% no que os usuários-chave desejam. Considerando que os usuários-chave também entendem isso e aceitam que uma solução que lhes oferece 80% do que precisam é suficiente, os clientes podem voltar ao padrão. É uma vitória para todos. No último mês, houve uma ampla gama de eventos no universo SAP. Nestes eventos, a SAP pregou que os clientes deveriam usar seu software padrão (argumentando a favor da nuvem pública). E se um cliente não puder ou não quiser migrar para a nuvem pública, pelo menos o código personalizado deve ser escrito de forma a manter o núcleo limpo. Tornando mais fácil – ou até mesmo possível – migrar para a nuvem pública posteriormente. Os exemplos discutidos foram desde processos de RH altamente padronizáveis até programas muito específicos e personalizados. Para muitos desses casos, voltar ao padrão é viável. RH é um dos mais simples. A maioria dos processos de RH nos clientes pode ser usada conforme está e como SaaS. RH raramente é onde a empresa se diferencia e depende de processos customizados definidos. Transações escritas por um desenvolvedor específico para os requisitos do usuário-chave também podem ser um exemplo em que voltar ao padrão é possível. Ajustar algumas partes de uma transação padrão pode ser alcançado usando Screen Personas ou Flexibilidade de UI. Com campos e lógicas personalizadas, talvez nem seja necessário um desenvolvedor.

Há apenas um pequeno problema. Pequeno, mas que estraga a história contada até agora. Você pode usar o software padrão da SAP quando há um padrão disponível. O que fazer quando a SAP não oferece uma solução padrão? Um cliente pode querer voltar ao padrão, mas e se não houver para onde retornar? Voltar para o quê exatamente? A SAP oferece soluções para uma ampla gama de problemas de negócios. Mas não para todos. Nem para todos os processos de negócios. Ou não oferece para alguns processos de negócios específicos. Para preencher essa lacuna, as empresas podem procurar um parceiro que ofereça uma solução para seu processo específico do setor. Se um parceiro já trabalhou com um cliente do mesmo setor, as chances são boas de que a lacuna seja preenchida. É possível preencher a lacuna no portfólio da SAP com uma solução empacotada. Talvez não exatamente voltando ao padrão, mas ainda melhor do que ter que codificar tudo sozinho. Desde que o fornecedor forneça suporte e atualize/ajuste a solução para futuras versões da SAP, o problema é resolvido. É um núcleo limpo e (de certa forma) voltando ao padrão (do fornecedor).

E se não houver solução de parceiro disponível? Quando o código personalizado pode ser uma prática recomendada pelo setor, mas apenas para uma área pequena que não interessa nem para a SAP nem para nenhum outro fornecedor? Ou a solução personalizada é usada para implementar um processo específico do setor que é específico para a situação de um cliente? E quando nem a SAP nem um parceiro oferecem uma solução? E se a solução de código personalizado é o padrão do setor? Um padrão que a SAP não cobre? E agora? Sem padrão disponível, sem solução de terceiros, sem possibilidade de voltar ao padrão. Não é uma situação perfeita, mas isso acontece e sempre acontecerá.

Os clientes da SAP sempre precisarão, de vez em quando, desenvolver uma solução personalizada. Realizar seu processo personalizado em código. Assim como com o desenvolvimento excessivo de aplicativos personalizados que nunca deveriam ter acontecido, sempre haverá uma ampla variedade de cenários em que os aplicativos personalizados são necessários. Os aplicativos personalizados às vezes não são opcionais, são um fato. Eles são necessários, simplesmente porque não há um padrão disponível.

O problema é: quando você analisa mais de perto o problema, não é incomum descobrir que isso afeta muitas outras empresas também. Sim, é um paradoxo. A solução é única, mas ao mesmo tempo não é. Como cada cliente lida com isso é único, mas há partes em comum que compartilham. O processo é muito único para a SAP (ou um parceiro) oferecer como padrão, mas há partes compartilhadas. Manutenção, atendimento de pedidos, sites de construção inteligentes, análise de riscos, planejamento etc. O processo é individual, uma razão para a vantagem competitiva. Mas não 100% do processo. 50% podem ser comuns e realizados de forma semelhante por outra empresa.

Você pode encontrá-los em eventos onde falam sobre isso. Apresentando sua solução personalizada. E você descobre em uma conversa que eles enfrentam exatamente os mesmos problemas que você. É quando você pode perceber que seu problema específico é uma prática recomendada pelo setor que você deve implementar. Idealmente, exatamente o que a SAP deveria resolver com seu software padrão. No entanto, a SAP o ignora. Talvez ainda seja muito específico para a SAP, ou apenas adequado para uma pequena região. Pode estar no backlog por anos, sem orçamento suficiente, pessoas, tempo. Ou simplesmente não factível devido a algum outro motivo. Não importa: um problema que outras empresas têm que resolver por conta própria não é coberto por nenhum software padrão.

As empresas podem pedir à SAP para implementá-lo. Um aplicativo personalizado que entra no padrão SAP. Iniciar algum tipo de coinovação com a SAP para influenciar o roadmap do produto com o objetivo de inserir funcionalidades no padrão. Por exemplo, por meio de influência do cliente, ou DSAG ou ASUG. Ou em colaboração mais próxima com a SAP. Isso funciona (parcialmente). O problema dessas abordagens para influenciar o padrão da SAP é como elas funcionam. É difícil obter uma visão do que está sendo trabalhado atualmente. Qual é o status do backlog. Quais funcionalidades foram solicitadas, qual é o status delas? A Influência do Cliente é boa, mas ainda é um lugar onde as ideias morrem. Uma solicitação pode ser recusada pela SAP simplesmente afirmando: não planejado. Ou não ter a funcionalidade é: funciona conforme projetado. E é isso. O backlog de um produto, as funcionalidades talvez já desconsideradas, funcionalidades impossíveis devido à demanda ou estratégia interna: essas informações estão ocultas. Um cliente pode optar pela coinovação. Uma ideia muito boa. Mas ainda é um desafio ter uma visão global sobre o assunto. Quem mais está envolvido em uma coinovação que afeta as funcionalidades? Uma lista global de iniciativas ativas. Um backlog global de funcionalidades solicitadas? Quantos outros clientes tentaram obter uma funcionalidade no padrão e “fracassaram”? Essa parte obviamente não é transparente. Abrir o processo de desenvolvimento a esse grau é um risco. Mas minimizar o risco para a SAP é bom para os clientes? Não serão então os clientes os que sofrem?

Por que não tornar mais fácil ver quais funcionalidades estão em andamento? Quem solicitou e por que foi aceito/rejeitado? Votar nas funcionalidades não apenas para colocá-las no backlog (como via Influência do Cliente), mas também para priorizá-las. Assim, não é principalmente a demanda interna da SAP que impulsiona a implementação, mas sim com muito mais peso da demanda do cliente. Influenciar diretamente a próxima versão. A lista pode ser discutida em reuniões de grupos de clientes, pode ser como um ticket, discutido em eventos, reuniões etc. Problema solucionável. O principal é sair de: adicionado ao backlog, um dia estará disponível. E chegar a: a funcionalidade agora está na lista de prioridades de x clientes, é melhor começar a implementação da funcionalidade agora.

Os roadmaps dos produtos da SAP são muitas vezes como sua festa de aniversário: você sabe que receberá algo; você sabe também de quem, mas nunca sabe exatamente o quê. Mas você ainda precisa organizar a festa e limpar depois. Com uma melhor transparência, uma funcionalidade trazida por vários clientes e (ainda) rejeitada pela SAP: isso pode ser algo para os parceiros se envolverem e oferecerem uma solução. Um processo de licitação pode ser incluído. Por que não? O parceiro diz: eu implementarei isso desde que x clientes se comprometam a comprá-lo. Ou talvez até para os clientes se unirem. Claro, isso significa que isso é um desafio para a SAP. Muitas pessoas terão que mudar a forma como trabalham hoje. O foco no cliente será redefinido.

Voltar ao padrão é a decisão certa a tomar. A SAP deve garantir que seu padrão cubra o máximo possível de áreas. Voltar ao padrão precisa de um padrão para voltar. Essa é a parte ausente da SAP. Soluções de parceiros podem preencher a lacuna ainda restante. Os clientes precisam ter uma visão simples do que é solicitado, planejado ou rejeitado. E eles precisam ter uma voz melhor na decisão do que é priorizado.