Por Reynald Fléchaux

Pauline Flament, diretora-geral de Tecnologia da Michelin, faz uma retrospetiva das duas grandes mudanças tecnológicas ocorridas recentemente no departamento de TI do fabricante de 29 mil milhões de euros: a cloud e o fabrico inteligente, que leva as TI às cerca de 80 fábricas do Grupo. Estas mudanças tiveram de ser acompanhadas em termos de competências, práticas e ferramentas. Isto conduziu ao que a CTO descreve como “uma transformação profunda do negócio das infraestruturas” e “a sua reinvenção em torno de um certo número de novos princípios”.

Uma reinvenção que visa também projetar-se num novo campo: as fábricas do Grupo. No passado, estas eram muitas vezes totalmente autónomas em termos de informática, mas agora estão cada vez mais ligadas a sistemas partilhados. A Michelin acompanha esta fusão TI/OT com programas de convergência, o primeiro dos quais, centrado nas camadas de infraestrutura, acaba de ser concluído. O objetivo agora é implantar um modelo homogéneo de servidores nas fábricas, combinado com recursos de cloud.

CIO: A Michelin lançou uma estratégia de cloud-first. Qual é o ponto de situação da vossa migração para ambientes de cloud?

Pauline Flament: Como muitas empresas, implementámos uma estratégia de cloud-first, que deve ser vista sobretudo como um lema dirigido às equipas internas, para as incentivar a mudar a sua forma de trabalhar. Passar para a cloud significa transformar não só a conceção das aplicações, mas também a forma como os programadores trabalham, nomeadamente na cadeia CI/CD. Por isso, tivemos de criar uma estratégia que colocasse a cloud em primeiro lugar para fazer a bola rolar. Foi o que fizemos há 5 ou 6 anos. Na altura, estávamos bastante à frente do mercado. Atualmente, estamos mais em linha com a média, com 30 a 40% das nossas aplicações na cloud.

Hoje, o lema passou a ser: “Cloud first but not only”, porque fomos apanhados pela realidade. Ao trabalhar principalmente com hiperescaladores, deparámo-nos com questões legais, como as ligadas ao RGPD, mas também com questões geopolíticas. Não podemos alojar todos os nossos dados e processos com estes atores. Nalguns países, essa escolha levantaria demasiadas restrições ou não seria sustentável. A política de cloud-first levou-nos, portanto, a questionar quais os dados, processos e algoritmos mais confidenciais e o nível de confiança que pode ser depositado num parceiro.

E não devemos esquecer os condicionalismos específicos de certas aplicações. Quando se pretende passar para o tempo real ou processar grandes volumes de dados, a cloud já não é adequada. Não devemos perder de vista o facto de a Michelin ter uma grande área industrial, com alguns locais bastante isolados que apenas beneficiam de uma largura de banda limitada. Por isso, somos obrigados a manter uma presença informática na fábrica, nem que seja para garantir a continuidade da atividade. Por fim, queremos limitar os riscos de dependência de um único fornecedor. Atualmente, mudar de uma cloud para outra continua a ser difícil, porque a cadeia de ferramentas continua a ser específica de um determinado fornecedor.

Qual é a situação atual?

Estamos num cenário multicloud, com uma cloud primária e uma cloud secundária, para as quais assinamos contratos-quadro. Estamos a estabelecer relações com players locais. Com base nisso, assinámos um contrato com um player francês. E perguntamo-nos sobre a conveniência de fazer o mesmo na China. Além disso, durante cerca de 18 meses, os editores de aplicações SaaS permitiram que as empresas escolhessem a sua própria hospedagem em cloud, o que permite-nos explorar os nossos contratos de estrutura e atingir os volumes listados.

Na estratégia de aplicações, como são feitas as compensações entre a modernização na cloud e a manutenção no local?

Primeiro, como parte do lançamento da nossa estratégia de cloud, fomos oportunistas. Em vez disso, foram novas aplicações que foram transferidos para a cloud. Porque, na transformação de aplicações existentes, a equação económica nem sempre está presente. Hoje, contamos com estratégias de publishers. No entanto, a maioria das aplicações de back-office, que historicamente eram locais, está a evoluir para SaaS. Assim apoiamos este movimento… quando nos faz sentido! A cloud também é adequada para todas as interfaces próximas dos clientes ou para aplicações que precisam de evoluir rapidamente, pois esses ambientes fornecem flexibilidade e acesso rápido à inovação, principalmente em dados.

A transformação para a cloud tem impacto nos developers, mas também na produção, porque parte da responsabilidade é transferida para os hyperscalers. Quais são as consequências desse movimento dentro da sua organização?

É, de fato, uma transformação profunda dos negócios de infraestrutura que nos levou a reinventar-nos. Contamos com uma transformação Lean para redefinir as nossas missões, responsabilidades e clientes. Porque sabíamos que as equipas com as quais trabalhamos iriam comparar-nos com hiperescaladores ou com editores no modo SaaS. Portanto, tivemos que oferecer uma simplicidade de interface e provisionamento comparável à desses players. Isso exigiu que trabalhássemos na nossa cultura interna, mas também nas nossas ferramentas.

