01-28 Reunião: Próximos passos Colliers, Criação de Construtora Digital e Data Lake

Itens de Ação

  • @[Equipa] - Sentar com um arquiteto de dados e um engenheiro de dados para fazer um projeto de um Data Lake - [Sem data definida].
  • @Igor - Atualizar o Lucas sobre a continuação da conversa e as respostas para suas duas perguntas pendentes para Pedro - [Sem data definida].
  • @Pedro - Alocar um arquiteto e um engenheiro de dados para criar o framework (blueprint) onde o Data Lake da construtora será construído - [Sem data definida].
  • @Pedro Villa - Organizar um memorando com base na conversa, clarificando terminologias e propondo um formato de trabalho para compartilhar com Igor Reginato, Bruno e Ricardo. - Sem data definida.
  • @Pedro Villa - Digerir as anotações e estruturar um documento de trabalho (draft de 1-2 páginas) com um plano de trabalho para confirmar o entendimento. - Sem data definida.
  • @Igor Reginato - Aguardar o documento de Pedro Villa para, em seguida, marcar o próximo bate-papo envolvendo os demais stakeholders (Bruno e Ricardo). - Sem data definida.

Decisões Chave

  • As melhorias de processo devem ser orientadas por dados (data-driven) para que os resultados possam ser mensurados de forma concreta.
  • A nova construtora implementará o ERP Sienge a partir de fevereiro/março.
  • Foi confirmado que a empresa não possui atualmente um Data Lake implementado. Igor Reginato mencionou que a área de inteligência de mercado está a começar a considerar o uso de uma ferramenta da Microsoft (possivelmente Azure) para este fim.
  • A abordagem deve focar-se em agregar dados de diversas fontes e formatos, abandonando a mentalidade orientada para a ferramenta e focando-se na solução de dados. A primeira informação a “guardar” é a necessidade de um Data Lake.
  • A construtora será o projeto piloto para estabelecer um novo modelo operacional baseado em tecnologia, para depois replicar esse modelo nas outras áreas de negócio (gerenciadora, diligências, transação, etc.).
  • Utilizar ferramentas SaaS temporariamente para garantir a ingestão de dados no formato correto no Data Lake, com a intenção de substituí-las por soluções proprietárias em 3 ou 4 meses. - Esta estratégia permite que o trabalho comece imediatamente sem esperar a conclusão da plataforma definitiva.
  • A solução será tecnicamente definida como uma “plataforma de dados”.

Minuta Detalhada

