Governança de dados mestres no kickoff do S/4HANA: checklist

A governança de dados mestres está pronta para o kickoff do S/4HANA quando cada item crítico pode ser comprovado com uma evidência: papéis nomeados por objeto, uma política mínima aprovada, um fórum que decide com prazo, uma linha de base de qualidade medida e um critério de qualidade por objeto para passar de fase. O que não estiver pronto não precisa adiar o projeto, mas precisa de dono e data antes dos workshops do Explore.

É comum o kickoff de um projeto S/4HANA ter cronograma, plano de comunicação, matriz de riscos e equipe alocada, e nenhuma linha sobre quem decide o dado. A apresentação mostra as fases, os workstreams e as datas dos mocks. Quando alguém pergunta quem vai aprovar o padrão de descrição de material, a resposta costuma ser "isso a gente vê no Explore".

No Explore, o workshop de compras para no meio porque ninguém na sala pode dizer se um campo é obrigatório. O consultor sugere um padrão, a área aceita para não travar, e três meses depois o primeiro mock volta com erros em boa parte dos fornecedores. A conversa vira "o dado do cliente está ruim", quando o que faltou foi uma decisão tomada antes, por alguém com autoridade para tomá-la.

O que o SAP Activate prevê para dados mestres?

O SAP Activate, metodologia de implantação da SAP, organiza o projeto em workstreams. Segundo a SAP Learning, um dos workstreams sugeridos é Data Management, que cobre carga, limpeza e gestão do ciclo de vida dos dados, com três subfluxos: Data Migration, Data Volume Management e Master Data Management. O objetivo descrito para Master Data Management é alta qualidade de dados, unificação dos dados e sua gestão eficiente (SAP Learning, Discovering the Workstreams).

A mesma lição descreve, no workstream Project Management, o Signoff: como verificar se o projeto está pronto para seguir adiante (os Q-Gates) e com quais critérios. Ela também trata da governança do projeto como o arcabouço em que o gerente de projeto e os sponsors tomam decisões, o que inclui estabelecer papéis, responsabilidades e autoridades de governança e decidir escalonamentos; quem monta essa governança precisa identificar as pessoas-chave que farão parte dela. A lição fala em governança do projeto e não usa o termo "governança de dados". Por isso o checklist deste artigo é uma recomendação para encaixar a governança de dados mestres nesse desenho, e não uma exigência da metodologia.

Um ponto da lição ajuda a entender por que os nomes precisam existir cedo. Na tabela de papéis por workstream, a linha Data Management traz, do lado do cliente (negócio), Business Data Owner (que a SAP descreve como data custodian), Data Preparation Expert, Master Data Change Requestor, Master Data Maintainer e Master Data Sponsor; do lado do cliente (TI), Data Extraction Expert, DVM ALM Process Owner e Master Data Manager (descrito como data steward); e, do lado do parceiro de implementação, Data Migration Architect, Data Migration Developer e Data Volume Management Consultant. Esses nomes não correspondem um a um aos papéis de owner e steward descritos no post sobre quem é data owner e quem é data steward, e cada empresa ajusta a nomenclatura. Entre os órgãos de governança do projeto, o nível 3 inclui um Integrating Committee, que decide sobre integração e gestão de dados mestres entre projetos (SAP Learning, Discovering the Workstreams). Se a própria SAP lista papéis de dado mestre do lado do cliente, faz sentido que eles tenham nome antes do kickoff.

Como saber se a governança de dados mestres está pronta para o kickoff?

A pergunta útil para o PMO e o sponsor é: o que já existe e pode ser mostrado? Uma resposta do tipo "estamos alinhando" não conta. Cada item precisa de uma evidência que alguém consiga abrir: uma lista assinada, uma ata, um relatório com data.

Passo 1: liste os objetos em escopo

Material, fornecedor, cliente, serviço, ativo. O checklist é aplicado por objeto, porque um objeto pode estar pronto e outro não. É comum material ter dono claro e cliente não ter ninguém.

Passo 2: peça a evidência de cada item

Use a tabela abaixo. Para cada linha e cada objeto, marque "existe" ou "não existe". Evite o "em andamento": ou a evidência está pronta, ou o item entra como pendência com dono e data.

Passo 3: decida o que fazer com cada lacuna

Nem toda lacuna adia o kickoff. A coluna "Se não estiver pronto" traz uma saída para cada item e o prazo-limite, que quase sempre é o fim do Prepare ou o início dos workshops do Explore.

Passo 4: leve o resultado ao fórum de decisão do projeto

As pendências viram itens do plano do projeto, com dono, data e acompanhamento no mesmo fórum que trata riscos e escopo. Assim elas entram na conversa do Q-Gate em vez de aparecer no primeiro mock.

