Como o SAP S/4HANA difere de outros sistemas ERP

ADVISA SOLUÇÕES EM INFORMÁTICA

SAP S/4HANA se enquadra em uma categoria de aplicações de negócios conhecidas como sistemas ERP, um termo cunhado pela primeira vez pelo Gartner em 1990.

 

Em essência, os sistemas ERP são aplicativos projetados para administrar toda a empresa – desde recursos humanos (RH) e folha de pagamento até sourcing e compras, desenvolvimento de produtos, fabricação, vendas e distribuição. Apesar de estar na mesma categoria ampla de outros sistemas ERP, como Oracle Fusion Cloud ERP, Oracle NetSuite ERP e Microsoft Dynamics 365, o SAP S/4HANA tem diferenças atuais e históricas que são importantes de serem compreendidas. Cada uma destas diferenças tem implicações relacionadas com a auditoria (ou pelo menos pode ajudar a explicar questões/questões que possam surgir durante uma auditoria). Dito de outra forma, se você às vezes coça a cabeça e se pergunta: “Por que diabos funciona assim?” ou “O que eles estavam pensando?”, às vezes a resposta está nessas diferenças, que discutiremos nesta postagem do blog.

 

História da Empresa SAP

Embora o termo ERP ainda não tenha sido cunhado, o primeiro produto de software da SAP, SAP R/1, foi indiscutivelmente a primeira aplicação ERP do mundo. A SAP foi fundada em 1972 por cinco ex-funcionários da IBM com a visão ousada de criar a primeira solução de software empresarial integrada, padronizada e em tempo real. Os fundadores desenvolveram sua própria linguagem de programação e escreveram a aplicação do zero nesta linguagem ( ABAP ). Na verdade, os fundadores desenvolveram muitos modelos e princípios exclusivos da SAP, incluindo o conceito de autorização SAP  (um modelo de segurança do usuário).

 

Periodicamente nos perguntamos por que os fundadores da SAP desenvolveram tanto desenvolvimento personalizado, em vez de confiar nos padrões informatizados que existiam na época. Por exemplo, o Resource Access Control Facility (RACF) e o Access Control Facility 2 (ACF2) eram aplicativos de segurança de mainframe muito populares. Por que a SAP não os usou em vez de escrever seu próprio modelo de segurança? Acontece que ambos os aplicativos de segurança foram desenvolvidos após o primeiro lançamento do SAP (em 1976 e 1978, respectivamente). Do ponto de vista da auditoria, a principal implicação da história da SAP é que os desenvolvedores SAP tiveram que criar seus próprios modelos/práticas/processos para fazer as coisas bem antes da convergência dos padrões e, portanto, em muitas áreas técnicas, o SAP S/4HANA funciona de forma diferente do SAP S/4HANA. outros aplicativos ERP.

 

Arquitetura Agnóstica de Hardware

Nos primeiros dias do desenvolvimento de software, a maioria dos pacotes de software estava dependente do hardware do computador e dos bancos de dados nos quais eram executados. Isso significa que se uma organização decidisse mudar de um banco de dados legado como o IBM Db2 para um banco de dados como o Microsoft SQL Server, seria necessária uma aplicação totalmente nova. Vemos isso até mesmo em aplicativos modernos, até certo ponto, onde os aplicativos projetados para serem executados em macOS ou Unix geralmente não são compatíveis com os sistemas operacionais Windows e, portanto, exigem um conjunto separado de código. Os fundadores da SAP estavam bem à frente do seu tempo; eles desenvolveram o SAP para executar muitas coisas dentro do aplicativo que normalmente seriam feitas em uma camada mais técnica. O exemplo mais clássico disso é como o SAP interage com o banco de dados subjacente.

 

Em muitos aplicativos, atividades específicas do banco de dados (como adicionar índices, criar tabelas/campos personalizados, monitorar/ajustar o desempenho, etc.) são realizadas diretamente no banco de dados. O SAP foi desenvolvido de forma que a maioria das atividades do administrador de banco de dados (DBA) seja executada não no próprio banco de dados, mas no aplicativo. No SAP S/4HANA, existem transações específicas para DBAs criarem tabelas e campos, indexar campos, criar visualizações e monitorar o desempenho do banco de dados. Do ponto de vista da auditoria, isso significa que é muito incomum que um DBA tenha que fazer login diretamente no banco de dados e, normalmente, quando o faz, está relacionado a fins emergenciais ou de manutenção não padrão.

 

