Clean core: o que é preciso realmente governar.

O princípio cabe numa frase. Num sistema limpo, o núcleo mantém-se conforme ao standard do editor; tudo o que a empresa lhe acrescenta vive ao lado, numa plataforma de extensão prevista para isso, atrás de interfaces documentadas. A SAP fez dele a doutrina oficial do SAP S/4HANA e do RISE with SAP, e seria um erro ver nisso apenas um argumento de venda: a promessa de atualizações regulares só se cumpre se ninguém tiver soldado o núcleo por dentro. Mas a verdadeira razão para se interessar por isto não está no editor. Está nas suas contas.

Cada específico é uma dívida

Um desenvolvimento específico nasce sempre de uma boa intenção. Um processo que emperra, uma demonstração regulamentar que o standard não produz tal e qual, um pedido do negócio que se quer satisfazer depressa: alguns dias de desenvolvimento e o assunto está resolvido. No momento em que se codifica, um específico parece quase gratuito. É depois que começa a custar.

Custa em cada subida de versão: tudo o que toca ao núcleo tem de ser analisado, adaptado, retestado, e a fatura repete-se enquanto o código viver. Num mundo RISE with SAP, em que o editor empurra as suas atualizações ao seu ritmo, esta carga deixa de ser um acontecimento de cinco em cinco anos para se tornar uma portagem recorrente. Custa em inovação: as capacidades que a SAP entrega, a IA embarcada em primeiro lugar, apoiam-se nos processos e nas estruturas de dados standard; um núcleo cheio de exceções vê-as passar. Custa por fim em dependência: com o passar dos anos, o conhecimento de um específico concentra-se em duas ou três cabeças, e no dia em que partem, a empresa descobre que já não sabe explicar o seu próprio sistema. Num mercado em que as competências SAP são raras, este último custo é o mais pesado.

Nenhum destes custos constava do orçamento do desenvolvimento inicial. É toda a dificuldade do tema: a despesa é visível e modesta, a dívida é invisível e longa. Uma direção-geral que a ignore pagá-la-á na mesma.

O caso particular da localização

No espaço OHADA, uma parte do específico não é um capricho do negócio. As demonstrações financeiras do SYSCOHADA revisto, o IVA e as declarações próprias de cada Estado da UEMOA, os recibos de vencimento e as contribuições sociais nacionais: tudo isso tem de sair do sistema, e o standard do editor nem sempre cobre cada detalhe de cada país. Estes desenvolvimentos são legítimos. A questão não é proibi-los, mas decidir onde vivem.

A nossa posição é clara: a localização constrói-se em extensão, no SAP BTP, com interfaces documentadas, e não através de modificações no núcleo. Uma demonstração SYSCOHADA desenvolvida no exterior sobrevive às subidas de versão e é mantida por uma equipa local. A mesma demonstração codificada no núcleo do sistema terá de ser revalidada a cada atualização, pelas raras pessoas que ainda a compreendem. A diferença de custo em dez anos é considerável, e decide-se no primeiro dia.

O teste: um diferenciador provado, senão o standard

Deve-se então proscrever todo o específico fora da localização? Não, e os defensores do tudo-standard enganam-se tanto como os outros. Certos processos fazem ganhar clientes, margens ou dias de tesouraria precisamente porque não se parecem com os do vizinho. Esses merecem ser defendidos, desenvolvidos corretamente no exterior do núcleo, e mantidos como ativos.

Tudo está no critério. O nosso é simples de enunciar e desconfortável de aplicar: um específico justifica-se se for imposto pela regulamentação, ou se o processo que suporta for um diferenciador de negócio demonstrável. Demonstrável, não sentido: quem sabe dizer o que a empresa perderia, concretamente, ao passar ao standard? Se ninguém souber responder, a resposta é o standard, e é o processo que se adapta. A nossa experiência dos inventários de específicos é constante neste ponto: a grande maioria falha o teste. Reproduzem um hábito, raramente uma vantagem.

A boa pergunta não é «o que faz este específico?» mas «quanto valeria a empresa sem ele?». Se a resposta é «o mesmo», não tem nada que fazer no núcleo.

O que a disciplina exige da governação

Um critério não basta; é ainda preciso alguém para o segurar. É aqui que o tema sai da esfera técnica, porque segurar um critério é dizer não. Não a um diretor de negócio apressado, não a um projeto que já prometeu, não à solução de facilidade que reabriria o núcleo. Uma autoridade de arquitetura que não possa apoiar-se na direção-geral cederá. Educadamente, e sistematicamente.

A governação que funciona assenta em três práticas. Uma instância de decisão em que o negócio vem defender o seu pedido, com o teste do diferenciador como regra do jogo anunciada de antemão. Um registo das derrogações, a seguir: cada específico aceite fica aí inscrito com o seu proprietário, a sua justificação, a sua localização (núcleo ou extensão) e a sua data de revisão, porque uma dívida gere-se mal quando não se faz a sua contabilidade. Uma revisão em cada subida de versão, por fim: um específico tem de reconquistar o seu lugar a cada prazo, senão sai. Sem este encontro, a deriva regressa em poucos anos, por acumulação de pequenas exceções todas razoáveis uma a uma.

2027, a purga que não voltará a passar

Resta o calendário. O fim da manutenção standard do ECC, fixado para o fim de 2027 com uma extensão possível até ao fim de 2030, impõe a cada empresa uma passagem para o SAP S/4HANA. Ora, uma conversão é o único momento em que purgar custa menos do que conservar: é de qualquer forma preciso inventariar, analisar e retestar cada desenvolvimento. Triar nessa ocasião é um esforço marginal; levar tudo é converter a sua dívida ao mesmo tempo que o seu sistema, e reembolsá-la durante mais dez anos.

É por isso que defendemos que a doutrina do específico seja fixada desde o enquadramento, antes da escolha do cenário e do integrador, em vez de descoberta a meio do programa, quando cada arbitragem atrasa um marco. A empresa que chega à negociação com a sua regra do jogo, o seu registo e a sua lista de purga escolhe o seu programa. A outra sofre-o.

Para prolongar: a nossa leitura da data de 2027 para as empresas da sub-região, a nossa oferta SAP · S/4HANA e ERP e as nossas aplicações à medida, onde as extensões se concebem e se constroem.