Checklist de prontidão da governança de dados mestres

Item	Evidência que comprova	Quem fornece	Risco se faltar	Se não estiver pronto
Papéis nomeados por objeto	Lista com o nome do data owner e do data steward de cada objeto em escopo, validada pelo sponsor	Sponsor e diretores das áreas de negócio	Decisões de dado ficam com o consultor ou com a TI; workshops sem quem responda pelo negócio	Nomear um responsável interino por objeto até o fim do Prepare, com data para o titular
Política mínima aprovada	Documento curto, aprovado e publicado, com itens como quem solicita um cadastro, quem aprova, o que é campo obrigatório e onde fica o padrão de cada objeto	Líder de dados mestres, com aprovação do sponsor	Cada frente do projeto cria a própria regra e elas se contradizem	Aprovar uma versão mínima com o que afeta os workshops do Explore e registrar o restante com dono e data
Fórum de decisão com escalonamento e prazo	Registro de quem decide sobre dado, em quanto tempo responde e para quem sobe um impasse	PMO e sponsor	Pendências de dado se acumulam e só aparecem no mock	Usar o fórum de governança do projeto com um item fixo de dados até existir um fórum próprio
Padrões de dado por objeto	Padrão de descrição, campos obrigatórios e regras de preenchimento definidos, ou com dono e data para definir	Data owners, com apoio dos data stewards	O padrão é decidido às pressas no workshop, por quem estiver na sala	Listar os padrões em aberto, cada um com dono e data anterior ao workshop do objeto
Linha de base de qualidade medida	Relatório com indicadores do legado por objeto (completude, duplicidade de material, validade de documentos de fornecedor) e data da medição	Líder de dados mestres, com extração feita pela TI	Ninguém consegue dimensionar a limpeza nem provar melhora depois	Medir ao menos completude e duplicidade nos objetos principais durante o Prepare
Critério de qualidade por objeto para passar de fase e para os mocks	Critério escrito por objeto, aceito pelo PMO como parte do Q-Gate do projeto	PMO com os data owners	A carga é aprovada porque rodou, não porque o dado está correto	Definir um critério provisório antes do primeiro mock e revisá-lo com a linha de base
Dono do De/Para e das regras de transformação	Nome do responsável por objeto e local único onde o De/Para e as regras são mantidos	Data owners com a equipe de migração	A regra de conversão é decidida por quem escreve o programa de carga	Registrar o dono de cada objeto até o fim do Explore
Regra para criação de cadastro durante o projeto	Decisão escrita: congelamento a partir de uma data ou dupla manutenção com responsável e controle	Sponsor, operação e PMO	Cadastros criados no legado depois do último mock ficam fora da carga ou entram sem tratamento	Decidir antes do primeiro mock e comunicar às áreas que criam cadastro
Plano de governança no Run	Definição de quem mantém cada objeto depois do go-live, com fluxo de solicitação e aprovação	Sponsor e líder de dados mestres	O cadastro volta a degradar logo depois do go-live	Incluir como entregável do projeto, com dono e data antes do cutover
Usuários-chave habilitados em conceitos de dado mestre antes do Explore	Agenda e lista de presença da habilitação	PMO e líder de dados mestres	Os workshops gastam tempo explicando conceito em vez de decidir	Agendar a habilitação no início do Explore, antes dos workshops Fit-to-Standard

Três observações sobre a tabela. Ela pede que os papéis estejam nomeados, não que a matriz de responsabilidades esteja completa; para escolher quem é owner e quem é steward, veja o artigo sobre data owner e data steward no cadastro. A linha de base pede poucos indicadores e uma data; o cálculo de cada um está em como medir a qualidade do cadastro. E a tabela não decide o que limpar antes da conversão; essa triagem, para o cadastro de materiais, está no artigo sobre o material master antes da conversão para o S/4HANA.

Como fica o checklist num caso concreto? (exemplo hipotético)

Exemplo hipotético, criado só para ilustrar o uso do checklist. Não é caso de cliente e os números são ilustrativos.

Uma indústria vai iniciar um projeto S/4HANA com três objetos em escopo: material, fornecedor e cliente. Três semanas antes do kickoff, o PMO aplica o checklist com o sponsor.

• Material: tem data owner nomeado (o gerente de suprimentos), padrão de descrição definido e uma medição de duplicidade feita no ano anterior. Falta o critério de qualidade para os mocks e a regra de criação durante o projeto.
• Fornecedor: tem steward, mas o owner não foi nomeado, porque compras e financeiro discordam sobre quem responde. Não há linha de base de documentos vencidos nem de situação cadastral que não confere.
• Cliente: nenhum item existe.