O papel da camada de aplicação SAP no banco de dados é ainda mais pronunciado no SAP ERP (e no SAP R/3 e SAP R/2 antes disso) do que no SAP S/4HANA. Por exemplo, existem categorias de tabelas, especificamente tabelas de cluster e tabelas de pool, que não são conhecidas pelo banco de dados. Além disso, os relacionamentos entre tabelas não são mantidos no banco de dados, mas sim na camada de aplicação SAP. Para ser claro, isso significa que usando uma ferramenta de consulta específica para o banco de dados no qual seu sistema SAP está sendo executado, você não verá tabelas como tabela BSEG (itens de linha de documento contábil), tabela MSEG (movimentos de materiais por item) ou tabela CDPOS (alterar detalhes de registro de documentos por campo) – eles só são acessíveis passando pela camada de aplicativo SAP em vez da camada de banco de dados. Como tal, ferramentas especiais que passam pela camada de aplicação SAP (muitas vezes através de uma chamada de função remota [RFC]) têm sido necessárias para fins analíticos de auditoria. O SAP S/4HANA elimina alguns desses requisitos ao ser habilitado para Open Database Connectivity (ODBC) e eliminar tabelas que são conhecidas apenas pelo aplicativo e não pelo banco de dados.

 

Outro exemplo de SAP com funcionalidade independente de hardware está relacionado à restrição da atividade de rede. O SAProuter não apenas atua como um roteador tradicional e permite a segmentação de rede definida no próprio aplicativo SAP, mas outros componentes do SAP atuam como um firewall. O SAP Gateway, que também é configurado diretamente no aplicativo SAP S/4HANA, pode aceitar arquivos de configuração contendo coisas como endereços IP permitidos/negados, bem como arquivos que definem não apenas quais programas os usuários externos (aplicativos) podem trabalhar, mas também qual servidor hospeda esses usuários externos. Embora nunca esperássemos que uma organização deixasse as configurações de roteador e firewall abertas porque “o SAP S/4HANA já faz isso”, um ponto forte desse modelo é que, se uma configuração de roteador ou firewall for alterada fora do SAP, o aplicativo ainda poderá manter algumas proteções básicas.

 

Nenhum aplicativo separado para desenvolvimento ou administração

Em alguns aplicativos, você pode se sentir confortável sabendo que os usuários finais ou terceiros não podem executar funções de desenvolvimento ou configuração porque não possuem ferramentas de desenvolvedor instaladas em seus sistemas. Tecnicamente no SAP S/4HANA, cada usuário possui ferramentas de desenvolvedor instaladas. Na verdade, cada usuário tem todas as ferramentas administrativas instaladas porque não há um aplicativo diferente para desenvolvedores versus administradores Basis versus administradores de banco de dados versus administradores de segurança versus usuários corporativos – está tudo no aplicativo SAP S/4HANA. A única coisa que realmente torna um desenvolvedor um desenvolvedor, um administrador um administrador e um usuário empresarial um usuário empresarial são as permissões que foram concedidas por meio de suas autorizações de segurança. Do ponto de vista da auditoria, isso significa que é mais fácil para usuários ou terceiros receberem erroneamente acesso elevado do que em aplicativos nos quais as funções administrativas e de desenvolvimento estão fisicamente separadas em aplicativos diferentes.

 

Código-fonte visível

A maior parte do SAP S/4HANA, incluindo todo o código que executa atividades comerciais padrão que conhecemos, é executado a partir de código que é completamente visível para usuários com as devidas autorizações. Ao contrário de muitos aplicativos em que o código que executa a funcionalidade principal é uma caixa preta, o SAP torna o código SAP S/4HANA transparente. Do ponto de vista da auditoria, este é um enorme benefício. Se houver dúvidas sobre o que um programa SAP específico está fazendo, o auditor (provavelmente auxiliado por alguém que saiba ler o código ABAP) poderá fazer essa determinação definitivamente. A única exceção a esta declaração de “código visível” diz respeito a operações muito técnicas (como a forma como a SAP prioriza processos de trabalho ou opera na camada de comunicação), o que se deve à sua natureza muito técnica e ao fato de não impactarem diretamente o resultado de um processo de negócios e muitas vezes não estão no escopo de uma auditoria.

 

