Estrutura Organizacional

Fui chamado para ajudar uma empresa poucos meses depois do go-live. O sistema estava no ar, os usuários treinados, os processos mapeados. Tudo parecia funcionar, até o controller pedir um relatório consolidado de estoque por empresa.

O resultado era um desastre silencioso: duas plantas do mesmo grupo econômico tinham sido cadastradas em empresas (company codes) diferentes. O inventário não consolidava. O fechamento mensal virava uma maratona de reconciliação manual.

A causa era simples: lá no início do projeto, a estrutura organizacional havia sido definida às pressas, sem alinhamento com a realidade do negócio.

Esse cenário se repete com uma frequência assustadora. A Gartner prevê que, até 2027, mais de 70% das iniciativas de ERP recém-implementadas não vão cumprir plenamente os objetivos de negócio, e cerca de um quarto vai falhar de forma grave. Uma das causas mais recorrentes é justamente a definição inadequada da estrutura organizacional nos primeiros dias do projeto. Ela parece técnica demais para os gestores e simples demais para os consultores, e acaba sem dono.

Este artigo muda isso. Você vai entender a hierarquia completa do SAP MM, por que cada nível existe e quais erros evitar antes que virem problemas impossíveis de resolver.

A hierarquia organizacional do SAP MM

O SAP MM opera dentro de uma estrutura hierárquica de unidades organizacionais. Pense nela como a planta baixa do sistema: antes de construir qualquer coisa (regras de compra, movimentos de estoque, integração com o financeiro), você precisa da fundação certa.

Cada nível é independente na configuração, mas interdependente na operação. Repare, no diagrama, que a Organização de Compras (em roxo) se liga a centros de empresas diferentes por linhas tracejadas: é o modelo de compras centralizadas, que veremos adiante. Vamos a cada nível.

Mandante (Client)

O nível mais alto do SAP. Representa uma instalação completa e independente: todos os dados e configurações existem dentro dele. Na prática, uma empresa costuma ter três mandantes: desenvolvimento, qualidade e produção. Não se “muda de mandante” durante a operação; é uma fronteira sistêmica.

Tabela: T000 · Campo-chave: MANDT

Erro comum: confundir mandante com empresa. Um mandante pode conter vários grupos econômicos.

Empresa (Company Code)

A unidade legal e contábil do SAP: uma entidade com CNPJ próprio (que, a propósito, passa a ser alfanumérico a partir de 2026), balanço independente e obrigações fiscais específicas. Cada empresa tem sua moeda, seu plano de contas e seu fechamento. É aqui que a integração MM-FI começa: toda movimentação de material que gera valor contábil está atrelada a uma empresa.

Tabela: T001 · Campo-chave: BUKRS (4 dígitos) · Configuração: OX02 (definir) / EC01 (copiar de um modelo)

Regra importante: um centro pertence a exatamente uma empresa, nunca o contrário.

Centro (Plant)

O coração do SAP MM. É neste nível que quase tudo acontece: recebimento, gestão de estoque, execução do MRP, valoração de materiais. Um centro pode ser uma fábrica, um centro de distribuição, um escritório ou um canteiro de obras. O critério não é o tipo de instalação, e sim a necessidade de gestão independente de estoque e compras.

Tabela: T001W · Campo-chave: WERKS (4 dígitos) · Configuração: OX10 (criar), OX18 (atribuir à empresa)

Dados de material por centro ficam na MARC; saldos de estoque por centro e depósito, na MARD.

Depósito (Storage Location)

A subdivisão física dentro de um centro, onde os materiais ficam guardados. Exemplos: matéria-prima, produto acabado, consignação, estoque bloqueado. Permite segregar estoques dentro da mesma planta sem criar unidades organizacionais separadas.

Tabela: T001L · Campos-chave: WERKS + LGORT · Configuração: OX09

Atenção para o S/4HANA: o MRP não roda no nível de depósito. Se você precisa planejar por subdivisão física, usa MRP Areas, uma entidade configurada à parte.

Organização de Compras (Purchasing Organization)

A unidade responsável por negociar com fornecedores, gerenciar contratos e definir condições. Pode ser específica de um centro ou atender vários (compras centralizadas):

Modelo	Descrição	Quando usar
Específica de centro	Atende exclusivamente um centro	Processos muito específicos por unidade
Cross-plant	Atende múltiplos centros	Compras centralizadas, ganho de escala

Tabela: T024E · Campo-chave: EKORG · Configuração: OX08 (criar), atribuição via SPRO

A escolha entre centralizada e específica é uma das decisões mais estratégicas da implementação. Depois de definida e com dados em produção, mudar é caríssimo.

