SAP 2027 visto de Marrocos : uma data de decisão antes de ser uma data de migração.

Toda a gente conhece o prazo. A SAP anunciou o fim da manutenção standard do ECC para o final de 2027, com uma extensão paga possível para além dessa data para quem a escolher. No papel, ainda há tempo. Na prática, uma transformação do núcleo de gestão enquadra-se, arbitra-se, contratualiza-se e depois executa-se, e cada uma destas etapas conta-se em trimestres. Quem raciocina em data de fim de manutenção já está atrasado. Quem raciocina em data de lançamento do seu programa mantém o controlo do calendário, do orçamento e da escolha dos seus parceiros.

Porque é que 2027 se lê de outra forma a partir de Casablanca.

As empresas marroquinas e africanas partilham com as europeias a mesma restrição técnica. Não partilham nem o mesmo ponto de partida nem o mesmo ambiente. Três diferenças pesam na decisão.

• Paisagens de sistemas muitas vezes mais jovens, mas mais heterogéneas. Muitos sistemas ECC da região foram implementados por vagas, filial após filial, por vezes por integradores sucessivos. O resultado é um núcleo menos antigo do que na Europa, mas menos harmonizado : vários modelos de processos coabitam sob um mesmo logótipo.
• Exigências locais que não se negoceiam. Fiscalidade e faturação eletrónica em evolução, plano de contas, obrigações declarativas, proteção de dados pessoais, especificidades da folha de salários ou das alfândegas conforme os países : um programa que as trata no fim do percurso paga-as caro.
• Um mercado de competências mais estreito. À medida que o prazo se aproxima, os perfis S/4HANA rarefazem-se em todo o lado. Na região, onde o viveiro é mais pequeno, os retardatários negociarão o seu programa nas piores condições de disponibilidade.

Estas diferenças não tornam a decisão mais difícil. Tornam-na mais urgente, e mais local : um cenário copiado de um grupo europeu sem o passar pelo filtro da sua realidade é um cenário que falhará no primeiro obstáculo regulamentar.

Três cenários, nenhuma doutrina.

O debate público opõe de bom grado a conversão « rápida e sem risco » à nova implementação « ambiciosa mas interminável ». O terreno é menos categórico. Existem três famílias de trajetórias, e a boa escolha deduz-se do seu existente, não de uma convicção de editor ou de integrador.

A conversão

Converter o sistema existente preserva o histórico, os processos e os desenvolvimentos. É a sua força, e o seu limite. Convém às empresas cujo núcleo ECC se manteve são : processos harmonizados, desenvolvimentos específicos controlados, dados limpos. Converter um sistema desordenado equivale a mudar de casa com as caixas sem as abrir : a desordem chega intacta à nova casa, onde custa mais caro a manter.

A nova implementação

Partir de um sistema novo permite adotar o standard S/4HANA, expurgar anos de desenvolvimentos específicos e reconstruir os processos sobre uma base limpa. É o caminho mais transformador, logo o mais exigente : supõe que a empresa aceite mudar as suas formas de fazer tanto quanto a sua ferramenta. Para os grupos da região que querem finalmente unificar as suas filiais num modelo comum, é muitas vezes a oportunidade a não perder. Desde que não se conduza um greenfield como uma conversão disfarçada, em que cada desvio ao passado se renegoceia linha a linha.

A transição seletiva

Entre as duas, as abordagens seletivas permitem triar : conservar o histórico e os processos que têm valor, refazer o resto. Para os grupos multipaís com paisagens de sistemas heterogéneas, onde não existe nenhuma resposta única, é frequentemente a via pertinente. É também a mais exigente em arquitetura, e a que menos perdoa a improvisação.

O cenário não se escolhe num catálogo. Deduz-se de um diagnóstico honesto dos seus processos, dos seus desenvolvimentos específicos, dos seus dados e da sua capacidade de absorção.

RISE, cloud pública : ler as ofertas com os olhos do comprador.

A questão do alvo duplica-se hoje numa questão de oferta comercial. RISE with SAP reúne licença, infraestrutura e serviços numa subscrição, em cloud privada. A cloud pública, com GROW, impõe o standard e um ritmo de atualizações ditado pelo editor. Estas ofertas não são nem boas nem más em si ; convêm a perfis de empresa diferentes.

