 Boa tarde, pessoal. Nós temos o privilégio de ser o último a apresentar. Mas vamos tentar ser breve. Eu queria começar falando do desafio que nós tivemos nesse projeto. A Serasa nos chamou, já há algum tempo, e o grande desafio foi, como no ambiente extremamente complexo, vocês vão ver com um parque tecnológico, mais de 250 aplicações, diferentes produtos de negócios, diferentes canais de atendimento, como a gente conseguia fazer um projeto ágil. Fazer, efetivamente, o drill down desde a arquitetura corporativa até um roadmap de transformação de uma forma ágil. Então, só para não me delongar muito aqui, a gente vai passar a apresentação. Mas o grande desafio inicial que nós fizemos foi o seguinte, antes de a gente iniciar o projeto, a gente fez um trabalho, um workshop, envolvendo o time de negócio, envolvendo o time de tecnologia, a gente tinha, praticamente, uma pergunta a responder. Qual era o problema de negócio que nós, baseado nas diferentes hipóteses, nas análises que a gente ia fazer, a gente ia conseguir responder isso para a organização. Então, o grande tema aqui que eu trago, uma reflexão, é a arquitetura corporativa, ela vem para resolver problemas de negócio. Então, como a gente consegue resolver esses problemas, a forma que a gente consegue resolver esses problemas, é aonde nós aplicamos os diferentes métodos e o Togaf vem para isso, para, efetivamente, você fazer uma arquitetura orientada a resultados. Que é um pouquinho do que a gente vai mostrar aqui. Eu vou apresentar aqui a Cris, eu acho que ela vai apresentar, ela vai tocar essa apresentação, ela vai contar um pouquinho da história da Serasa e um pouquinho da história do que foi esse projeto. Boa tarde, pessoal. Meu nome é Cristiane Sato. Eu trabalho no time de arquitetura editei da Serasa. Eu vou falar um pouquinho, contextualizar vocês da Serasa, o que ela tem até um videozinho para dar uma animadinha. Apesar de que o Antônio já anima bastante. Eu falo um pouquinho do projeto. Ele tem o nome de Avalon, por isso que é o projeto Avalon. A abordagem desse projeto, então, aí o Felipe vai me ajudar bastante, porque é bem a metodologia que eles utilizaram e os resultados. Então, para começar, acho que é um videozinho aqui. Cada decisão que você toma tem a ver com o futuro e a Serasa Experience trabalha todos os dias pensando em como contribuir para que o seu seja de crescimento e sucesso. A Serasa Experience está ao seu lado para transformar dados em informação e informação em oportunidades para você ou para seus negócios. Oportunidade para você vender mais e melhor. Oportunidade para você encontrar o cliente certo, no lugar certo. Oportunidade para você conceder crédito com mais segurança e administrar sua carteira de clientes com mais eficiência e rentabilidade. Oportunidade de investir com menos riscos, de encontrar bons fornecedores, de controlar melhor suas despesas. A Serasa Experience desvendo o poder dos dados e o coloca nas suas mãos, ajudando você e o consumidor a ter uma vida financeira cada vez mais protegida e saudável e a sua empresa a ficar cada vez mais sólida e competitiva. A Serasa Experience oferece ainda informação e tecnologia de ponta de uma maneira prática e eficiente. Mais do que isso, a Serasa Experience amplia oportunidades para que negócios e projetos pessoais prosperam. Acesse serasaexperium.com.br e saiba mais. Bom, esse daí é o vídeozinho que eu quis trazer também para mostrar um pouquinho para vocês que a Serasa não faz só negativação das pessoas. Porque a gente tem esse estigma, a gente está querendo mudar, faz um tempinho, então a gente usa várias informações que a gente coleta, tanto do mercado, de todos os lugares, também para o bem do consumidor, para o bem dos nossos clientes. E aqui é um pouquinho da Serasa em números, a gente é grande, temos seis milhões de consultas diárias, mais de 38 milhões de CNPJ cadastrais da nossa base. A gente tem 500 mil clientes e 17 mil colaboradores no mundo todo. Então para vocês terem uma dimensão do que foi esse projeto em que a gente olhou toda essa gama de negócios e de tecnologias que a gente tem lá dentro. Então aqui para contextualizar na parte do nosso desafio, hoje o que a gente tem lá no negócio? A gente está trabalhando com novos segmentos de mercado, que a gente está tendo mais consumidores, pequenas empresas, médias pequenas empresas, novos segmentos de mercado, a gente precisa de novos produtos por causa disso. A gente tem áreas de negócio trabalhando mais com foco em clientes, então eles estão criando produtos pensando, focando no cliente. Com tudo isso acontecendo, a gente precisa ter um time-to-market melhor, a concorrência também está crescendo, a gente tem uma necessidade muito forte de modernização tecnológica, vocês vão ver no próximo slide, para atingir esse time-to-market e a gente quer reduzir o custo do mainframe, que é um corda à nossa empresa. Então aqui um pouquinho da visão geral da tecnologia, ali são várias unidades de negócios que a gente tem, porque a gente tem vários produtos de vários segmentos, são várias unidades de negócios, aqui a gente fala um pouquinho dos desafios que tem cada pontinho, essa caixona, essas caixinhas em vermelho, são dependências que a gente tem como mainframe, então a gente tem em todas as unidades de negócio, a gente tem componentes compartilhados, são usados por todos no mainframe, então isso traz uma complexidade muito grande e um custo muito alto. E aí, Cris, só para tangibilizar um pouquinho, assim que a gente entrou a gente se deparou, é efetivamente com uma TI central, onde basicamente é o grande birô de informações e eu tinha um poder de decisão altamente descentralizado nas unidades de negócio, onde as unidades estavam lançando diferentes produtos, ou a sua própria TI dentro das unidades, numa forma descentralizada, ou utilizando parceiros externos, e muitas das vezes esses produtos, quando você olhava o custo de produzir, o custo daquele produto, ele não vinha o custo que você tinha de beber da fonte do mainframe. Só para vocês terem uma ideia, nós fizemos um gráfico onde nós pegamos a receita da serasa projetada ao longo da visão executiva, não só organicamente, como inorganicamente, e fizemos uma comparação do custo de crescimento de MIPS e MSU mainframe. Era uma coisa absurda. Ou seja, apesar de hoje a serasa ainda ter um time to market, eu poder lançar produtos, uma alta dependência de uma tecnologia legada, onde é difícil você ter a agilidade que os clientes precisam, você ainda tinha um crescente crescimento de custos. Então acho que isso foi um grande motivador e o que representa nessa figura, que é, apesar de eu estar lançando novos apps, estou atendendo novos canais, estou atendendo novos públicos, eu continuo bebendo no meu grande bureau de informação. Isso aí. Então esse é um grande desafio para a gente, como que a gente, nessa curva de crescimento de MIPS, conseguia atender novos clientes, o processamento ia aumentar. Se você olha aqui nesse desenho, tem bastante coisa que fala muito de crescimento de dados. Então a gente tem um crescimento muito grande, um processamento muito grande, por consequência, o custo maior ainda. Então nesse cenário, a gente chamou o APWC com dois objetivos principais. O primeiro era construir uma arquitetura de referência para nos ajudar a evoluir essa tecnologia, mas que ela estivesse alinhada com os nossos diretrizes globais, porque a gente tem uma diretriz tecnológica forte globalmente, então a gente tinha que alinhar isso, mas também como um negócio para atender o negócio. E o segundo objetivo era criar um roadmap dessa transformação, criar esse roadmap para ajudar a gente a criar o BC e tudo mais. Nisso foi criado o projeto Avalon. Então o projeto Avalon em números é isso aqui. A gente tiveram mais de 20 entrevistas com executivos de negócios para entender a percepção do negócio em relação a TI, o que que a TI deixa de atender, o que eles precisam, quais são os objetivos no curto médio e longo prazo. Tiveram mais de 21 pessoas engajadas nesse projeto, porque teve todo um apiamento que foi feito do que a gente tem e o que precisamos. Foram 208 sistemas mapeados. Acho que vale a pena que falar que nesse projeto a gente não olhou todos os sistemas que existem na empresa. A gente olhou seis produtos, não, são dois produtos e mais quatro sistemas transversais. São sistemas que são utilizados por diversos produtos. Então, por exemplo, faturamentos, esse tipo de coisa. Então esses projetos SIS-SEMs representavam 90% dos estilos arquiteturais da empresa. Então a gente focou nesse SIS-SEMs para poder extrapolar para todos os demais. Então desses SIS-SEMs saíram esses 208 sistemas mapeados, são famílias de sistemas. E 453 componentes tecnológicos que foram mapeados, certo? De funcionalidades, interfaces, componentes. Esse daqui é o processo que foi feito nesse projeto. Então ele foi dividido em três grandes fases. A primeira grande fase foi o de descobrir onde foi mapeado todo o SIS-SEM, que é um depar aqui dos entregáveis com o ADM. Tem as letrinhas aqui dos entregáveis. Teve essa grande fase de descobrir onde foram feitos esses passos, grandes passos aqui, que eram mapeados e tecnológicos da empresa. Descobri quais eram os grandes drivers de negócio. Na parte de desenhar, a gente pegou todos esse entendimento do que foi mapeado ali. Desenhou a arquitetura do SIS, desenhou todas as capabilities, os capabilities map, alguns princípios de arquitetura foram descritos. Então aqui foi a parte de desenhar toda essa arquitetura. E a arquitetura de referência também foi desenhada aqui nesse modelo. É legal discutar aqui que eles tiveram que fazer... Esse projeto aqui em notem possivel se for olhar, são três meses. Esses duas primeiras grandes fases foram feitas com duas squads no modelo ágil. Duas squads, duas semanas para cada sprint. Então foram duas sprintes para cada grande fase. Eu considero isso super rápido. No planejamento foi só uma squad, mas é aqui que a gente fez, dado todo o mapeamento de como a gente queria ser, quais eram a lista de iniciativas que a gente teria, toda a priorização que foi feita aqui. E efetivamente o roadmap e o estudo financeiro de tudo isso. Eu acho que só para corroborar um pouquinho aqui, Chris, eu acho que o grande desafio é o seguinte, é como a gente faz um projeto em 12 semanas em um ambiente extremamente complexo como é o ambiente da serasa, onde você tem diferentes aplicações, diferentes estilos, diferentes produtos, para você ter uma ideia hoje, se eu não me engano, deve ter mais de 50 produtos disparados nas diferentes unidades. Então acho que a chave do sucesso aqui primeiro foi qual o problema de negócio que eu quero resolver. Então o problema de negócio estava muito claro para a gente, era o time to market e uma grande dependência de um birô de informação de uma aplicação legada. O segundo, vamos olhar um pouquinho para o negócio e vamos olhar dentro das capacidades que eu tenho do negócio, quais daquelas capacidades eram altamente custosas ou eu não tinha agilidade suficiente para poder entregar o valor que os clientes esperavam. Então diante dessa primeira priorização, a gente conseguiu fazer o projeto. E aí qual foi a saída? A saída foi o seguinte, legal, eu tenho um parque tecnológico de mais 250 aplicações. Mas olhando essas prioridades, olhando esses problemas que eu quero resolver e mapeando quais são os grandes produtos e as grandes capacidades de negócio que estão efetivamente sendo impactadas por aqueles problemas, quais são os estilos arquiteturais que existem hoje dentro da organização que a gente pode extrapolar? Ou seja, nada mais é do que um grande pareto. O que é o meu 80 a 20? Onde é que estão meus maiores custos? Então nós listamos quais são os principais ofensores de custo dos produtos, onde é que está o meu maior ganho de receita com aqueles produtos e em cima desses produtos com outros critérios de priorização, como volumetria, quantidade de transação, processamento de transação por dia, impacto no cliente final, foi o que a gente conseguiu realmente montar esse roadmap e sair do outro lado em 12 semanas de trabalho. Acho que isso foi o grande X da questão. Um das primeiras coisas que a gente fez foi levantar esses direcionadores do negócio. Teve vários, esses foram os três que guiaram e permearam todo o projeto. Então eles foram coletados naquelas entrevistas com os executivos e os três são crescimento do negócio através de novos produtos e novos mercados, ou seja, a gente está no momento em que a gente vai crescer muito mesmo, é só para corroborar a situação que a gente viu na arquitetura, é isso mesmo. Foco na experiência do cliente, então a ideia é que a gente ter maior inovação, uma transformação digital e a segmentação dessa nova segmento de mercado que a gente quer atingir. E o aumento da produtividade e da eficiência, ou seja, a gente precisava melhorar os nossos processos, automatizar processos. A gente estava trabalhando com o modelo Cascata no início desse projeto, então era tudo muito lento, os projetos eram muito grandes, então tinha todos esses problemas. Os principais artefatos desse projeto foram esses aqui, que eu achei que valia a pena destacar, tem dois aqui que... Eu acho que vale a pena explicar um pouquinho esses daqui que vocês já conhecem. Essa matriz de priorização foi muito legal porque pegaram todas as iniciativas, baseado em alguns questionários, saiu essa matriz de priorização aqui em que a gente pegou, tem algumas técnicas aqui, que é o Secret Source da PWC. Mas ficou muito legal porque a gente fez entrevistas com a TI, foram perguntas que foram feitas direcionadas para nós, e baseado nisso saiu essa matriz de priorização. E foi muito rápido, o confecção disso aqui. Outra coisa que eu acho legal de falar são essas ondas, que foi decidido separar em três ondas aqui toda essa transformação. Essa primeira onda que separaram todas as iniciativas que tinham o cunho de fundação, ou seja, da Fundação Tecnológica de Pessoas, treinamento, escapacitação, contratações, aumento... Toda a parte estrutural ficou separada nessa onda, então a gente sabe mais ou menos o tempo. A segunda onda é a transformacional, onde, baseado em uma nova plataforma, a gente já tem a capacidade de trazer novos produtos para essa plataforma, então a gente já estaria começando desenvolvendo produtos na nova plataforma. E a onda de nova era, onde a gente fala que é aonde a gente vai ter todos os nossos sistemas transformados. Tem outro... Outro item que foi fundamental, que foi entregue também nesse projeto, são fatores críticos de sucesso. São itens que a gente vai ter que tomar muito cuidado no decorrer desse projeto. Esse projeto é bem grande. Esse projeto, o Avalon, acabou. Foi até recente, foi no começo de setembro que acabou. E esses itens são itens que a gente vai ter que tomar cuidado, que vai tomar cuidado por todo essa transformação, que vai ter um outro nome de projeto, porque a gente na Serasa gosta de dar nomes diferentes para os projetos. Então, esse novo projeto vai... A gente vai ter que tomar bastante cuidado com a parte de capacitação, todos esses investimentos, a governança de dados que podem mudar e tal. Esse item aqui, a cultura ágil, comprometemente de toda a companhia, isso é muito importante, mas é uma coisa muito legal, porque como esse projeto não foi feito TI por TI, foi um projeto que a gente trouxe o engajamento de todas as áreas de negócio, eles se empolgaram muito com esse projeto, então eles se engajaram, ajudaram, a gente teve prioridade nessas entrevistas, foi muito legal. Mas é uma coisa que a gente tem que ter esse comprometimento durante todo o projeto, não só em toda a transformação, não só durante esse levantamento. Com tratação e aquisição, a gente vai tomar bastante cuidado na parte também para a gente não ter equipe TI de Beus, fazendo uma pequena mudança e indo para outro caminho, a gente tem que tomar conta disso tudo. Isso é etapa e mobilização. Isso aqui é muito importante, porque aquelas datas das ondas, aqueles prazos, são pensados em ter uma mobilização, a gente precisa fazer o set up rápido para ter uma mobilização também que ajude a gente a fazer isso rápido. E acho que só para corroborar, Cris, acho que tem um tema que é interessante, um pouco da mudança do modelo de consumo da informação pelo negócio. O que é interessante? O negócio, hoje, as diferentes biulas, consumiam a informação direto do Birô, mas ela consumiu informações em formatos de relatório. Acho que qual foi a sacada que a gente não trouxe, mas na arquitetura de transição, foi o seguinte, ao invés de eu consumir a informação do relatório A, que me entrega uma negativação, do relatório B, que me entrega uma positivação, e assim sensivamente, eu mudo o conceito, eu passo a fornecer para o negócio o objeto pessoa, para que as diferentes unidades de negócio possam consumir aquela informação. Então, se eu quiser implementar modelos federados, onde eu continuo tendo uma descentralização do desenvolvimento de aplicações, eu consigo prover para as unidades de negócio, a gente consegue prover o conceito efetivamente do objeto. Então, independente do que eu esteja consultando, independente da plataforma que eu vou estar usando, elas vão consumir o modelo de informação que isso vai passar por uma esteira, ou seja, o que eu acho legal disso é a mudança de conceito na organização. Então, a partir desse momento, as unidades de negócio, elas começam a se preocupar no seguinte, não mais em que a aplicação que eu vou construir, eu vou construir para gerar o relatório e tal, não. Eu vou construir em uma aplicação para entender que eu consumir informações daquela pessoa, ou daquele CPU. Acho que isso foi a grande mudança de modelo e a grande mudança é a transformação que isso vai trazer para o consumo das informações para as diferentes unidades. Isso. E para fechar aqui o último slide, o resultado tem a ser horizonte aqui, mais ou menos de quatro anos, que é aquele, as três ondas para se terminar, porém ali a gente está falando somente daquelas seis sistemas que foram mapeados. O UBC é de dez anos, extrapolando aquela estimativa para todos os outros sistemas. Isso aqui é muito interessante, é o Payback, que é assim, só da gente fazer essa transformação e essa modernização, tirando o custo de mainframe, a gente já tem esse projeto se pagando por ele mesmo em oito anos. Então, em oito anos, ele termina de pagar ele mesmo só por conta do custo. Então, a gente nem está falando, nem colocamos na conta que novos produtos que a gente vai ter e ganhar dinheiro por conta desse projeto. Então, isso é muito interessante. Acho que foi um tema interessante, como eu falei, e às vezes no final, acho que em qualquer projeto de arquitetura, você está resolvendo um problema de negócio, mas você tem que quantificar aquele problema. Eu acho que o grande diferencial aqui é como a gente consegue quantificar esse problema. E aqui, entrando um pouquinho mais no como, o que a gente fez? A gente pegou regras de rateio da organização, listamos os principais produtos e listamos a receita dos produtos. Quando a gente levou isso para o comitê executivo, a gente começou a traçar alguns panoramas de cenários, falar que eu tenho uma série de produtos que hoje me custam mais do que ele me gera de receita. Como é que a gente coloca isso na linha do tempo? Qual custo que eu estou tendo para efetivamente manter, não só manter e evoluir esses produtos, vis-a-vis o que eu estou trazendo de receita para companhia. Então, a gente montou um business case muito com a ajuda do time financeiro, do próprio time de TI. E aí o que agrada a surpresa é o seguinte, o valor dessa transformação, como a Cris comentou, ela se paga pela TI. Só a redução de MIPAGEM, de MSU, mais algumas reduções de licenciamento, algumas otimizações de estrutura, o projeto se pagou. Nós nem estrapolamos essa análise financeira para uma análise de negócio, ou seja, dentro do time to market, deu a lançar um novo produto, o quanto se ia me trazer de maior rentabilidade ou de maior retorno. Então, eu acho que isso foi a grata à surpresa que a gente chegou num denominador comum que a TI própria, a redução do custo da TI, com algumas otimizações, ela paga um projeto de transformação como vocês estão vendo aí para dez anos. Eu acho que isso é um grande diferencial. Sim, ajudar muito a aprovar o projeto também. E algumas resultas imediatas, porque eu acho que vale a pena mostrar esse projeto ainda não iniciou lá, efetivamente, o projeto de transformação, mas algumas resultas imediatas foram que, mesmo esse projeto sendo tão rápido, nesse meio tempo, quando já tínhamos arquitetura de referência, na verdade, a gente começou a trabalhar já nos projetos estruturados e estratégicos na arquitetura nova. Então, a gente já entrou no detalhe da arquitetura de referência, já começou a trabalhar nela. Então, a gente já tem três ou quatro projetos estratégicos na arquitetura nova. Então, independente do projeto ser aprovado ou não, a gente já está indo para essa arquitetura. Isso foi uma coisa que me chamou muita atenção, olhando realmente o que a Serasa tem feito em relação à transformação ágil, à cultura, principalmente, partindo de TI com o negócio. Foi muito legal que a gente ia montando o modelo e, ao mesmo tempo, tinha um projeto, vamos agora tratar o projeto positivo, mas tá bom, mas já começavam as squads desenhais, já começavam a fazer MVPs em cima do modelo que a gente estava discutindo. Então, a gente sentava com eles. Alguns já tiveram um start anterior, mas outros, em tempo de projeto, a gente até participou de algumas inception, o pessoal já desenhando o modelo, já começando a criar MVPs enquanto o nosso projeto estava em vôo. Então, isso me chamou muita atenção, a agilidade que a empresa está dando e não realmente eu espero um trabalho todo de arquitetura corporativa, a pró forçamento, tem uma rodada de aprovação, de priorização, para depois eu começo para daqui a três anos, não. Já tem três ou quatro squads que já estão fazendo MVPs, então, usando um pouco do modelo de referência que o Avalon deixou e já estão começando a pivotar. Então, isso me chamou muita atenção como a serasa está embuída dessa cultura ágil e como isso realmente está acontecendo na prática. A gente acaba não vendo muito isso no mercado. A gente foi bem no meio do projeto que a gente virou para ágil o nosso TI. A gente está em transformação ainda, mas o legal do mindset ali não é que a gente quer virar ágil, a gente quer aprender a se transformar o tempo todo, aprender a como mudar o tempo todo. Porque a gente, a serasa mesmo, vende dos últimos, sei lá, dez anos para cá, não para de mudar. Então, a gente está mudando muito. Tem muitos novos mercados chegando. Então, por isso que a gente chegou a ver onde a gente está. E esse mindset a gente está trazendo também para a arquitetura, para o time de arquitetura. A gente tem arquitetura ainda a parte corporativa. A gente está explorando cada vez mais, mas a gente quer trazer a parte essa agilidade para a arquitetura também. Estamos trabalhando com toda a mesma companhia, uma mudança de mindset de toda a companhia. Toda a companhia não é uma mudança somente da TI para trazer o ágil e a gente ficar preparado para mudanças. E não é só trabalhar com ágil, é estar preparado para mudar. Então, a gente já tem esse mindset que é um pouco diferente. Então, a gente tem muito trabalho pela frente. São dez anos ainda, dependendo da priorização, espero que seja dez mesmo. E é isso que eu queria mostrar para vocês, gente. Obrigada.