[01:06-01:45] O objetivo da reunião é discutir os próximos passos da Colliers e potenciais colaborações.

  • O Igor Reginato, Igor, iniciou a reunião mencionando uma conversa prévia com Serapiano, que recomendou o contato com Pedro para discutir o futuro da Colliers.
  • Foi solicitado que Pedro Villa fizesse uma introdução sobre sua experiência para facilitar a comunicação e o alinhamento. [01:45-04:02] Apresentação de Pedro Villa, destacando sua experiência em transformação digital baseada em dados.
  • Pedro Villa tem uma longa carreira como executivo, principalmente como CFO e CIO em empresas de varejo (e.g., DePascoal) e fundos de investimento (e.g., Abre).
  • Nos últimos cinco anos, após sair do mercado corporativo em 2019, ele tem se dedicado a projetos de transformação digital, com foco principal nos setores de varejo e saúde.
  • Sua metodologia de trabalho consiste em entender problemas complexos das empresas e desenvolver soluções em camadas, abordando frentes como:
    • Engajamento de clientes.
    • Melhoria de produtividade de equipes internas (vendas, back office).
    • Automação de processos com Inteligência Artificial (IA).
    • Inteligência de mercado.
  • A base de todas as soluções é a engenharia de dados, utilizando machine learning e IA para gerar insights e retroalimentar os processos de melhoria de negócio de forma contínua. [04:12-06:53] Apresentação de Lucas, Diretor-Geral da Colliers Latinoamérica, sobre o modelo de negócio de Serviços de Projetos Estratégicos (SPS).
  • Lucas se apresentou como Diretor-Geral da Colliers Latinoamérica, trabalhando diretamente com a equipe de Igor na área de SPS (Strategic Project Service).
  • Os projetos da SPS são definidos como serviços com início, meio e fim, e não como serviços contínuos.
  • O caráter “estratégico” vem do fato de que as soluções são desenhadas sob medida para as necessidades imobiliárias específicas de cada cliente, seguindo lógicas de gestão de projetos como PMP e PMI.
  • Lucas expressou grande interesse na conversa para entender como a tecnologia e novas abordagens moldarão o setor nos próximos anos. [06:55-08:38] Igor detalha o objetivo estratégico de criar uma construtora como uma spin-off digitalizada e apresenta uma lista de desejos para automação.
  • Igor esclareceu sua posição cuidando do Brasil, enquanto Lucas supervisiona a América Latina.
  • A Colliers, com o apoio do advisor Serapiano, deseja acelerar a estruturação de seus serviços de construção.
  • O plano principal é criar uma construtora como uma spin-off do serviço de gerenciamento de projetos, que já existe há mais de 10 anos, e que essa nova entidade nasça “absolutamente digitalizada”.
  • A conversa foi direcionada para a automação de processos, com Igor apresentando uma “wish list” (lista de desejos) para calibrar expectativas sobre o que é viável, sonho ou plano concreto. [08:39-10:31] Discussão sobre a abordagem orientada a dados (data-driven) para a otimização de processos, mesmo partindo do zero.
  • Pedro Villa explicou que sua abordagem para revisão de processos é 100% amparada em dados, citando um exemplo na Hapvida onde a produtividade de vendas foi quase dobrada (de 45 para 80 vendas/mês) após a análise de dados e implementação de mudanças processuais.
  • Key Decision: As melhorias de processo devem ser orientadas por dados (data-driven) para que os resultados possam ser mensurados de forma concreta.
  • Igor concordou com a abordagem, mas pontuou um desafio: a nova construtora partirá praticamente do zero, sem um histórico de dados. O processo envolverá a criação de novos processos, geração de dados a partir deles e, então, o refinamento contínuo com base nesses dados coletados. [10:31-13:01] Igor apresenta o “Primeiro Ato”: detalhamento do fluxo de trabalho comercial e as oportunidades de automação com IA.
  • Igor estruturou sua “wish list” em “atos”, começando pela etapa comercial, que vai desde a qualificação do lead até a entrega da proposta.
  • As principais atividades desta fase incluem:
    • Estudos de massa e viabilidade.
    • Análise de projetos técnicos e memoriais para estimar tempo e custo.
    • Análise de editais extensos para identificar pontos críticos.
    • Orçamentação e equalização de propostas de fornecedores (e.g., ar-condicionado, instalações elétricas).
    • Gestão de informações de fornecedores (ERPs).
    • Elaboração da proposta técnico-comercial, incluindo ilustrações e animações.
    • Análise de cenários de execução (e.g., entrega em fases vs. fase única).
  • Igor questionou se uma IA bem calibrada poderia ajudar a automatizar essas tarefas, que hoje são muito manuais.
  • Pedro perguntou se o pipeline atual já possui algum nível de automação, ao que Igor respondeu que não. [13:02-14:09] Discussão sobre o estado atual dos processos e a implementação do ERP Sienge.
  • Igor informou que a empresa está em fase final de contratação do ERP Sienge, que detém cerca de 70% do mercado de construtoras no Brasil.
  • Ele questionou sobre um possível conflito entre a IA e o ERP, mencionando ter ouvido que a IA poderia substituir os ERPs.
  • Key Decision: A nova construtora implementará o ERP Sienge a partir de fevereiro/março.
  • Atualmente, os processos são totalmente manuais, utilizando ferramentas da Microsoft (como o Teams) e “ser humano”, sem nenhuma automação. [14:09-19:46] Pedro propõe um modelo de IA semi-assistido, priorizando tarefas de alto impacto como análise de documentos e orçamentação.
  • Pedro sugere montar modelos de IA para cada etapa do pipeline, combinando know-how proprietário da Colliers com ferramentas de mercado.
  • A implementação seria gradual, começando com um modelo “semi-assistido”, onde a IA reduziria drasticamente o tempo da tarefa (de 8 horas para 30-60 minutos), mas com revisão final de um técnico.
  • Igor concorda, esperando que a IA atue como um “agente” sobre softwares existentes (e.g., Autodesk, Adobe).
  • Pedro Villa sugere priorizar tarefas de alto impacto e viáveis, como análise de projetos, editais, contratos (usando LLMs de mercado) e, principalmente, a orçamentação, que é apontada como a área “core”.
  • Pedro Villa reforça que a análise de RFPs (Request for Proposal) é outra aplicação ideal, e que um modelo misto (LLM convencional + proprietário) pode aumentar significativamente a acurácia. [19:47-21:24] A automação pode otimizar significativamente o monitoramento de licenciamentos e a gestão com concessionárias, tarefas atualmente manuais e demoradas.
  • Na fase pós-contrato, a análise e assinatura já utilizam ferramentas de mercado.
  • O monitoramento de licenciamento ambiental é um processo que consome muito tempo, pois exige o acompanhamento das regulamentações específicas de cada um dos 26 estados e mais de 5.000 municípios, que não possuem APIs centralizadas como a da Receita Federal.
  • O processo atual envolve ligar para consultores regionais para obter atualizações.
  • O Igor Reginato sugere que um ganho significativo poderia ser obtido com algum grau de automação, como o uso de formulários para centralizar as atualizações.
  • A gestão de concessionárias (ex: Enel, Sabesp, Vivo) envolve um serviço similar de follow-up manual para obtenção de licenças, representando outra área com potencial de otimização. [21:27-23:27] A automação do planejamento de projetos, especificamente a criação de cronogramas e a simulação de cenários de fluxo de caixa, é vista como uma oportunidade de alto potencial.
  • O planejamento consome um grande volume de horas de trabalho e tem um potencial significativo para automação, embora iniciativas existentes não tenham evoluído muito.
  • O fluxo de trabalho desejado é:
    1. Transformar um escopo de projeto em uma Estrutura Analítica de Projeto (EAP), detalhando todos os entregáveis.
    2. A partir da EAP e das quantidades, estimar as durações das atividades.
    3. Gerar um cronograma como output, preferencialmente em Microsoft Project, mas outros formatos seriam aceitáveis.
  • Ao atrelar o orçamento (preço) ao cronograma, seria possível gerar um fluxo de caixa e simular diferentes cenários de execução da obra (ex: começar da direita para a esquerda) para identificar a melhor abordagem.
  • Atualmente, essas simulações são feitas manualmente, um processo demorado e suscetível a erros.
  • As duas primeiras etapas (EAP e cronograma) são consideradas a “coluna vertebral” do planejamento. Uma vez resolvidas, outras tarefas como elaboração de planos de qualidade, comunicação, riscos e logística do canteiro de obras poderiam ser 70-80% automatizadas com ferramentas como o ChatGPT. [23:30-26:13] A captura da realidade com tecnologias como nuvem de pontos, drones e câmeras 360 pode automatizar o acompanhamento e validação do progresso de obras, aumentando a eficiência e a auditabilidade.
  • O conceito de “captura da realidade” é introduzido para monitorar e controlar projetos.
  • Tradicionalmente, a “nuvem de pontos” (escaneamento a laser) era usada para criar um projeto “as-built” (como construído) quando não havia uma planta precisa.
  • Uma nova aplicação é usar essa tecnologia para o acompanhamento de obras, automatizando a comparação entre o projetado (BIM 3D) e o executado (nuvem de pontos).
    • Tecnologias aplicáveis: Imagens de drone, scanners a laser e câmeras 360.
  • Pedro Villa confirma que já utiliza drones com automosaicos para acompanhamento de plantio e processamento de área.
  • A captura da realidade também pode ser aplicada em estudos topográficos para obter uma ordem de grandeza quase instantânea, gerando um diferencial competitivo.
  • Um benefício chave é a maior auditabilidade para clientes remotos, que teriam acesso a dados concretos (fotos, nuvem de pontos) em vez de apenas um percentual de avanço em um software. [26:14-29:29] A automação de processos de controle, como gestão de mudanças, apropriação de custos e consolidação de comunicações, pode gerar ganhos de eficiência exponenciais.
  • Validação e controle de escopo: A gestão de mudanças (ex: trocar uma porta por uma janela, calcular créditos) gera um trabalho descritivo e relatórios que podem ser automatizados.
  • Controle do cronograma: O acompanhamento do avanço físico é um processo caro, chegando a custar quase 2 milhões de reais com “apontadores” em uma obra.
  • Controle de custos: A apropriação de custos, recebimento de notas fiscais e controle de valores ainda dependem de muito trabalho humano.
    • Exemplo de automação “sonho”: Um bot de WhatsApp para envio de foto de nota fiscal que automatiza o lançamento de reembolsos.
  • Monitoramento de comunicações: A expectativa é que ferramentas como o Microsoft Copilot possam consolidar informações de e-mails, Teams e WhatsApp para gerar relatórios resumidos automaticamente. [30:00-30:57] A comunicação com os clientes em projetos de desenvolvimento é desafiadora devido à sua falta de conhecimento técnico e relutância em usar plataformas dedicadas.
  • A empresa trabalha para clientes como Coca-Cola e McKinsey, cujos interlocutores (CFO, chefe de operações) nem sempre possuem uma visão geral do projeto e se focam excessivamente nos aspetos técnicos.
  • Esses clientes não têm familiaridade com todos os processos envolvidos no projeto.
  • Tentativas anteriores de usar plataformas online para partilha de minutas e documentos falharam, pois os clientes não as utilizavam, não conseguiam aceder devido a problemas com links ou firewalls. [30:58-32:53] A comunicação via e-mail e PDF é considerada a forma mais segura de gerir o projeto, apesar de consumir mais tempo, mas a automação da criação de minutas de reunião (Meeting Minutes) é vista como uma grande oportunidade de otimização.
  • Pedro Villa aponta o WhatsApp como uma ferramenta de comunicação central no Brasil, mas o Lucas considera-o problemático (“uma morte”), pois pode levar a mudanças de escopo e aprovações informais.
  • A prática atual que mais protege a equipa é o envio de um PDF por e-mail para todas as partes interessadas (stakeholders), documentando formalmente acordos e avanços semanais.
  • Não formalizar a comunicação representa um risco de má gestão das expectativas.
  • Existe um desejo de automatizar e sintetizar comunicações e acordos, dado que o trabalho já é feito através de várias chamadas (conference calls, Teams).
  • Atualmente, o processo formal resume-se a atas de reuniões (Meeting Minutes) de chamadas de projeto semanais ou mensais, mas a frequência e a organização são inconsistentes. [32:56-34:37] A automação da geração de atas de reunião (Meeting Minutes) e resumos poderia economizar horas e aumentar significativamente a produtividade dos gestores de projeto.
  • Lucas sugere que a capacidade de codificar e automatizar a geração de atas no final de cada reunião economizaria horas de trabalho.
  • Igor Reginato concorda, projetando que essa economia de tempo poderia permitir que um gestor de projeto (Project Manager) gerisse dois projetos em vez de um, reduzindo o custo operacional para metade.
  • Lucas menciona que já estão a iniciar testes com o Copilot Pro, que gera resumos das reuniões (“loop”), embora o processo ainda seja complexo.
  • O cenário ideal seria ter um resumo de cada chamada de projeto, formatado segundo os padrões da empresa, que seria enviado automaticamente ao Project Manager para revisão e aprovação, e depois convertido num PDF para enviar ao cliente.
  • Lucas afirma que alcançar isto seria tão relevante que “vamos ir a dormir às sete da tarde”. [34:37-03:35] A maioria dos problemas em gestão de projetos deriva de falhas de comunicação e a automação de relatórios de visitas a obras representa outra grande oportunidade de economia de tempo.
  • Igor Reginato cita o Project Management Institute, afirmando que 80% dos problemas em projetos são causados por falhas de comunicação, e os gestores de projeto gastam muito tempo a gerir essa comunicação.
  • Lucas apresenta um segundo exemplo de otimização de tempo: o processo de visitas a obras.
  • O processo manual atual envolve:
    • Tirar fotos com o telemóvel e fazer anotações em plantas durante a visita.
    • Regressar ao escritório para descarregar a informação.
    • Inserir as fotos e notas num formato oficial de compliance.
    • Organizar e partilhar o documento com o cliente. [03:35-37:16] Um processo automatizado para relatórios de visitas a obras, utilizando georreferenciação e reconhecimento de voz/imagem, poderia economizar no mínimo duas horas diárias por pessoa.
  • A solução proposta envolveria uma aplicação que permitiria:
    • Mapear observações diretamente numa planta digital no local da visita.
    • Tirar fotos, vídeos e fazer scans de nuvens de pontos.
    • Usar comandos de voz para ditar notas (ex: “estou olhando a condicionada…”).
    • Tirar uma foto da etiqueta de um equipamento para que a IA extraia informações externas sobre ele.
  • Todo o relatório seria georreferenciado e estaria pronto assim que a equipa saísse do local da obra.
  • A combinação desta automação com lembretes automáticos economizaria, no mínimo, 2 horas por dia para cada pessoa da equipa. [37:18-38:50] Pedro Villa identifica os desafios apresentados como problemas de um pipeline complexo com ferramentas fragmentadas e propõe a implementação de um Data Lake como solução fundamental.
  • Pedro Villa reconhece que a empresa enfrenta múltiplos microprocessos com diversas ferramentas (e-mail, WhatsApp, ERP) e que as IAs de mercado atuais oferecem apenas um ganho de produtividade marginal (estimado entre 5% e 10%), sem resolver o problema de fundo.
  • Ele identifica os problemas descritos como dores antigas e tradicionais no setor de construção, com as quais ele próprio se familiarizou no início da sua carreira.
  • A principal questão de Pedro Villa para a equipa é se eles possuem um Data Lake com Machine Learning (usando tecnologias como Databricks ou Snowflake).
  • Key Decision: Foi confirmado que a empresa não possui atualmente um Data Lake implementado. Igor Reginato mencionou que a área de inteligência de mercado está a começar a considerar o uso de uma ferramenta da Microsoft (possivelmente Azure) para este fim. [39:10-40:14] A criação de um Data Lake é apresentada como a “fundação” essencial para interligar informações de diferentes etapas do projeto e viabilizar um pipeline inteligente.
  • Pedro Villa esclarece que um Data Lake é a base necessária para o projeto, comparando o seu planeamento ao projeto de uma fundação na construção civil.
  • O primeiro passo seria o trabalho de um arquiteto e um engenheiro de dados para projetar e construir o Data Lake.
  • O objetivo principal do Data Lake é garantir que a informação gerada numa fase (ex: comercial) possa ser consumida noutra fase (ex: monitorização), interligando todos os dados.
  • Pedro Villa enfatiza que sem um Data Lake e com as informações dispersas em bases de dados separadas, é impossível criar um pipeline inteligente de ponta a ponta. [40:14-41:03] A distinção entre um Data Lake e um simples repositório de dados como o SharePoint é clarificada, destacando a capacidade do Data Lake de processar dados não estruturados.
  • Igor Reginato questiona se o seu SharePoint poderia funcionar como um Data Lake, ao que Pedro Villa responde negativamente, explicando que o SharePoint é um banco de dados relacional.
  • Pedro Villa explica que um Data Lake é mais profundo e permite trabalhar com dados desestruturados (ex: conversas de WhatsApp) em conjunto com dados estruturados (ex: folhas de cálculo do Excel).
  • Esta capacidade permite, por exemplo, verificar se um item mencionado numa conversa de WhatsApp está dentro do escopo definido numa folha de cálculo e se requer um processo de gestão de mudanças (change management).
  • Igor Reginato reconhece a clareza da explicação, admitindo que o seu pensamento estava limitado a dados estruturados. [41:04-43:10] A solução ideal deve ser agnóstica em relação às ferramentas de comunicação, focando-se na integração de dados de múltiplas fontes, em vez de forçar o uso de uma única plataforma.
  • Igor Reginato defende o uso atual de múltiplas ferramentas (WhatsApp, Teams, e-mail) como uma consequência da falta de uma solução ideal, mas mostra-se aberto a padronizar uma ferramenta se esta for a melhor.
  • Pedro Villa contrapõe, afirmando que a estrutura deve permitir o uso de qualquer ferramenta, pois a “vida real é cruel” e não se pode forçar clientes e fornecedores a adotar uma plataforma específica (ex: Slack).
  • Lucas corrobora, partilhando uma experiência em que um cliente exigiu o uso das suas próprias ferramentas (Zoom, WeChat, SharePoint), forçando a sua equipa a adaptar-se.
  • Key Decision: A abordagem deve focar-se em agregar dados de diversas fontes e formatos, abandonando a mentalidade orientada para a ferramenta e focando-se na solução de dados. A primeira informação a "guardar" é a necessidade de um Data Lake. [43:12-44:22] A implementação de um Data Lake inicia-se com uma fase de conceção de projeto, semelhante à engenharia civil, envolvendo arquitetos e engenheiros de dados.
  • Action Item: @[Equipa] - Sentar com um arquiteto de dados e um engenheiro de dados para fazer um projeto de um Data Lake - [Sem data definida].
  • Pedro Villa reitera que a metodologia para criar um Data Lake é a mesma de um projeto civil, utilizando terminologias como “arquiteto de dados” e “engenheiro de dados” para desenhar a “planta” da solução.
  • A principal vantagem de um Data Lake é a sua capacidade de consumir informações simultaneamente de várias fontes de dados, tanto estruturados como não estruturados. [44:22-45:57] Um Data Lake com Machine Learning permite que a IA aprenda com os dados históricos da empresa, aumentando a precisão das soluções e automatizando tarefas complexas.
  • O segundo ponto fundamental é que a estrutura de Data Lake com Machine Learning permite que o sistema “aprenda” com os dados existentes (ex: 100 tabelas de projetos orçados, contratos, etc.).
  • “Aprender” significa encontrar a resposta de IA mais adequada, incorporando todo o know-how acumulado da Colliers.
  • Isto eleva o uso da IA para além das soluções simples de mercado, conferindo-lhe um nível de propriedade e precisão muito maior para o negócio.
  • Exemplos de aplicação incluem:
    • Realizar revisões de custos mais precisas.
    • Identificar se uma comunicação no WhatsApp constitui um extra ao escopo do contrato.
    • Gerar alertas automáticos para que um humano revise pontos de atenção. [45:58-46:54] O design do Data Lake deve mapear todos os canais de informação, estruturada e não estruturada, para capturar o conhecimento histórico completo da empresa.
  • Lucas compreende que o Data Lake necessita de um design para mapear todos os “contentores” ou canais que fornecem informação.
  • Estes canais incluem:
    • Pastas no Teams ou SharePoint.
    • E-mails e comunicações de WhatsApp.
    • Gravações de chamadas (conference calls) do Zoom de clientes.
    • O histórico de 500 projetos, 50 mil minutas de reunião e as interações com 150 clientes. [47:01-49:38] A implementação de um Data Lake é um processo de duas fases: projeto/implementação rápida da infraestrutura e, em seguida, trabalho paralelo na ingestão de dados e desenvolvimento de processadores.
  • Pedro Villa descreve a construção de uma “fundação de dados” (Data Foundation) como a abordagem mais avançada do mercado para automação, sobre a qual todas as outras ferramentas (ERP, comunicação, etc.) são construídas.
  • A solução é flexível, permitindo que a empresa continue a usar ferramentas existentes, como o Microsoft Visio, pois conectores podem ser usados para analisar esses documentos e transformar o seu conteúdo em dados para o Lake.
  • Atas de reunião podem ser armazenadas num formato padronizado como Markdown (MD) dentro do Data Lake.
  • O processo de implementação consiste em:
    1. Projeto e Estrutura: Desenhar a “planta” ou “blueprint” do projeto de dados.
    2. Implementação da Infraestrutura: A implementação de ferramentas como Databricks e Snowflake é relativamente rápida.
    3. Operação em Duas Frentes:
      • Uma equipa foca-se na ingestão de dados históricos.
      • Outra equipa foca-se nos processadores de dados, que entregam os outputs necessários para cada processo (ex: um Excel, uma notificação). [49:40-51:37] O modelo Data Lake permite uma gestão de acessos granular e capacita as equipas a criar soluções de dados personalizadas, como a pré-elaboração de projetos com base em dados históricos.
  • Lucas questiona sobre a gestão de acessos, e Pedro Villa confirma que o modelo Data Lake é o “padrão ouro” do mercado para gestão e controlo de acesso aos dados.
  • Isto permitiria que dados sensíveis (custos de pessoal, performance) fossem usados para o planeamento do negócio, mas não ficassem acessíveis a um Project Manager, que por sua vez também não precisaria de acesso a todo o know-how do Data Lake.
  • Pedro Villa exemplifica que, um ano após a implementação, a equipa de engenharia poderia contratar um “programador de dados” que, com um simples código, poderia gerar um pré-projeto com base em critérios específicos (ex: 20 últimas experiências, região, segmento). [51:38-57:19] O Data Lake pode ser enriquecido com dados externos e de mercado para análises preditivas, e a conversa conclui com entusiasmo sobre o plano de ação.
  • Lucas sugere alimentar o Data Lake com informações de mercado (custos, características de imóveis) das áreas transacionais da empresa.
  • Pedro Villa confirma que quanto mais informação (interna ou externa), melhor, e ilustra com um caso de uma distribuidora de alimentos que usa dados externos (dólar, commodities) e não estruturados (fotos de cardápios) para otimizar operações.
  • Ele conclui que, com um modelo de Data Lake, “o céu é o limite”.
  • O Lucas encerra sua participação, expressando entusiasmo e a necessidade de um plano prático, sugerindo um piloto regional e pedindo para ser incluído no follow-up.
  • Action Item: @Igor - Atualizar o Lucas sobre a continuação da conversa e as respostas para suas duas perguntas pendentes para Pedro - [Sem data definida]. [57:25-58:55] Igor Reginato detalha o desafio de começar a construtora do zero, sem dados ou processos preexistentes, e questiona sobre o impacto humano da implantação tecnológica.
  • Afirma que a construtora é uma nova empresa (startup) e, portanto, não possui dados históricos nem processos estabelecidos.
  • Diferentemente da Colliers, que possui um “mar de dados não estruturados”, a nova construtora partirá do zero.
  • A estratégia para a definição de processos será copiar as melhores práticas do setor, como as da Sienge, em vez de “inventar a roda”, adaptando-as apenas se necessário para o “mundo Coders”.
  • Questiona Pedro sobre como as equipes (o “ser humano”) têm reagido e se adaptado à implantação de novas tecnologias, especialmente perfis não técnicos que precisarão operar as novas ferramentas. [58:56-01:01:41] Pedro aborda a implementação de ERP, o início de um projeto sem dados prévios (“Greenfield”) e a gestão de equipes durante a transição tecnológica.
  • Esclarece que um ERP resolve e melhora processos, mas não aborda automação ou digitalização, sendo crucial que seus dados estejam no Data Lake.
  • Considera o cenário “Greenfield” (começar do zero) como positivo, pois o projeto pode iniciar com suposições (assumptions) que são refinadas à medida que os dados são coletados.
  • Sobre as equipes, afirma que a abordagem varia conforme a área:
    • Para uma equipe comercial sensível, as mudanças (ex: de preços) foram introduzidas de forma quase imperceptível para evitar resistência.
    • Áreas de tecnologia geralmente exigem reciclagem de pessoal ou novas contratações, como cientistas de dados.
    • A tendência para áreas de projeto é o surgimento de “mini-cientistas de dados” ou especialistas de BI para atender a demandas específicas.
  • A aderência varia muito entre empresas, podendo necessitar de “truques” ou até da substituição de pessoal que se torna obsoleto no novo processo. [01:01:42-01:04:20] Igor Reginato explica a estratégia de usar a construtora como um piloto para criar um novo DNA inovador para a Colliers e busca definir os próximos passos.
  • O objetivo não é criar um departamento de inovação, mas sim que a empresa inteira já nasça com um “DNA inovador”.
  • Key Decision: A construtora será o projeto piloto para estabelecer um novo modelo operacional baseado em tecnologia, para depois replicar esse modelo nas outras áreas de negócio (gerenciadora, diligências, transação, etc.).
  • Igor Reginato confirma que a construtora pode usar dados legados da Colliers para o aprendizado dos modelos de IA.
  • A ideia é acelerar negócios, como a venda de terrenos, transformando a oferta de um simples terreno em um “business plan” completo para um centro logístico, por exemplo.
    • Isso seria feito acoplando conhecimentos de várias áreas (avaliação, comercialização, inteligência de mercado) para determinar o melhor uso do terreno (residencial, logístico, industrial) e apresentar ao investidor um plano com projeções de rentabilidade.
  • Após expor esses desejos, pergunta diretamente a Pedro sobre qual é o próximo passo para seguir adiante com o projeto. [01:04:21-01:08:09] Pedro detalha a proposta de próximos passos, iniciando com uma fase de assessment para definir escopo e prioridades.
  • O primeiro passo é detalhar o escopo apresentado para criar uma matriz de priorização do projeto.
  • Action Item: @Pedro - Alocar um arquiteto e um engenheiro de dados para criar o framework (blueprint) onde o Data Lake da construtora será construído - [Sem data definida].
  • Esta fase inicial de assessment e criação do blueprint levaria de 45 a 60 dias.
  • Após o assessment, seria tomada uma decisão sobre como modularizar o projeto: desenvolver pedaços separados ou montar um squad para um escopo mais completo.
  • Pedro afirma que, embora o mercado ofereça ferramentas para partes específicas do problema, não há uma solução única que resolva tudo. A estratégia é centralizar todos os dados primeiro e depois construir ferramentas proprietárias sobre essa fundação.
  • Estima que cerca de 80% do pipeline apresentado pode ser resolvido com IA, o que colocaria a construtora na vanguarda do setor.
  • O plano final a ser apresentado incluirá um cálculo de ROI e comparação com alternativas de mercado para apoiar decisões racionais. [01:08:10-01:14:05] Discute-se o ecossistema integrado, os recursos necessários para o projeto e a viabilidade do cronograma.
  • Igor Reginato destaca a importância de um “ecossistema” para resolver a atual pulverização de sistemas, e vê a IA como ferramenta para unificar processos. A solução deve ser replicável para a América Latina (“multi-tenant”).
  • Ele questiona sobre a equipe que precisará montar e o investimento necessário, informando que os sócios estão dispostos a fazer um aporte significativo.
  • Na fase inicial de assessment, Pedro esclarece que basta um comitê com representantes das áreas afetadas para mapear necessidades e dados.
  • Igor Reginato questiona a viabilidade de atingir R$ 100 milhões em 11 meses, conforme expectativa, e pede uma ordem de grandeza do investimento. [01:14:06-01:15:10] Pedro Villa afirma que o prazo de 11 meses é viável, citando um caso de sucesso e destacando a importância do design e da priorização.
  • Pedro Villa considera o prazo viável e usa como exemplo um projeto da Hapvida, originalmente previsto para dois anos, que sua equipe entregou em 67 dias.
  • Ele esclarece que, embora tenham aproveitado 20% do que já estava pronto no caso da Hapvida, 80% foi desenvolvido do zero.
  • O sucesso dependerá do design do projeto, da priorização de tarefas e de uma análise detalhada sobre como os dados serão consumidos e estruturados. [01:15:12-01:16:19] Pedro Villa detalha sua metodologia de trabalho, baseada em uma equipe especializada e dimensionamento de recursos conforme a prioridade do cliente.
  • Pedro Villa explica que seu “Dream Team” é composto por três PhDs em ciência de dados, que analisam detalhadamente as informações para criar a “planta” do projeto.
  • O trabalho é dividido em partes e entregue a uma equipe de execução, cujos recursos são dimensionados de acordo com as prioridades definidas pelo cliente.
  • Exemplo de priorização: se a área comercial da construtora for a necessidade mais urgente, as ferramentas para esse setor serão desenvolvidas primeiro. [01:16:20-01:17:05] Discute-se a estratégia de contratação de um ERP e a possibilidade de substituí-lo por uma ferramenta proprietária no futuro.
  • Pedro Villa sugere uma abordagem de priorização em squads para resolver dores específicas, como a parte comercial no início das operações da construtora.
  • Propõe-se que o cliente contrate o ERP que já está avaliando, mas com um contrato de curto prazo.
  • A ideia é que, em aproximadamente 12 meses, uma ferramenta proprietária desenvolvida no projeto possa substituir a necessidade desse ERP. [01:17:07-01:18:15] É avaliada a estratégia de utilizar ferramentas SaaS temporariamente enquanto a plataforma de dados é construída.
  • Igor Reginato confirma que seu contrato de ERP é mensal e pode ser rescindido a qualquer momento, o que se alinha à estratégia proposta.
  • Pedro Villa sugere que, enquanto o Data Lake (a fundação) é construído, podem ser usadas algumas ferramentas de mercado no modelo SaaS.
  • Key Decision: Utilizar ferramentas SaaS temporariamente para garantir a ingestão de dados no formato correto no Data Lake, com a intenção de substituí-las por soluções proprietárias em 3 ou 4 meses. - Esta estratégia permite que o trabalho comece imediatamente sem esperar a conclusão da plataforma definitiva. [01:18:16-01:19:55] Define-se a necessidade crítica de que todas as ferramentas de mercado contratadas, incluindo o ERP, possuam APIs para integração.
  • Igor Reginato afirma não haver apego a ferramentas específicas e sugere focar na “coluna vertebral” do negócio (orçamento ao faturamento), abordando dores como a lentidão na assinatura de NDAs (atualmente 30 dias).
  • Pedro Villa estabelece como fundamental que qualquer ferramenta de mercado a ser contratada tenha APIs para garantir a interoperabilidade e evitar dependência de um único sistema.
  • Igor Reginato confirma que já contratou o ERP (Sienge) com APIs disponíveis, especificamente para superar a limitação anterior que exigia o download de CSVs para usar com o Power BI, prática que considerava “pré-histórica”. [01:19:56-01:22:03] Esclarece-se que a solução a ser desenvolvida é uma “plataforma de dados” e não um software ou SaaS tradicional.
  • Igor Reginato questiona a nomenclatura técnica da solução a ser criada (sistema, software, etc.).
  • Pedro Villa explica que a solução não é um software instalável, mas sim uma “plataforma de dados” ou uma “plataforma de serviços e micro-serviços”, que será edificada sobre uma infraestrutura de nuvem (como AWS ou Azure) e utilizará tecnologias como o Databricks para o Data Lake.
  • Key Decision: A solução será tecnicamente definida como uma "plataforma de dados". [01:22:07-01:23:44] São definidos os próximos passos, que incluem a criação de um memorando e a análise de dados existentes.
  • Igor Reginato concorda em compartilhar sua apresentação com Pedro Villa.
  • Action Item: @Pedro Villa - Organizar um memorando com base na conversa, clarificando terminologias e propondo um formato de trabalho para compartilhar com Igor Reginato, Bruno e Ricardo. - Sem data definida.
  • Pedro Villa ressalta a vantagem de iniciar um projeto do zero (“greenfield”), pois oferece mais liberdade, ao contrário de Igor Reginato, que vê a falta de dados como uma desvantagem, mas também reconhece a ausência de “dados mal feitos”.
  • Pedro Villa contrapõe a ideia de “dado ruim”, afirmando que “não existe dado ruim, existe dado mal aproveitado”. [01:23:45-01:25:05] Discute-se a diferença entre o tratamento de dados estruturados e não estruturados no novo contexto de IA e Machine Learning.
  • Igor Reginato relata sua experiência com Power BI, onde gastava a maior parte do tempo limpando e estruturando dados, e expressa curiosidade sobre como o novo sistema lidará com dados não estruturados.
  • Pedro Villa explica que o processo envolverá muitos cálculos e que o machine learning busca o ponto onde “a derivada tende a zero” para encontrar a melhor resposta.
  • Ele assegura que Igor Reginato entenderá rapidamente como dados estruturados e não estruturados se comunicam e como a “máquina pensa”, reforçando que, no final, “é tudo matemática”. [01:25:05-01:26:31] Confirma-se o plano de ação para os próximos passos, focando na elaboração de uma proposta de assessment.
  • Igor Reginato expressa entusiasmo com o projeto e a oportunidade de modernizar as operações.
  • Action Item: @Pedro Villa - Digerir as anotações e estruturar um documento de trabalho (draft de 1-2 páginas) com um plano de trabalho para confirmar o entendimento. - Sem data definida.
  • O próximo passo após o alinhamento será marcar uma reunião para apresentar uma proposta de trabalho para um “assessment” (avaliação).
  • A partir do assessment, o projeto será refinado. [01:26:33-01:27:07] Combinam-se os detalhes de comunicação para agendar a próxima reunião.
  • Igor Reginato se coloca à disposição para contato via WhatsApp ou e-mail a qualquer momento.
  • Action Item: @Igor Reginato - Aguardar o documento de Pedro Villa para, em seguida, marcar o próximo bate-papo envolvendo os demais stakeholders (Bruno e Ricardo). - Sem data definida.