Na contagem hipotética, a maior parte dos 30 cruzamentos (10 itens por 3 objetos) fica como "não existe". O sponsor não adia o kickoff. Ele nomeia um owner interino para fornecedor e outro para cliente, aprova uma política mínima de uma página, define que o fórum do projeto terá um item fixo de dados com prazo de cinco dias úteis para decisão, e coloca a medição da linha de base de fornecedor e cliente como entrega do Prepare. As outras pendências recebem dono e data antes dos workshops do Explore.

O que sai da reunião é uma lista curta de lacunas, cada uma com responsável, que o PMO acompanha como qualquer outro risco do projeto.

Por onde começar

1. Liste os objetos de dado mestre em escopo do projeto e, para cada um, quem hoje cria, altera e aprova o cadastro.
2. Aplique a tabela acima com o PMO e o sponsor, objeto por objeto, marcando só "existe" ou "não existe".
3. Meça a linha de base dos objetos principais antes do kickoff, nem que seja com dois ou três indicadores.
4. Transforme cada lacuna em item do plano do projeto, com dono e data anterior aos workshops do Explore.
5. Se clientes e fornecedores estão no escopo, revise também os pontos de cadastro de Business Partner no S/4HANA, para o padrão de dado chegar pronto aos workshops.
6. Para entender como a migração e o saneamento se encaixam nas fases do projeto, veja a página de migração de dados para o SAP S/4HANA.

Perguntas frequentes

Dá para começar o projeto sem a governança de dados mestres pronta?

Dá, desde que as lacunas estejam visíveis e tenham dono e data. O risco está em começar sem saber o que falta. A recomendação é fechar os itens que afetam os workshops (papéis, fórum de decisão e padrões por objeto) até o fim do Prepare, e os itens de qualidade (linha de base e critério por objeto) antes do primeiro mock.

Quem deve ser o sponsor da governança de dados no projeto?

Alguém com autoridade sobre as áreas que criam e usam o dado, além da TI. Em muitos projetos faz sentido que seja o próprio sponsor do projeto, porque ele já arbitra conflitos entre áreas. O que não funciona é deixar o papel com o gerente de projeto da consultoria, que não responde pelo negócio depois do go-live.

Preciso de SAP MDG para ter governança de dados mestres no S/4HANA?

Os itens do checklist são decisões de papel, regra e critério, e nenhum deles depende de uma ferramenta específica. A escolha da ferramenta vem depois dessas decisões. Para comparar caminhos, veja o artigo sobre SAP MDG ou MDM complementar.

Governança de dados é a mesma coisa que governança do projeto?

Não. Na SAP Learning, a governança do projeto é o arcabouço em que o gerente de projeto e os sponsors tomam decisões, com papéis, responsabilidades, autoridades e escalonamento do projeto. A governança de dados mestres responde quem decide sobre o dado, com que regra e com que critério de qualidade, e continua depois do go-live. As duas se encontram no fórum de decisão e no Q-Gate, por isso o checklist sugere usar o fórum do projeto enquanto não houver um próprio.

O que muda entre greenfield e brownfield para a governança?

Os itens do checklist valem nos dois casos; muda onde está o peso. Quando o sistema atual é convertido, o cadastro existente segue com o projeto, então a linha de base e a decisão do que limpar antes ganham peso cedo. Quando os dados vêm de um ou mais legados para um ambiente novo, o De/Para, as regras de transformação e os padrões de destino pedem atenção maior. Confirme com a equipe do projeto qual abordagem foi escolhida antes de priorizar os itens.

Como a 4MDG pode ajudar

Na migração de dados para o SAP, a 4MDG trabalha com critério de aceite em cada fase do SAP Activate, relatórios de qualidade com métricas antes e depois do saneamento e governança contínua na fase Run, depois do go-live. Se o checklist mostrou lacunas, comece pelo diagnóstico gratuito: ele é feito sobre um recorte real da base, sem instalar nada, e mostra com número quanto está duplicado, incompleto ou irregular. Prefere conversar antes? Fale com a gente pela página de contato.

Fontes

• SAP Learning, curso Discovering SAP Activate: Implementation Tools and Methodology, lição "Discovering the Workstreams". https://learning.sap.com/courses/discovering-sap-activate-implementation-tools-and-methodology/discovering-the-workstreams_e34f1cd2-362f-4008-a6bd-8085da9caabe. Acesso em 30/10/2026.
• 4MDG, Migração de dados para o SAP S/4HANA. https://4mdg.com.br/pt/migracao-sap-s4hana. Acesso em 30/10/2026.
• 4MDG, Consultoria e diagnóstico. https://4mdg.com.br/pt/consultoria-e-diagnostico. Acesso em 30/10/2026.