Quando uma família de Blumenau decide almoçar em um Madero, ela sabe o que vai encontrar. O hambúrguer tem o mesmo ponto do Madero de Balneário Camboriú, de Curitiba, de Brasília. A batata tem a mesma crocância. O atendimento segue o mesmo script. A música ambiente, o uniforme, a temperatura do ambiente — tudo reconhecível.
Ao mesmo tempo, cada unidade é operada por um franqueado diferente. Alguém que investiu capital próprio, contratou a equipe local, conhece o público da cidade, negocia com o shopping, decide escala, lida com o imprevisto operacional do dia a dia. A franqueadora não opera a loja. Ela habilita o franqueado a operar dentro do padrão.
Esse equilíbrio — autonomia local com padrão compartilhado — é exatamente o desenho organizacional que sustenta um Data Office funcional. No artigo anterior, tratamos das quatro frentes que estruturam um Data Office. Agora, olhamos para o modelo organizacional em detalhe: como esse desenho funciona na prática, quais papéis o compõem, e como ele evolui sem virar burocracia.
“Há decisões que só fazem sentido quando tomadas pela área de negócio, e há padrões que só funcionam quando sustentados de forma compartilhada.“
O modelo federado resolve o falso dilema. Ele parte de uma premissa simples: há decisões que só fazem sentido quando tomadas pela área de negócio, e há padrões que só funcionam quando sustentados de forma compartilhada. A chave é delimitar bem quem cuida do quê.
É o mesmo princípio da franquia. O franqueado decide horário de funcionamento, composição da equipe local, campanhas regionais, operação do dia a dia. A franqueadora define o padrão de produto, a marca, a tecnologia compartilhada, o treinamento inicial, os critérios de auditoria. Nenhum dos dois atropela o outro. Os dois precisam um do outro.
O hub-and-spoke aplicado a dados
O modelo federado do Data Office opera em lógica hub-and-spoke. O hub (centro) é o Center for Enablement, liderado pelo CDO ou Head de Dados. Os spokes (raios) são os domínios de negócio — cada área que gera, transforma ou consome dados de forma intensiva.
O hub carrega o que é padrão: arquitetura de referência, política de governança, catálogo corporativo de dados, treinamento, suporte técnico, metodologia de certificação dos produtos de dados que as áreas vão consumir. Os spokes carregam o que é contextual: conhecimento de negócio, decisão sobre o que construir, priorização de iniciativas do domínio, qualidade do dado de origem, relacionamento com os consumidores internos daquela informação.
O CDO, nesse desenho, não é “o gestor de dados da empresa inteira” — essa postura recria a centralização que o modelo busca evitar. O CDO é o articulador da estrutura. Ele garante que o hub entregue o padrão que os spokes precisam para operar com autonomia, e que os spokes evoluam em velocidade compatível com a visão institucional do tema.
Os papéis que compõem o modelo
No hub, três papéis sustentam a operação. O CDO ou Head de Dados responde pelo tema na diretoria, preside o conselho de dados e presta contas ao comitê executivo — trimestre a trimestre, com reporte formal sobre evolução da agenda e impacto gerado. A liderança do C4E conduz a equipe especializada em padrões, capacitação e suporte. E o Arquiteto de Dados cuida da coerência técnica da plataforma e dos produtos de dados certificados, garantindo que o que se constrói em um domínio seja interoperável com o que se constrói em outro.
Nos spokes, três papéis são fundamentais.
O Data Owner é o responsável institucional pelos dados do domínio — tipicamente um gerente ou diretor da área de negócio, não alguém da TI. É quem responde “sim” ou “não” quando outra área pede acesso a um dado do domínio, quem aprova mudança na definição de um indicador, quem arbitra se um caso de uso de IA pode ou não avançar usando aquela base.
O Data Steward é o responsável operacional — quem cuida do padrão no dia a dia, acompanha indicadores de qualidade, reporta ao Data Owner, participa dos fóruns do C4E. Frequentemente é o analista que já fazia isso informalmente, agora com nome, processo e apoio.
O Data Product Owner é quem traduz as necessidades do domínio em produtos de dados priorizados — com visão de roadmap, entendimento do que é valor para a área e articulação com o C4E sobre o que deve ser construído, em que ordem e com que padrão. É o papel que garante que o backlog do domínio não vire lista de desejos, e sim uma carteira orientada a impacto.
Em projetos de diagnóstico que temos conduzido em indústrias brasileiras, um padrão chama atenção: esses papéis já existiam em estado informal antes do Data Office ser estruturado. Toda área que lida intensivamente com dado tem alguém que, na prática, é o dono do indicador, alguém que cuida dele no dia a dia, e alguém que prioriza o que precisa ser construído primeiro. O que a estrutura formal faz é tirar essa prática da sombra, dar nome, dar mandato, dar suporte — e integrar esses profissionais em um fluxo institucional reconhecido.
Os fóruns onde a estrutura vive
Papel formalizado que não se traduz em prática real não sustenta modelo algum. O que faz o desenho federado funcionar são os fóruns onde hub e spokes se articulam com regularidade.
No nível institucional, o comitê executivo de dados reúne a alta liderança em cadência trimestral — CDO, CFO, CIO, líderes das principais áreas de negócio. Não é fórum técnico; é fórum de decisão. Ali se arbitra prioridade entre iniciativas que disputam o mesmo investimento, se aprova novo orçamento, se acompanha o reporte do CDO sobre o estado da agenda. É o mecanismo que mantém dados como tema vivo no topo da organização, não como pauta ocasional entre outras de TI.
No nível operacional, o conselho de dados reúne os Data Owners dos domínios com a liderança do hub em cadência mensal ou bimestral. É onde se discute roadmap de produtos de dados, se formaliza nova definição de indicador cross-funcional, se articula conflito entre domínios sobre significado de um dado. É o fórum onde a lógica federada de fato acontece — com os donos do dado sentados à mesma mesa que quem carrega o padrão.
Em casos de políticas específicas, fóruns temporários se formam. Em projetos de governança de IA em multinacional brasileira que temos acompanhado, a construção da política exigiu um fórum dedicado, com ciclos curtos de co-construção entre a liderança de governança e as áreas que demandavam iniciativas de IA. O resultado não foi um documento escrito no gabinete, mas uma política desenhada com as pessoas que iam operar sob ela — o que reduziu drasticamente a curva de adoção depois.
O que esse modelo evita na prática
Quando o desenho federado funciona, algumas dinâmicas conhecidas deixam de acontecer. A área comercial para de precisar abrir chamado para obter um dashboard de margem regional — ela tem o Data Steward da área e a plataforma do hub para fazer isso com autonomia. Duas áreas que historicamente divergem sobre a definição de um indicador cross-funcional (cliente ativo, ticket médio, margem de contribuição) passam a ter um fórum onde a divergência se resolve institucionalmente, e a definição vira referência única. Novos projetos de IA param de começar do zero na discussão sobre viabilidade — chegam ao conselho já com o filtro dos domínios envolvidos, o que acelera decisão e reduz desperdício de iniciativa.
Nada disso é mágico. É consequência de uma estrutura onde autonomia e padrão convivem, e onde os fóruns funcionam de verdade — com cadência, com pauta, com reporte, com consequência.
Sobre esta série
Este é o terceiro artigo de uma série de cinco sobre Data Office publicados no blog da Target. Os anteriores trataram do que é um Data Office e por que ele virou tema de estratégia, e das quatro frentes que compõem sua estrutura. Os próximos exploram o playbook de implementação em seis fases calibrado para a realidade brasileira, e o framework de mensuração de valor e gestão da mudança ao longo do tempo. Cada artigo foi desenhado para funcionar de forma autônoma, mas lidos em sequência constroem uma visão integrada do tema.
Uma franquia bem desenhada não é uma marca que controla lojas. É uma marca que torna possível a existência daquelas lojas — dando ao franqueado acesso a padrão, tecnologia e suporte que ele sozinho não teria capacidade de construir. Um Data Office federado opera com a mesma filosofia. Não controla as áreas; torna possível que elas decidam com velocidade dentro de um padrão que sustenta a confiança institucional no dado.
No próximo artigo, traduzimos esse desenho em um playbook: seis fases de implementação, com as armadilhas típicas e os frameworks para endereçá-las em cada etapa.
Esta série de artigos faz parte de uma iniciativa mais ampla da Target para aprofundar o debate sobre Data Office no mercado de dados brasileiro — um tema que, pela relevância e pelo volume de perguntas que recebemos, claramente merecia mais do que uma publicação avulsa.
Além dos artigos, realizamos um webinar gratuito conduzido pelo Alan Feliciano, nosso Head de Data Office, onde estudantes, analistas, engenheiros de dados, gestores, CDOs e donos de empresa se reuniram para discutir, na prática, como estruturar uma operação de dados que funciona. Foi a primeira edição de muitas. Se quiser conferir um pouco de como foi, acesse o post no Linkedin e no Instagram.
Série: Data Office — o próximo capítulo da jornada de dados
1. O que é Data Office e por que ele virou tema de estratégia (acesse aqui)
2. A anatomia das quatro frentes que sustentam o Data Office (acesse aqui)
3. Desenho organizacional federado: papéis, domínios e responsabilidades (você está aqui)
4. Playbook de implementação em seis fases para a realidade brasileira (disponível em alguns dias, fique de olho no blog)
5. Framework de mensuração de valor e gestão da mudança (disponível em alguns dias, fique de olho no blog)