Grupo de Compradores (Purchasing Group)

A menor unidade do processo de compras: um comprador ou equipe responsável por uma categoria de materiais. Aparece em todos os documentos de compra (requisição, cotação, pedido) e é essencial para relatórios de produtividade e compliance. Não é atribuído à estrutura empresarial: opera no nível do mandante.

Tabela: T024 · Campo-chave: EKGRP (3 dígitos) · Configuração: OME4

Por que a estrutura certa faz diferença

Não tenho números de mercado para isso, mas, em mais de duas décadas de projetos, o padrão é claro. Uma estrutura bem documentada permite incluir um novo centro em poucos dias; uma estrutura confusa transforma o mesmo trabalho em semanas de retrabalho e reconfiguração de outros módulos. A segregação correta de depósitos reduz erros de separação; a atribuição bem pensada de grupos de compradores dá rastreabilidade para auditoria. E refazer a estrutura depois do go-live custa várias vezes mais do que fazer certo antes, porque envolve ajustar documentos em aberto, reconciliar saldos e revalidar a integração com o financeiro.

Erros comuns

Criar (ou deixar de criar) um centro sem avaliar os critérios certos. Cada centro adiciona complexidade de manutenção, então a decisão precisa ser justificada, mas os critérios vão muito além de “tem compras próprias”. Um centro pode se justificar por benefício fiscal (regimes e incentivos que variam por estado), por necessidade logística, por valoração de estoque separada ou por exigência legal, mesmo sem gestão de compras independente. O erro não é ter muitos centros; é decidir no automático, sem analisar esses fatores. A pergunta certa não é “precisa de compras próprias?”, e sim “o que justifica um centro aqui: fiscal, logística, valoração ou lei?”.

Confundir empresa com centro. Três filiais com o mesmo CNPJ que consolidam no mesmo balanço são uma empresa com três centros, não três empresas.

Não documentar a lógica de atribuição. Sem registrar por que cada org de compras está ligada a cada centro, qualquer mudança futura vira arqueologia de sistema.

Atribuir a organização de compras errada. Criar uma org cross-plant mas tratá-la como específica de centro gera um problema silencioso: pedidos de um centro somem para o outro, com duplicação e perda de escala.

Ignorar a integração com o FI. Cada centro impacta o financeiro (valuation area, centro de custo, business area). Estruturar o MM sem alinhar com o FI cria inconsistências que só aparecem no fechamento.

Mexer na estrutura depois do go-live. O erro mais caro de todos. Já vi uma correção de consolidação de centros durar meses e envolver o ajuste de centenas de documentos em aberto.

No S/4HANA

O S/4HANA não eliminou a estrutura organizacional, mas endureceu algumas regras:

• Material Ledger obrigatório. No ECC era opcional; agora a valoração de materiais acontece sempre no nível do centro. Projetos de migração que ignoram isso costumam ter surpresas no cutover.
• MRP Areas substituem o planejamento por depósito, que deixou de existir.
• Business Partner unificou o cadastro de fornecedores, mas a estrutura (org de compras, grupo, centro) continua sendo o contexto que define as condições. Estrutura ruim continua gerando dado ruim, independentemente da interface nova.

A mensagem é simples: o S/4HANA torna a estrutura organizacional mais importante, não menos. Decisões que no ECC dava para contornar agora têm impacto direto em funcionalidades obrigatórias.

Como começar com o pé direito

Comece pelo negócio, não pelo sistema. Antes de abrir o SPRO, responda: quantas entidades legais existem? Quantos locais com estoque independente? Quem compra o quê e para onde?

Monte a matriz de atribuições. Numa planilha simples: qual centro em qual empresa, quais depósitos em cada centro, qual org de compras atende qual centro, qual grupo cuida de qual categoria. Esse mapa vale ouro.

Valide com as áreas antes de configurar. Finanças valida as empresas; Compras aprova as organizações de compras; Operações confirma os depósitos. Duas horas de reunião no início evitam dois meses de retrabalho depois.

Congele o design antes do go-live. Defina uma data (em geral três meses antes) a partir da qual nenhuma mudança de estrutura entra sem passar por um comitê. Mudança de última hora em estrutura organizacional é uma das principais causas de problema no cutover.

Conclusão

A estrutura organizacional é o ponto de partida de qualquer implementação SAP MM, e o lugar onde mais erros silenciosos são cometidos. Acertar aqui é o que faz o resto do sistema fluir.

No próximo artigo entramos nos dados mestres, começando pelo Mestre de Material: o cadastro que sustenta compras, estoque e planejamento, e onde um único campo mal preenchido trava a operação lá na frente.