Código-fonte sincronizado com código executável compilado

Em muitos aplicativos de computador comuns, os desenvolvedores usam uma linguagem de programação de computador para escrever linhas de código, cuja versão final é conhecida como código-fonte original. Embora o código-fonte defina a ordem e a lógica das operações do computador a serem executadas pelo aplicativo, os próprios computadores subjacentes não podem ler diretamente o código-fonte. Uma vez pronto para ser executado, o código-fonte deve ser compilado , que é um processo que transforma o código de algo que um programador pode entender em algo que um computador pode entender. A compilação do código-fonte gera, em última análise, o código executável que os computadores executam.

 

Devido a esse processo de “codificar primeiro e depois compilar”, muitos aplicativos de computador estão sujeitos ao risco de que a versão compilada (executável) do código seja diferente do código-fonte final pretendido pelo desenvolvedor. Isso pode ser o resultado de o desenvolvedor ter esquecido de compilar o código, o aplicativo de computador ser apontado para uma versão mais antiga do código compilado (e não atualizado para apontar para o código compilado mais recente), um invasor inserir seu próprio código compilado que não não representa o que o desenvolvedor escreveu ou uma infinidade de outros fatores semelhantes. Assim, é comum que durante uma auditoria de TI relacionada ao código, o auditor realize testes para garantir que os arquivos executáveis ​​sejam atuais e relacionados à versão aprovada mais recentemente do código-fonte.

 

No SAP S/4HANA, o código fonte e o código compilado estarão sempre sincronizados, portanto não há risco de os dois serem diferentes. Isso ocorre porque o SAP sempre começa com o código-fonte. Mais especificamente, quando um servidor que executa o aplicativo SAP S/4HANA é iniciado (ou reinicializado), não há código compilado existente. Na primeira vez que um usuário executa um programa após a inicialização, o SAP S/4HANA irá ler o código-fonte e compilá-lo em tempo real. Do ponto de vista da auditoria, isto significa que o risco de o código-fonte não ser consistente com o código compilado não é relevante.

 

Se você já executou uma transação ou programa no SAP e notou um relógio na barra de status com a legenda “compilando”, significa que você é a primeira pessoa a executar esse programa no servidor SAP desde a reinicialização.

 

Menos personalizações Greenfield

Embora o SAP S/4HANA, como outros sistemas ERP, permita que as organizações usuárias façam personalizações, as verdadeiras personalizações greenfield são limitadas (pelo menos em comparação com outros sistemas ERP com os quais trabalhamos) e mais estruturadas. Primeiro, a SAP protege seu próprio código contra modificações e, usando a funcionalidade SAP padrão, é impossível modificar o código entregue pela SAP sem receber permissão e assistência da SAP. Onde as organizações tiveram que desenvolver seu próprio conjunto de funcionalidades porque faltava código entregue pela SAP, a SAP faz um ótimo trabalho na identificação dessas áreas, trabalhando posteriormente com a organização para entender e aprimorar o que foi desenvolvido (muitas vezes trazendo a equipe relevante do cliente membros para a sede da SAP na Alemanha) e, finalmente, incorporando esta nova funcionalidade em versões futuras. Como tal, o que antes era personalizado muitas vezes se torna padrão em versões posteriores.

 

A SAP também faz um bom trabalho ao antecipar onde um código mais avançado/personalizado pode ser necessário e ao incorporar saídas de usuário (seções de código que podem chamar código definido pelo usuário ou de terceiros e retornar valores de volta ao bloco de código principal) em programas padrão para que o programa principal possa ser executado com entradas personalizadas, sem exigir uma reescrita completa. Por último, a SAP tenta manter o máximo de customização possível nos formulários padrão fornecidos no Guia de Gerenciamento de Implementação (IMG). O IMG é semelhante à área de “opções” dos produtos Microsoft, onde, através de caixas de seleção, preenchimento de campos e seleção de listas suspensas, você pode efetivamente fazer com que seus produtos Microsoft se comportem de maneira diferente dos produtos do seu vizinho (sem nunca ter que escrever uma única linha de código).

 