A segunda transformação que realizámos foi apoiar as equipas no seu consumo de cloud. Porque este último não conhecia esses ambientes, que muitas vezes chegavam ao nosso cenário pela IaaS. Criámos equipas para os ajudar a obter os componentes certos e possivelmente reembalá-los. As equipas de desenvolvimento, portanto, não vão diretamente para o portal do hyperscaler. Aconselhamo-los nas ferramentas certas, nas boas práticas em termos de monitorização, transição para produção ou segurança. Para isso, construímos duas ofertas de serviços com base na maturidade da equipa de aplicações. Ou já é muito orientado para o produto e pode trabalhar diretamente no PaaS de um hiperescalador, e então estabelecemos um diálogo entre especialistas e especialistas. Finalmente, IaaS e PaaS não nos desintermediaram. A nossa missão é garantir o desempenho dos serviços informáticos, independentemente do modo de alojamento, bem como os custos associados e a segurança adequada.

Por fim, lembre-se de que na Michelin as operações de TI já eram amplamente terceirizadas. Além das fábricas, não tínhamos mais os nossos próprios datacenters. Em vez disso, a cloud levou-nos a reinternalizar habilidades para acelerar a transformação e controlar custos. Primeiro em atribuições de arquitetura ou liderança de projeto, depois em operações e automação. A força de trabalho de infraestrutura está, portanto, a aumentar ligeiramente, mas estamos a trazer mais valor agregado para a empresa e a ajudar a realizar novas missões, principalmente em segurança. Sem esquecer que, em dados ou em cálculo, os volumes de atividade apresentam taxas de crescimento de até 30% ao ano, crescimentos que absorvem os ganhos de eficiência trazidos pela evolução das tecnologias.

Como gere o controle de custos da cloud?

A transformação que acabei de descrever leva-nos a expor o nosso catálogo de serviços, mas também os custos associados. Cada equipa de infraestrutura produz relatórios, exibindo estoques e custos de serviços. Isso permite-nos realizar um trabalho educativo com os nossos clientes internos. Por exemplo, o departamento responsável pela computação organiza uma reunião com cada equipa de aplicações para compartilhar níveis de consumo on-premise e na cloud, tendências observadas e alavancas de otimização. Fica claro que esse trabalho educativo ainda precisa de ser aprofundado junto das equipas de desenvolvimento. A maturidade cresce quando estes se organizam em modo de produto e manifestam o desejo de estabelecer um diálogo de valor com os seus próprios clientes, um diálogo sobre serviços, usos e custos. Este é o caminho que queremos seguir, mas a maturidade ainda não é a mesma em todos os lugares.

Além disso, esses esforços são apoiados pela governança estabelecida ao mais alto nível da empresa. A cada dois meses, é organizada uma reunião com o cogestor do grupo e os responsáveis ​​pelas áreas funcionais e discutimos não só o gasto de construção de novas aplicações, mas também os custos que esses projetos geram em infraestrutura e em execução. A minha responsabilidade é fornecer-lhes informações que lhes permitam conhecer os desafios que enfrentamos, o aumento de volumes e as alavancas de otimização que estamos a utilizar para compensar este crescimento. O que me deixa otimista é que a consciencialização está progredindo, por exemplo, do lado das equipas posicionadas em dados que estão a ver os seus volumes crescerem muito rapidamente. E a TI Verde desempenha um papel muito positivo. Porque o nível de emissões de carbono está diretamente relacionado com os gastos.

Como é abordada a questão do controle da dívida técnica?

Em primeiro lugar, a modalidade produto constitui um importante passo em frente nesta área, porque a questão do uso e valor é abordada tanto pelas equipas de aplicação como pelas das infraestruturas. Depois, nos comités de governança, certamente falamos de orçamentos de projeto e execução, mas também de património. Com indicadores de como o número de aplicações em cada domínio de negócio, idade média e taxa de obsolescência. Esses dados vêm do nosso CMDB, que contém uma descrição detalhada dos componentes. A nossa alavanca é mostrar essas taxas de obsolescência, calculadas pelos nossos arquitetos, para estabelecer um diálogo sobre esse assunto. Esta taxa, que pode ir até 40 ou 50%, dependendo da definição escolhida (qualquer componente não suportado por exemplo), não é um critério propriamente dito. Antes de tudo, é necessário determinar se essa obsolescência é grave ou não para poder priorizar os sites e propor um roteiro razoável. Por exemplo, uma aplicação exposta na Internet na DMZ não pode apresentar uma obsolescência grave, por questões de segurança.

Na maioria dos fabricantes, os cientistas da computação já entraram em fábricas e oficinas. Qual é a estratégia da Michelin nesta área e o papel das equipas de infraestrutura?

