Para quem usa SAP MII | PCO
O fim do suporte ao SAP MII e ao SAP PCO costuma ser tratado como um problema de aplicação. Não é: é um problema de integração. Esta página explica o calendário real, o que está de fato em risco e quais são os caminhos — inclusive o de não ir para o SAP DM.
Suporte pleno da SAP. O melhor momento para diagnosticar e planejar sem pressa.
31/12/2027: última data com manutenção principal incluída no contrato.
Suporte apenas via Extended Maintenance, contratada à parte.
Um programa de migração leva de um a três anos. Começar aqui é apertado.
31/12/2030: sem correções, sem patches de segurança, sem suporte padrão.
Datas conforme os comunicados públicos da SAP sobre o fim de vida do SAP MII. Confirme o calendário aplicável ao seu contrato junto à SAP antes de planejar.
O que está em jogo
Quando a conversa sobre sair do SAP MII começa, ela costuma começar pelas aplicações Web — as telas que o operador usa. São visíveis, todo mundo tem opinião sobre elas, e por isso viram o centro do projeto. Mas quem mantém um ambiente SAP MII há anos sabe que a parte difícil está embaixo: as transações que falam com o ERP, os laços que leem o CLP, as filas que seguram a produção quando o SAP não responde.
Essas integrações raramente estão documentadas em um lugar só. Foram construídas ao longo de anos, por equipes diferentes, e boa parte do que se sabe sobre elas está com pessoas, não em papel. É esse acervo que o fim do suporte coloca em risco, e é ele que leva mais tempo para reconstruir — não a interface.
Trocar a camada de integração antes de mexer nas telas inverte a ordem de risco do projeto: tira-se do ar primeiro a plataforma que perdeu suporte, e decide-se sobre o front-end depois, sem prazo em cima.
Decisão
Não existe uma resposta única — existe a resposta que cabe no seu risco, no seu orçamento e no seu calendário. Os cinco caminhos que aparecem na prática:
Custo baixo agora, risco crescente depois.
Nada para de funcionar em 31/12/2027. O que acaba é a correção de defeito, o patch de segurança e o suporte contratado. Para uma planta que roda 24 horas, operar uma camada de integração sem correção de segurança é uma decisão que precisa passar pela área de risco, não só pela de TI.
Faz sentido para quem quer um MES. Nem todo mundo quer.
O SAP Digital Manufacturing é um MES na nuvem SAP BTP, com custo recorrente e um projeto de implantação próprio. Para quem usava o SAP MII como MES, é uma sucessão natural. Para quem usava o SAP MII como camada de integração — que é a maioria — é comprar outra categoria de produto para resolver o problema que se tinha.
Resolve o prazo primeiro e preserva o que funciona.
As integrações com SAP e com o chão de fábrica saem do SAP MII e passam a rodar em uma plataforma com suporte, mantendo as mesmas BAPIs, os mesmos IDocs e os mesmos equipamentos do outro lado. As telas continuam de pé enquanto você decide o que fazer com elas. É o caminho que o CMS foi feito para atender.
Sai do SAP MII por inteiro, sem herdar o débito técnico.
A integração passa para o CMS e as aplicações Web construídas sobre o SAP MII são refeitas em tecnologia atual — desacopladas, responsivas e sob o seu controle. Custa mais e leva mais tempo do que trocar apenas a integração, mas encerra o assunto: não sobra nada preso ao ciclo de vida de um produto de terceiro.
Fica no ecossistema SAP sem terceirizar o chão de fábrica.
As aplicações Web migram para o SAP BTP e o Integration Suite cuida das integrações entre sistemas corporativos. O CMS entra onde o Integration Suite não alcança: OPC UA, Modbus, CLP, historiadores e o resto do chão de fábrica. Para quem já decidiu investir em BTP, é a divisão de trabalho que evita forçar uma ferramenta corporativa a conversar de forma direta com equipamento e APIs internas, sem um hub de integração e controle.
Dúvidas frequentes
A manutenção principal incluída no contrato vai até 31/12/2027. Depois disso o suporte existe apenas como Extended Maintenance, contratada à parte e com custo adicional, até 31/12/2030. A partir de 2031 não há correção, patch de segurança nem suporte padrão.
Não. Nada é desligado remotamente. O que termina é o direito a correção de defeito, patch de segurança e atendimento. O ambiente continua rodando — o que muda é que qualquer problema novo passa a ser seu, sem canal para escalar.
Não. O SAP DM é a sucessão que a SAP oferece, mas é um MES em nuvem, com escopo e custo próprios. Se você usa o SAP MII como camada de integração entre o SAP e o chão de fábrica, e não como MES, o CMS é um caminho que resolve o fim do suporte e agrega diversas tecnologias atuais e de ponta.
Dá para usar os dois, e costuma ser o melhor arranjo: eles resolvem camadas diferentes. O Integration Suite é forte na integração entre sistemas corporativos, mas não fala os protocolos do chão de fábrica — não há OPC UA, Modbus, Sparkplug B, leitura de CLP nem historiador como o AVEVA PI. Ele transporta MQTT pelo Advanced Event Mesh, mas como barramento corporativo de eventos, não como cliente de equipamento. E, por rodar em nuvem, colocá-lo no caminho entre um equipamento e o SAP cria uma dependência de conectividade que a produção não aceita: quando o link cai, a linha não para de produzir junto. O CMS fica ao lado do equipamento, fala esses protocolos e segura a fila local até o SAP voltar. Numa arquitetura com BTP, o Integration Suite cuida do corporativo e o CMS cuida da fábrica.
Porque não é o trabalho dele. O MES existe para executar e rastrear a produção, e é nisso que o fornecedor investe. A conectividade costuma vir como uma API que recebe dados: resolve a entrada, mas não o que acontece em volta dela — segurar a fila quando o ERP não responde, reprocessar só o que falhou, avisar às três da manhã que uma conexão caiu, mostrar o que ia dentro de cada mensagem. Sem isso, a falha só aparece quando a produção percebe. E um MES raramente é dimensionado para manter dezenas de conexões vivas e ler tag de CLP em laço, então cada integração nova vira dependência do roadmap do fornecedor. O CMS assume essa camada para qualquer sistema de fábrica, e o MES volta a fazer o que faz bem.
Sim, e costuma ser o caminho de menor risco. As telas legadas continuam no ar enquanto a integração passa a rodar em uma plataforma com suporte. A decisão sobre o front-end fica para depois, sem o prazo do fim de vida pressionando.
O SAP Plant Connectivity acompanha o mesmo movimento do SAP MII. É o componente que conversa com OPC, CLP e equipamento de chão de fábrica, então quem depende dele para coleta precisa tratá-lo no mesmo plano — não como um item separado.
Não. As mesmas BAPIs, RFCs e IDocs continuam sendo chamados, com os mesmos parâmetros. O que muda é quem faz a chamada. O contrato com o lado SAP é preservado, que é justamente o que torna esse caminho mais curto do que reconstruir tudo.
Um programa completo de migração, incluindo front-end, varia bastante de um ambiente industrial para outro. Fazemos um levantamento do seu caso e devolvemos uma estimativa. Trocar apenas a camada de integração é bem mais curto, porque o escopo é conhecido e não depende de redesenhar a experiência do operador.
Pelo inventário. Antes de escolher plataforma, é preciso saber quantas integrações existem, o que cada uma faz, com que sistema fala e quem depende dela. Em quase todo ambiente SAP MII esse levantamento revela integrações que ninguém lembrava — e é ele que define o tamanho real do projeto.
Por onde começar
Antes de escolher plataforma, é preciso saber o que existe. Enviamos a planilha que usamos no início de todo projeto de migração: treze colunas que, na prática, mudam a decisão — cada uma explicada no próprio arquivo, com uma linha de exemplo já preenchida.