Frequentemente ouvimos usuários frustrados de TI ou de negócios reclamando que a SAP cria software inflexível que é difícil de personalizar de acordo com a forma como uma organização funciona. Na nossa experiência, argumentaríamos que o SAP é muito flexível, mas apenas de uma forma altamente estruturada. Embora seja verdade que o SAP S/4HANA geralmente não permite coisas que algumas organizações consideram requisitos, nossa experiência mostra que muitas vezes esses requisitos são baseados em formas legadas e desatualizadas de fazer negócios que, para começar, não são boas práticas. Por exemplo, trabalhamos com organizações que reivindicaram a exigência de colocar mercadorias recém-adquiridas no processo de fabricação antes que o recebimento de mercadorias relacionado fosse inserido no SAP. Isso para nós parece um indicativo de um processo de recebimento interrompido. Acreditamos que a forma altamente estruturada como o SAP S/4HANA permite customizações o torna um programa muito mais confiável do que aquele que permite aos usuários finais personalizá-lo efetivamente como quiserem.

 

Curiosidades

Para encerrar nossa introdução ao SAP S/4HANA, deixamos algumas curiosidades sobre a suíte.

O nome

O nome original em alemão da empresa, SystemAnalyse Programmentwicklung, é traduzido para o inglês como System Analysis Program Development. Vários anos após o início, a SAP renomeou-se para Systeme Anwendungen und Produkte in der Datenverarbeitung, que se traduz em Sistemas, Aplicativos e Produtos em Processamento de Dados. A empresa agora atende pelas suas iniciais, SAP.

A pronuncia

Embora você ouça regularmente o nome da empresa pronunciado incorretamente, de acordo com https://www.sap.com/about/company/what-is-sap.html , SAP é “…pronunciado como letras individuais (SAP). SAP não é pronunciado como uma palavra ('sap').

A localização

A SAP está sediada numa pequena cidade alemã chamada Walldorf, que tinha uma população estimada de 15.545 pessoas em 2020. Se todos os funcionários da SAP se mudassem para Walldorf, a população da cidade aumentaria cerca de sete vezes (a SAP tem quase 110.000 funcionários em todo o mundo).

Nomes de produtos iniciais

A segunda grande versão do principal software da SAP era conhecida como SAP R/2, e a terceira versão era conhecida como SAP R/3. Embora não seja tecnicamente o nome na época, muitos agora se referem à versão inicial como SAP R/1. O “R” significa tempo real, o que era exclusivo da SAP, já que a maioria dos aplicativos da época usava processamento periódico em lote. O “2” e mais tarde o “3” representa o número de camadas da arquitetura. Sendo o SAP R/2 a versão mainframe, a camada de banco de dados era separada da camada de aplicação, criando uma arquitetura de duas camadas. O SAP R/3 migrou do mainframe para o PC e incluiu não apenas a camada de banco de dados e a camada de aplicação (servidor) separadas, mas também transferiu a camada de apresentação (cliente) para o PC, tornando-o uma arquitetura de três camadas.

Idiomas Suportados

A SAP suporta mais idiomas do que qualquer outro sistema ERP do mercado. No momento em que este artigo foi escrito, o SAP S/4HANA oferece suporte a 39 idiomas e o SAP Translation Hub oferece suporte a 45 idiomas.

O legado

A SAP é uma das mais antigas empresas de software ainda em operação no mundo. Embora a IBM e a Hewlett-Packard já existissem muito antes da fundação da SAP, a SAP como empresa é mais antiga que a Microsoft, a Apple e a Oracle. Na verdade, a SAP é 22 anos mais velha que a Amazon e, no momento desta publicação, tem o dobro da idade do Google e mais de três vezes a idade do X e do Workday.

ADVISA SOLUÇÕES EM INFORMÁTICA