Tudo nasceu, sobretudo, da vontade dos vários departamentos de trabalharem em conjunto, a todos os níveis. Assim, recebemos pedidos de engenheiros de automação que desejavam conectar as suas máquinas. Mas a alavanca real, que se materializou há cerca de dez anos, veio novamente pela segurança cibernética. Com os ataques do tipo Stuxnet, percebemos coletivamente que os sistemas de produção, conectados às TI, eram vulneráveis. Essa observação levou cientistas da computação e engenheiros de controle a dar um passo em direção ao outro. Para os primeiros, tratava-se antes de tudo de compreender os métodos de trabalho nas fábricas. Eles funcionam 24 horas por dia, 7 dias por semana e um problema no computador é suficiente para paralisar toda uma cadeia. Tínhamos, por isso, de mostrar humildade, perceber estes constrangimentos, identificar as mais-valias que poderíamos trazer, mas também as áreas em que deveria prevalecer a autonomia nas fábricas, por questões de capacidade de resposta.

Com base nessas bases, definimos um programa inicial de convergência de TI da fábrica, executado de 2019 a 2022. Esse programa concentrou-se nas camadas inferiores da infraestrutura, enquanto a gestão da fábrica se concentrou nas suas questões-chave, como capital humano ou produtividade. Este primeiro ciclo colocou as camadas inferiores da infraestrutura sob a responsabilidade da TI, por se tratar de uma profissão de expertise. Neste campo, as fábricas posicionam-se agora numa lógica de expressão de necessidades e consumo de serviços. Convergimos assim as redes e catálogos de serviços oferecidos aos utilizadores. Este ainda não é o caso do lado do servidor.

A segunda inovação trazida por este programa prendeu-se com a racionalização dos parques aplicacionais, com uma racionalização dos portefólios separando o tempo real, relativo ao autómato, de tudo o resto – dados, reporting, performance e qualidade -, relacionando antes uma chamada central computador. Ao mesmo tempo, as empresas embarcaram em experiências com dados e IA para estruturar necessidades em termos de dados, casos de uso relevantes e habilidades.

Este ciclo acaba de terminar. Quais são as ambições agora?

Estamos em processo de redação de um segundo ciclo, que pretende partir dessas conquistas para ir além. Agora que os dois engenheiros centrais aprenderam a trabalhar juntos, vamos concentrar-nos nos problemas das fábricas e nas maneiras de os resolver. Isso requer, em particular, uma racionalização dos data lakes e da IA ​​já presentes em instalações industriais. O objetivo agora com essas tecnologias é escalar. Hoje, cada fábrica trabalha com os seus dados. A nossa ambição é compartilhar dados e casos de aplicação entre fábricas, sempre que isso fizer sentido. O valor virá da transversalidade e homogeneização, o que também mostra o quanto a prévia racionalização da infraestrutura foi uma importante alavanca.

Em vez disso, a consolidação ocorrerá na cloud?

Sim, mas com limites no desempenho esperado das aplicações e na confidencialidade de determinados dados. A reflexão sobre a arquitetura técnica deve ser acompanhada de uma análise funcional. Em termos de arquitetura de TI, é necessário identificar soluções que permitam, de forma transparente, estar localmente – quando necessário – ou na cloud, quando relevante. Tudo sem que o roteiro de dados se torne muito complexo.

Estamos, portanto, a implantar um modelo de computação homogéneo nas fábricas, introduzindo capacidades de cloud. Se as fábricas há muito procuram abstrair-se da cloud para se manterem autónomas no seu funcionamento, hoje consomem de facto ambientes deste tipo, sem necessariamente o medirem bem. Por exemplo, parte do rastreio de atividades agora está na cloud. E essa tendência só aumentará com dados e IA. O nosso objetivo é endossar este estado de coisas para garantir o nível certo de desempenho e segurança, com o nível de suporte adequado. Porque é preciso ter em mente que as fábricas não têm todas as habilidades necessárias para suportar essa mudança. A minha responsabilidade nesse sentido é mascarar as complexidades trazidas por tecnologias cada vez mais presentes na produção.

Como a Michelin está organizada para usar os dados?

Combinamos dados e IA na mesma organização. A isto junta-se uma rede dentro das profissões, com gabinetes de dados para o setor terciário, comércio, I&D, manufatura, sem esquecer a própria TI. E cada profissão ou grupo de profissões tem a sua governança para legislar sobre seus dados, aliada às ferramentas necessárias. Este sistema está agora a caminho de ser implantado.

Tanto com a cloud quanto com a fusão TI/OT, estamos a testemunhar uma extensão da abrangência das TI. Quais são as consequências para a monitorização?

Para suportar essas transformações, passamos da monitorização técnico, focada na disponibilidade dos recursos da unidade, para a observabilidade, uma abordagem que parte dos processos e aplicações críticos para o negócio e visa monitorizar o seu nível de desempenho. Assim, já não se trata apenas de verificar se tal aplicação ou tal processo responde aos pedidos, mas sim que o faz nas condições esperadas pelo negócio em causa. Obviamente, essa forma de monitorização requer conexão com os elementos técnicos que entregam o desempenho esperado para construir painéis de observabilidade. Mas estes não são dedicados aos responsáveis ​​da área técnica, mas sim partilhados entre equipas técnicas, de suporte e até de negócio. Há quase dois anos que seguimos essa abordagem, embora ainda não esteja generalizada em todos os lugares. Estamos a tentar ter um demonstrador por área de negócio para que essa mudança de postura seja depois implantada por capilaridade.