Visto da região, três pontos merecem uma atenção particular. A localização dos dados, primeiro : onde estão alojados os seus dados, sob que jurisdição, e o que diz a regulamentação do seu país e dos seus setores regulados ? A conectividade, depois : um núcleo de gestão na cloud supõe ligações de rede cuja qualidade e redundância não se supõem, verificam-se. O modelo económico, por fim : a subscrição alisa a despesa, mas compromete-a no tempo e em divisa. Um diretor financeiro deve poder comparar os cenários em custo completo ao longo de vários anos, não pelo preço do primeiro.

A nossa posição : a cloud pública é uma excelente resposta para uma entidade que aceita o standard e quer ir depressa, uma filial nova por exemplo. A cloud privada continua a ser a via natural das paisagens de sistemas complexas. O que conta não é a palavra « cloud », é a disciplina de arquitetura que a acompanha : um núcleo limpo, extensões ao lado do standard e não dentro dele, para que o novo sistema não reproduza a deriva do antigo.

As exigências locais, à cabeça e não em anexo.

Vemos demasiados programas em que a conformidade local chega no fim da conceção, como um lote à parte confiado às equipas do país. É o inverso que é preciso fazer. O plano de contas, as obrigações fiscais e declarativas, a faturação eletrónica quando se impõe, a proteção de dados pessoais, a gestão das divisas e dos fluxos intragrupo devem ser colocados desde o enquadramento, país por país, porque condicionam o modelo de dados e o recorte das vagas.

Para um grupo marroquino que opera na África Ocidental ou Central, isso significa uma coisa concreta : o modelo comum deve ser concebido para absorver as diferenças locais sem transformar cada uma delas num desenvolvimento específico. É um trabalho de arquitetura funcional, e é aí que a presença de equipas que conhecem estes contextos faz a diferença entre um deployment que se estende e um deployment que se atola.

Decidir em poucas semanas, não em alguns trimestres.

A nossa convicção é simples : a primeira etapa não é nem um concurso nem uma escolha de ferramenta. É um enquadramento curto e decisivo, que entrega três coisas à direção-geral.

• Um levantamento sem complacência do sistema existente : processos, desenvolvimentos específicos, dados, custos, riscos, obrigações locais. Um diagnóstico que tira consequências, em vez de mais um inventário.
• Cenários realmente comparados, em custo completo e em benefícios esperados, com as suas condições de sucesso explícitas. Um cenário sem condições de sucesso é um argumentário comercial.
• Um roteiro por vagas, sequenciado segundo as dependências, a capacidade de absorção das equipas e os prazos regulamentares de cada país, em que cada etapa entrega valor intermédio.

Este enquadramento muda a relação de forças. A empresa que sabe o que quer, em que ordem e em que condições, escolhe os seus parceiros em vez de os sofrer. E é aí que a restrição se torna uma oportunidade : o prazo oferece o que nenhum programa obtém facilmente, o alinhamento de toda a empresa, sede e filiais, numa mesma data. Seria uma pena fazer dela apenas uma migração técnica.

Uma última coisa, que se prende com a nossa forma de trabalhar : quem enquadra deve ser quem entrega. Um cenário recomendado por uma equipa que nunca suportará a sua realização é um cenário sem responsável. Preferimos comprometer o nosso nome em ambos.

O que reter

2027 é uma data de decisão. Esperar pela extensão de manutenção sem trajetória é deixar o mercado, as competências e o calendário decidir no seu lugar.

O cenário

Conversão, nova implementação ou transição seletiva : a escolha deduz-se de um diagnóstico dos seus processos, dos seus desenvolvimentos específicos, dos seus dados e da sua capacidade de absorção, nunca de uma doutrina.

O local primeiro

Exigências fiscais, regulamentares e de dados de cada país à cabeça do enquadramento, não em anexo. O modelo comum deve absorver as diferenças sem as transformar em desenvolvimentos específicos.

O primeiro passo

Um enquadramento de poucas semanas : levantamento, cenários comparados, roteiro por vagas. Depois, uma decisão ao nível da direção-geral.

Para ir mais longe : a nossa oferta SAP S/4HANA, a nossa abordagem do enquadramento à realização, e o nosso ponto de vista sobre a fundação de dados, que se constrói na maioria das vezes no mesmo movimento.