Portal de Processos · Diagnóstico AS IS

Diagnóstico de processos da Atacadão Dia a Dia

Retrato preliminar dos processos operacionais, montado do que as conversas de projeto permitem afirmar. A validar com quem opera cada etapa.

Compras e Registro de Despesas

Preliminar

Confiabilidade 44/100

Primeiro retrato do processo de compras e registro de despesas do Atacadão Dia a Dia, construído a partir de 6 reuniões de alinhamento do projeto (dez/2025 a jul/2026). Importante: ainda não houve um mapeamento de processos dedicado deste fluxo - o entendimento veio de conversas...

Perfil do cliente

O contexto em que esse processo vive

CNPJ

17.457.404/0001-01
matriz - Atacadão Dia a Dia S.A.

Fundação

30/07/2012
raízes em 1960 (mercearia Casa Oliveira, Padre Bernardo/GO); marca Atacadão Dia a Dia lançada em 2013

Sede

Ceilândia Sul, Brasília-DF
Núcleo Rural Alex Gusmão, Gleba Lote 455-A, BR-070 Km 08

Porte

Grande
36 lojas no DF, GO, BA e TO; mais de 9 mil colaboradores diretos

Receita

R$ 6,6 bilhões
Ranking ABRAS 2026 - maior rede de varejo alimentar do DF, 20ª posição nacional

Escala do processo

~1.040 compras/mês
~250 usuários no Fluig - escopo operacional deste mapeamento

O Atacadão Dia a Dia é uma das maiores redes de atacarejo (cash & carry) da região Centro-Oeste, com raízes que remontam a 1960, quando os irmãos Jaci e Zico Oliveira fundaram a mercearia Casa Oliveira em Padre Bernardo (GO). A família expandiu os negócios para o Distrito Federal ao longo das décadas seguintes, e a marca Atacadão Dia a Dia nasceu em 2013, consolidando o modelo de atacarejo que hoje soma 36 lojas no Distrito Federal, Goiás, Bahia e Tocantins, com mais de 9 mil colaboradores diretos.

Diferente de atacarejos tradicionais, a rede investe em serviços agregados como padaria, açougue e adega de vinhos, além do programa de fidelidade Clube DD+ e do formato DD Express para compras rápidas. Segundo o Ranking ABRAS 2026, a empresa faturou cerca de R$ 6,6 bilhões - a maior rede de varejo alimentar do Distrito Federal, na 20ª posição nacional.

O ERP em uso é o Consinco (TOTVS), implantado nas lojas a partir de maio de 2026. Este portal mapeia o processo de Compras e Registro de Despesas; outros quatro fluxos (Contrato, Expansão, Reembolsos/Concessionárias e "Fora da norma") foram citados e ainda serão mapeados.

Linhas de atendimento e formatos

36 lojas físicas no DF, GO, BA e TO - alimentos, bebidas, higiene e limpezaServiços internos agregados: padaria, açougue e adega de vinhosClube DD+ - programa de relacionamento e fidelidadeDD Express - formato para compras rápidas e convenientesAtendimento dedicado a fornecedores para negociação e parceria

Diferenciais

Aposta no atacarejo premium: agrega serviços de supermercado tradicional (padaria e açougue de qualidade) aos preços competitivos do atacado
Forte identificação regional, com raízes na história da família fundadora em Goiás desde 1960
Reputação classificada como "BOM" no Reclame Aqui (nota ~7,4 a 7,6/10); responde quase 100% das reclamações, com índice de solução acima de 73%

Liderança

Alessander Junior da Silva

Sócio e Diretor (COO) - mais de 25 anos em gestão comercial e operações no varejo alimentar

Braz Sebastião Aparecido da Silva

Sócio e Diretor

Gerardo Carvalho da Silva Junior

Sócio e Diretor

Cristiano da Silva Nogueira

Sócio

Saulo da Silva Pereira

Sócio

Concorrência no setor de atacarejo (Centro-Oeste)

Atacadão (Grupo Carrefour) - líder nacional do setor, forte presença no DF e GoiásAssaí Atacadista - vice-líder nacional, em expansão agressiva no Centro-OesteCosta Atacadão - concorrente regional forte no entorno do DF e GoiásSuper Adega - modelo de atacarejo com foco em serviços premium e adega de vinhosFort Atacadista (Grupo Pereira) - player nacional buscando espaço no Centro-Oeste

A empresa e seus processos

Visão geral do portfólio

Onde o Atacadão Dia a Dia está na jornada de gestão dos seus processos. Este portal começa pelo processo de Compras administrativas e despesas, mas a ambição é ser o mapa institucional de todos os processos da empresa - cada um evoluindo de identificado até automatizado e em produção. O painel abaixo mostra, com honestidade, o que já enxergamos e o quanto ainda há pela frente.

4

Identificado

apareceram nas conversas, ainda sem diagnóstico

1

Em diagnóstico

retrato preliminar (Compras ADM)

0

Mapeado dedicado

entrevistas com a ponta

0

Automatizado / produção

Fluig ainda em construção

Processos conhecidos

Compras administrativas e despesas

Da necessidade de compra ao registro e pagamento da despesa. Retrato preliminar em curso - o processo deste portal.

em diagnóstico

Compras por contrato

Fluxo de despesas com contrato ativo, citado nas reuniões como caso de alçada e recorrência próprias. Ainda não diagnosticado.

identificado

Compras de expansão

Compradores de expansão usam um fluxo próprio (dito por Compras). Aparece como processo vizinho, a mapear.

identificado

Reembolsos e concessionárias

Despesas de reembolso e de concessionárias citadas como fluxo distinto. A mapear.

identificado

Compras fora da norma / emergenciais

O caminho da compra já feita fora do processo (cartão emergencial, urgência), citado como recorrente. A mapear.

identificado

O inventário completo dos processos do Dia a Dia ainda não foi levantado - por isso este painel não mostra um total nem um percentual: seria um número inventado. Começamos pelo processo de Compras administrativas e despesas porque foi por ele que o projeto de automação começou - não por uma priorização estratégica do portfólio. Levantar o inventário e priorizar quais processos mapear e automatizar primeiro é um passo futuro, que a estratégia da empresa vai orientar, e é o que faz o portal virar o mapa institucional dos processos.

Onde os processos criam valor

Cadeia de valor

Onde cada processo do Dia a Dia cria valor, e o quanto já enxergamos de cada um. O bloco em destaque é o processo deste diagnóstico; os demais mostram, com honestidade, o limite atual da nossa base de conhecimento.

Atividades de suporte

Compras administrativas e despesas

Em diagnóstico

O processo deste diagnóstico: compras de uso e consumo, serviços e despesas das lojas e da administração. Entendimento vindo de reuniões de alinhamento do projeto, sem mapeamento dedicado.

Controladoria, Financeiro e Contabilidade

Tocado pelo diagnóstico

Controladoria e Financeiro aparecem nas reuniões pelo papel que cumprem no processo mapeado (orçamento, alçadas, pagamento). Contabilidade e Fiscal ainda não foram consultados.

Tecnologia da informação

Tocado pelo diagnóstico

Fluig (BPM), Consinco e RM (TOTVS) apareceram nas conversas pelo papel que cumprem no processo de compras. O desenho completo da área não foi levantado.

Gestão de pessoas

Sem informação

Nenhuma informação coletada até aqui.

Atividades primárias

Compra de mercadoria para revenda

Sem informação

Fluxo comercial, separado das compras administrativas. Não abordado por nenhuma fonte deste diagnóstico.

Abastecimento e distribuição às lojas

Sem informação

Sem informação nas fontes até aqui.

Operação das 36 lojas

Tocado pelo diagnóstico

Aparece no diagnóstico apenas onde cruza com o processo mapeado: solicitações feitas pelas lojas e lançamento manual de notas em cada uma.

Venda no modelo atacarejo

Sem informação

Conhecida pelo perfil público da empresa (atacado + varejo). Nenhum processo comercial foi abordado nas conversas.

Esboço de referência montado exclusivamente a partir do perfil público da empresa e das seis reuniões do projeto de compras (dez/2025 a jul/2026). Nenhum bloco além do processo mapeado foi objeto de levantamento dedicado; as descrições registram apenas o que essas fontes permitem afirmar. A cadeia se completa à medida que novos processos forem mapeados.

Panorama do processo

Compras e Registro de Despesas

Retrato preliminar, a partir de reuniões de alinhamento do projeto. Ainda não houve um mapeamento de processos dedicado.

44

Preliminar

confiabilidade /100

6

Reuniões

8

Etapas descritas

8

Achados

8

Lacunas

Governança do processo

Quem responde pelo processo, quem decide e com que rito ele é revisto. Nas seis reuniões realizadas, nenhum destes papéis foi formalizado. Não é um detalhe: enquanto não houver dono e alçadas, cada mudança de regra depende de quem estiver na sala.

Dono do processo

Não definido

Nenhuma reunião nomeou um responsável único. Hoje a condução é compartilhada entre Compras, Controladoria e o projeto de TI.

Gestor operacional

Não definido

Compras executa o dia a dia, mas sem designação formal de gestão do processo.

Alçadas de aprovação

Não definido

Não definidas. O fluxograma de alçadas está pendente com a Controladoria, é um dos achados deste diagnóstico.

Fórum de revisão

Não definido

Não existe rito periódico. O processo muda por demanda do projeto de automação, sem cadência de revisão estabelecida.

Processo de cadastro

Não definido

Não estruturado e sem dono. Roda hoje no Gestão X (fora do Fluig, desconectado do ERP). Cláudio (S7): é o coração do processo, mas ninguém responde por ele. É um "filhote de processo" a organizar.

Seções deste diagnóstico

1 / 12

O esqueleto do processo

O fluxo do processo, como foi descrito

O diagrama abaixo é o processo como as pessoas o descrevem - o fluxo de negócio, não o desenho técnico do Fluig. Os dois diferem: uma atividade da automação pode resolver várias etapas de negócio, e boa parte do processo hoje acontece fora do sistema (cotação em ferramenta própria, lançamento manual no ERP). Cada etapa traz seu tipo: o sistema faz (engrenagem), a pessoa faz pelo sistema (pessoa) ou a pessoa faz fora do sistema (mão). A correspondência entre este fluxo e o do Fluig está no mapa de automatização.

↓ Baixar o fluxo em SVG (amplie sem perder qualidade)

Descrição das atividades

1

Solicitante

Registrar a necessidade / solicitação

2

Compras

Cotar com os fornecedores

3

Aprovador

Aprovar (alçada + orçamento)

Aprova → segue | Sem orçamento → barra

4

Solicitante

Gerar a requisição no ERP

5

Compras

Executar a compra / pedido ao fornecedor

6

Solicitante

Receber e conferir

7

Central de lançamento

Lançar a nota no ERP

8

Financeiro

Pagar

Detalhamento das etapas

A versão densa de cada etapa, para leitura e validação em campo. Onde o detalhe vem de uma única voz, isso está sinalizado no texto.

1 Registrar a necessidade / solicitação

Solicitante

A área que precisa comprar abre a demanda no Fluig, num fluxo de solicitação que já existe (natureza de despesa, item, quantidade, centro de custo, filial). Mas, na prática, esse fluxo formal é contornado na maior parte das vezes: em cerca de 70% dos casos a compra já aconteceu antes de qualquer registro, alguém compra por pedido de um superior ou por urgência, e só depois abre-se a solicitação para regularizar a despesa, quase como um pedido de pagamento. Esse padrão foi confirmado em reuniões separadas, de dezembro de 2025 e maio de 2026, o que sustenta que não é uma exceção pontual. O solicitante é o próprio usuário logado no Fluig (entre 200 e 250 pessoas, criadas por chamado, sem integração de matrícula com o Consinco ou o RM); quem pede pela loja é o administrativo da filial. O projeto em curso quer inverter essa cultura para "quero comprar", não "já comprei, pague", exigindo uma única natureza de despesa por pedido (sem misturar ativo com material de consumo), justificativa obrigatória, e a especificação item a item com centro de custo, filial e unidade de medida. A data de necessidade, pensada com um mínimo de três dias de antecedência, deve dar lugar a um SLA de 30 horas úteis por etapa; o rateio entre centros de custo, quando existir, deve somar 100%. Preencher solicitante e filial automaticamente a partir do login foi discutido mas adiado para uma segunda versão: a TI considera a integração entre Fluig, Consinco e RM complexa demais para a entrega inicial. Aqui há um desvio importante: se o solicitante não encontra o item que precisa comprar, o fluxo cai numa área de Cadastro, ela verifica se o item realmente não existe, cadastra no ERP, vincula a natureza de despesa e empurra o pedido adiante, sem devolver ao solicitante. Esse sub-fluxo de cadastro de item ainda está sendo desenhado (TO-BE), espelhando o de fornecedor que já roda hoje; ficou em aberto se a natureza é vinculada no próprio cadastro ou se exige uma etapa extra de outra área.

2 Cotar com os fornecedores

Compras

A cotação roda hoje fora do Fluig, numa ferramenta caseira criada pela própria área de Compras: ela categoriza o produto, vincula automaticamente os fornecedores daquela categoria, dispara um e-mail com um link externo para cada um preencher a proposta e devolve um mapa comparativo em PDF. São cerca de mil cotações por mês; o resultado é hoje digitado manualmente no Fluig, e uma cotação simples de cinco fornecedores por cinco produtos já significa 25 digitações. Itens de consumo recorrente não são recotados a cada pedido: são cotados uma vez, com uma tabela de preços válida por dois a três meses; a ideia de pular a cotação por completo para itens já pré-negociados ainda está em discussão, não é prática confirmada hoje. O desenho em curso quer trazer essa lógica para dentro do Fluig: o frete passaria a compor o valor da cotação (hoje é só um campo descritivo), a forma de pagamento viraria uma opção pré-cadastrada como 30 DDF ou DDE em vez de texto livre, e o prazo de entrega seria calculado em dias corridos a partir da aprovação. Uma proposta teria validade padrão de 5 dias, embora a prática hoje gire entre 7 e 15, e venceria automaticamente se ultrapassado esse prazo, cancelando a solicitação. A meta de SLA para toda a etapa é de 30 horas úteis. Como no cadastro de item, aqui há um desvio que já funciona hoje: quando o fornecedor escolhido não está cadastrado, o fluxo cai numa área de Cadastro que o registra no ERP e devolve ao formulário para seguir adiante, é justamente esse fluxo de cadastro de fornecedor, já em operação, que o de item pretende replicar.

3 Aprovar (alçada + orçamento)

Aprovador

Hoje o próprio solicitante valida a cotação e pode até trocar o fornecedor ou o preço vencedor escolhido, e, se optar por um fornecedor mais caro, precisa justificar. Existe uma alçada de gerente e depois regional antes de chegar ao diretor, resolvida por um dataset no Fluig, mas os valores dessa alçada nunca foram definidos: na prática, quase tudo cai na alçada do próprio solicitante. A verificação de saldo orçamentário via API já foi liberada, embora o endpoint ainda não retorne dado real; segundo as reuniões, o sistema em construção deve barrar o envio sem orçamento suficiente. O orçamento é consultado por conta contábil, ano, mês, filial e centro de custo, sempre por natureza de despesa, não por item. Falta definir as alçadas reais por valor, com o fluxograma sob responsabilidade da Controladoria, mas já se sabe que despesa vinculada a um contrato ativo deve ter alçada menor, condicionada à vigência e ao saldo do contrato (mensal ou anual), e que algumas naturezas só podem lançar nota se houver contrato. Certas contas, como água e esgoto, têm a trava orçamentária desligada por parâmetro, pagando mesmo acima do previsto. Aprovar a despesa deve ficar separado de escolher e justificar a compra, são papéis diferentes.

4 Gerar a requisição no ERP

Solicitante

A requisição que reserva o orçamento no Consinco ainda é criada manualmente, enquanto a tarefa segue aberta no Fluig, as fontes não são unânimes se é o próprio solicitante ou a área de Compras que a cria na prática, a confirmar. Se ela não for criada, o orçamento simplesmente não é reservado, e o Fluig passa a mostrar um saldo disponível que não reflete a realidade. Hoje a requisição só reserva o valor total e grava o fornecedor, sem descrição item a item; seu número no Consinco é distinto do número do processo no Fluig, ainda que os dois estejam vinculados. Há consenso entre Controladoria, TI e Diretoria de que essa reserva precisa se tornar automática, via integração, e não mais depender de alguém lembrar de fazê-la; sem orçamento, o sistema deveria bloquear a criação. O maior obstáculo é técnico: não existe hoje uma rota que permita ao Fluig inserir dados no Consinco, só consultá-lo. Como caminho intermediário, a TI propõe que o Fluig apenas confirme, por uma consulta simples, se a requisição já foi criada, e bloqueie o avanço do processo enquanto ela não existir. Ficou uma tensão sem resolver entre a Praxis e a TI do cliente sobre a direção dessa integração: se o Fluig deve orquestrar o Consinco ou se todo o trâmite deve entrar pelo Fluig como requisição e virar pedido diretamente no ERP.

5 Executar a compra / pedido ao fornecedor

Compras

Com a requisição criada, a área de Compras confirma a compra e envia as informações ao fornecedor vencedor. Aqui há um desvio citado em duas reuniões: assim que a compra é executada, verifica-se se o item é imobilizado; se for, o processo desce para o Patrimônio colocar a plaqueta antes de voltar e confirmar a compra. Ficou em aberto a definição precisa do que conta como item realmente imobilizado, ponto que a Controladoria (Thiago) vai fechar. A requisição, uma vez criada, trava o valor e o fornecedor, que deixam de poder ser editados no lançamento. Compras com entrega direto no centro de distribuição já passam pelo módulo comercial do Consinco, fora deste fluxo administrativo; a revenda tem um fluxo próprio, também fora deste recorte. O projeto quer permitir o desmembramento: uma única solicitação poder virar vários pedidos, um por fornecedor vencedor, cada um com sua própria requisição. Como fricção proposital contra a compra sem aprovação prévia, toda despesa classificada como fora da norma deve ir sempre ao diretor financeiro, mesmo em valor baixo; e a data do pedido deve ser validada contra a data de emissão da nota, para impedir que uma compra aconteça antes da requisição que deveria autorizá-la.

6 Receber e conferir

Solicitante

Quem pediu recebe e confere o produto, mas não há hoje nenhuma conferência automática entre o que foi pedido, o que veio na nota e o que efetivamente chegou. Já aconteceu de uma nota chegar com um preço diferente do pedido e ser recebida sem que ninguém percebesse a divergência. O Consinco já suporta recebimento parcial e a sinalização de item imobilizado, embora compra parcial seja rara na prática. A ideia em construção é registrar o recebimento com mais precisão, total, parcial, com ressalvas (avaria, quantidade incompleta, item divergente ou atraso) ou não recebido, anotando a data real e quem recebeu, e introduzir um recebimento cego: o recebedor informa a quantidade e o valor unitário que efetivamente chegaram, e o próprio sistema compara com a nota para identificar divergências. A nota fiscal passaria a ser validada contra o pedido antes de seguir adiante, e quem anexa essa nota deve ser sempre a área que fez a compra, não a área de compras, para garantir que alguém confirme ter recebido.

7 Lançar a nota no ERP

Central de lançamento

A central de lançamento abre o anexo da nota e digita cada campo à mão no Consinco (CNPJ, datas, valores, impostos) para as 36 lojas da rede, a um custo de cerca de 5 minutos por nota e sujeito a erro de digitação. Como o ERP não tem onde anexar o documento, a nota fica anexada no Fluig. Essa é, hoje, a única parte do processo já integrada de fato: a entrada da nota já gera os pagamentos no sistema, embora a formalização de compras já feitas às vezes gere duas entradas para a mesma despesa. A solução em desenho prevê a leitura automática do XML ou do DANFE por um leitor ou coletor, eliminando boa parte da digitação manual e deixando a central de lançamento livre para atuar em gestão de contratos e monitoria. O número do Fluig da nota precisa ficar vinculado à requisição que reservou o orçamento, e o fluxo deve aceitar que um único desdobramento gere até 3 notas distintas.

8 Pagar

Financeiro

O Financeiro executa o pagamento diretamente no ERP, mas o Fluig não sabe informar se uma despesa foi de fato paga: um erro como uma chave Pix incorreta só é descoberto quando o fornecedor liga ou manda um e-mail reclamando. A alçada de quem aprova o pagamento, assim como a de compra, nunca foi definida. A mudança pretendida calcula o vencimento automaticamente, somando a data de recebimento à condição de pagamento negociada na cotação (como 30 DDF ou DDE), em vez de deixá-lo digitado livremente; o próprio campo de vencimento deve migrar para uma etapa anterior no fluxo. O Fluig passaria a buscar no Consinco o status do pagamento, mostrando ao solicitante se e quando foi pago. Uma vez que a compra já tenha sido autorizada lá atrás, a ideia é que esta etapa vire apenas uma ratificação do recebimento, sem repetir um workflow de aprovação completo.

Pontos de atenção

Integração só de leitura: o ERP não recebe do Fluig

Hoje o Fluig consulta o Consinco (fornecedor, produto, centro de custo, saldo de orçamento) mas não insere dados. Requisição e reserva de orçamento são criadas manualmente no ERP; se o colaborador esquece, o orçamento não é reservado e o sistema sinaliza disponibilidade incorreta. Ligar a rota de inserção Fluig→Consinco é o maior desafio técnico do projeto.

Processo em transição - cuidado ao ler o AS-IS

Um fluxo Fluig novo está entrando em produção/homologação ao mesmo tempo em que o processo antigo (solicitação de pagamento) ainda roda. Parte do que se descreve como "hoje" já é o fluxo novo; parte ainda é o antigo. Confirmar o que de fato está em produção.

Reunião de projeto não é o processo vivido

O material vem de reuniões de desenho da solução, não de entrevistas de mapeamento. O AS-IS aparece em serviço do TO-BE - precisa ser validado diretamente com quem opera na ponta.

A cotação roda fora do sistema

A cotação hoje acontece numa ferramenta caseira criada pela própria área de Compras (~1.000 cotações/mês), fora do Fluig e do ERP. Trazer isso para dentro do fluxo é um objetivo, mas o cuidado é não perder a produtividade que a ferramenta já entrega.

O fluxo tem desvios que o diagrama linear não mostra

O diagrama acima é o caminho principal. Na prática há três ramificações, descritas nas etapas: cadastro de fornecedor não encontrado (já roda hoje, na cotação → área de Cadastro → ERP → volta), cadastro de item não encontrado (mesma lógica, ainda sendo desenhada, na solicitação) e emplaquetamento de item imobilizado (depois de executar a compra → Patrimônio coloca a plaqueta → volta). Envolvem duas áreas que não aparecem no caminho principal: Cadastro e Patrimônio.

Vocabulário do processo

Termos como a casa usa, no sentido em que aparecem neste documento.

Formalização

Compra que já aconteceu na prática e só depois entra no sistema, para registro e pagamento. Hoje é o caminho de cerca de 70% das compras.

Requisição

Pedido formal registrado no ERP antes da compra, que origina a reserva de orçamento. Hoje é criada manualmente e, na maioria dos casos, depois da compra feita.

Reserva de orçamento

Bloqueio de verba no Consinco vinculado à requisição, para garantir que a compra cabe no orçamento. Hoje é feita manualmente.

Natureza

Classificação orçamentária e contábil do gasto, usada no lançamento da nota. Hoje aplicada de forma inconsistente entre quem lança.

Cotação

Coleta de preços com fornecedores antes da compra. Hoje acontece fora do sistema (telefone, WhatsApp, e-mail), sem registro estruturado.

Central de Lançamento

Equipe responsável por digitar as notas fiscais no ERP. O lançamento é 100% manual, na casa de 5 minutos por nota, para as 36 lojas.

Emplaquetamento

Identificação física (plaqueta de patrimônio) de item de imobilizado no recebimento, exigida antes do pagamento quando a compra envolve ativo.

Consinco

ERP de gestão (TOTVS) usado pelas lojas. Hoje o Fluig apenas consulta o Consinco; nada é gravado automaticamente nele a partir do fluxo.

2 / 12

De onde vem e para onde vai

Cadeia do processo

Todo processo tem uma entrada, um processamento e uma saída - e nenhum vive isolado. As compras administrativas não começam nem terminam em si: nascem de uma necessidade na loja ou na área e terminam com a despesa paga e contabilizada. Este portal ilumina o meio da corrente; o que vem antes e o que vem depois ainda não foram mapeados. Aqui o foco é o encadeamento entre processos; o detalhe do que entra e sai por dentro das compras está no SIPOC, logo abaixo.

Antes · a mapear

Origem da necessidade (loja / área)

A demanda nasce na ponta: a loja ou a área identifica que precisa comprar. Hoje esse início é informal (a compra muitas vezes já aconteceu antes de entrar no sistema). A mapear como processo próprio.

entradanecessidade de compra da loja ou da área

Este processo · em diagnóstico

Compras e Registro de Despesas

Solicitação, cotação/negociação, aprovação, requisição/reserva de orçamento, execução da compra, recebimento, lançamento da nota e encaminhamento para pagamento.

saídadespesa registrada, paga e contabilizada

Depois · a mapear

Financeiro (execução do pagamento)

Executa o pagamento no ERP após o lançamento da nota. Não foi ouvido neste diagnóstico. A mapear.

Contabilidade (contabilização)

Contabiliza a despesa conforme a classificação. Depende do plano de contas, ainda não consultada. A mapear.

Mapear e automatizar só as compras é um bom começo, mas o ganho pleno vem de tratar a corrente inteira. O que vem antes (a origem da necessidade) e o que vem depois (Financeiro e Contabilidade) são os próximos processos a diagnosticar - cada um com o mesmo rigor deste, para que a automação não fique ilhada no meio.

Enquadramento do processo

SIPOC · o processo em uma folha

Este processo ainda não passou por um mapeamento dedicado que sustente um SIPOC de verdade. O que temos vem de reuniões de alinhamento do projeto, não de um levantamento próprio de fornecedores, entradas e clientes, por isso a moldura fica vazia em vez de preenchida com suposições.

Vazio honesto · aguardando mapeamento dedicado

Fornecedor

a mapear

Entrada

a mapear

Processo

a mapear

Saída

a mapear

Cliente

a mapear

O que falta para preencher esta seção

Uma rodada dedicada com quem opera para nomear os fornecedores reais (não só "o ERP"), precisar as entradas/gatilhos do processo, e identificar os clientes/consumidores concretos da saída (quem usa a despesa registrada, além de Controladoria e Financeiro em tese). Enquanto isso não acontece, preencher aqui seria inventar precisão que as reuniões de alinhamento não sustentam.

3 / 12

Responsabilidades

Matriz RACI · quem faz o quê em cada etapa

O R (Responsável) de cada etapa deriva do ator observado nas reuniões; A/C/I ficam a validar com o cliente, junto com o fluxograma de alçadas pendente na Controladoria.

Proposta · papéis derivados das reuniões, a validar com o cliente

Etapa	Solicitante	Compras	Controladoria	TI	Aprovador/Diretoria	Central de Lançamento	Financeiro
Registrar necessidade / solicitação	R
Cotar com fornecedores		R
Aprovar (alçada + orçamento)			C		A
Gerar requisição no ERP	R			C
Executar a compra / pedido ao fornecedor	C	R
Receber e conferir	R
Lançar a nota no ERP			C			R
Pagar							R

R Responsável (executa) A Aprova C Consultado I Informado

4 / 12

O que já emergiu do cruzamento

Achados ricos e dores recorrentes

Do cruzamento das entrevistas emergiram dores recorrentes e caminhos paralelos ao sistema. Os pontos confirmados por mais de uma voz já valem como achados; os de voz única ficam marcados como relato a confirmar.

Dor / gargalo

Lançamento de nota 100% manual em 36 lojas

Alta

A central de lançamento digita cada nota fiscal no Consinco à mão (~5 min/nota). Não escala com a abertura de lojas. É a dor que originou o projeto.

Confirmado por 3+ vozes

Controladoria · Compras · Gestão

Dor / gargalo

Compra sem requisição nem orçamento prévios (formalização)

Alta

Cerca de 70% das compras já foram feitas quando entram no sistema; o solicitante chega com a nota e pede o pagamento. A despesa vira ponto cego que estoura o orçamento.

Confirmado por 2+ vozes

Controladoria · Compras

Dor / gargalo

Reserva de orçamento feita manualmente no ERP

Alta

A requisição que reserva o orçamento é criada à mão no Consinco. Se o colaborador esquece, o orçamento não é reservado e o Fluig sinaliza saldo incorreto - compra fora do planejado.

Confirmado por 3+ vozes

Controladoria · TI · Diretoria

Dor / gargalo

Classificação de natureza inconsistente

Alta

Cada pessoa classifica a natureza da despesa de um jeito; o plano de contas "vira uma zona" e o histórico fica pouco confiável para montar orçamento.

Confirmado por 2+ vozes

Controladoria · Compras

Dor / gargalo

Recebimento sem conferência nota × pedido × físico

Alta

Não há conferência entre o que foi pedido, o que veio na nota e o que chegou. Caso citado: nota com preço diferente do pedido recebida sem validação.

Confirmado por 2+ vozes

Compras · Controladoria

Melhoria recente

Status de pagamento: de ponto cego a consulta ao Consinco

Baixa

Até pouco tempo, o Fluig não informava se a despesa foi paga (erros como chave Pix errada só apareciam quando o fornecedor reclamava). Recentemente passou a consultar o Consinco: verifica o campo que o Financeiro preenche ao pagar e retorna o status, finalizando o processo. Falta ainda a visão de quem paga (Financeiro não ouvido) para saber por que um pagamento falha.

Verbatim S7Corrigido em v0.4

Compras · Controladoria (S7)

Lacuna de controle

Alçadas de aprovação não definidas

Média

Hoje quase tudo cai na alçada do solicitante; as alçadas por valor (compra e pagamento) ainda não estão definidas. O fluxograma está pendente na Controladoria.

Confirmado por 2+ vozes

Diretoria · Controladoria · Praxis

Dor / gargalo

Cadastro roda no "Gestão X", fora do Fluig e desconectado do ERP

Alta

Cadastro de item e fornecedor não acontece no Fluig: é feito num sistema à parte, o Gestão X, que não se comunica com o ERP. Quem cadastra sai do Fluig, digita tudo no Gestão X e a devolutiva volta por lá, o que exige recopiar a informação para o ERP à mão. Cláudio (S7): o cadastro "é o coração, o pulmão, o intestino do processo", mas não está estruturado. É um processo sem dono e sem rito próprio.

Verbatim S7Novo em v0.4

Compras · Controladoria (S7)

5 / 12

Para fechar o retrato

O que falta e o caminho para os 100%

O diagnóstico aponta os próprios buracos. Abaixo, o que nenhuma versão preencheu ainda, o que fazer para fechar cada um, e com quem falar a seguir.

Lacunas e o que fazer

// gap → ação → o que sobe na nota

›

Operadores de linha de frente não ouvidos. As dores foram descritas pelas gerências. Falta ouvir quem executa: o solicitante de loja e a central de lançamento de notas. O que eles vivem pode diferir do que os donos do processo relatam.

→ O que fazer: Entrevista de mapeamento dedicada com o solicitante de loja e com a central de lançamento, focada no que executam, nas exceções e nos "jeitinhos" do dia a dia.

↑ Cobertura + Convergência

›

Contabilidade e Fiscal ainda não consultados. A classificação contábil definitiva e o plano de contas dependem de Contabilidade e Fiscal (citados como Aziel e Felipe), que não participaram das reuniões. É a base do "cadastro é a alma do negócio".

→ O que fazer: Sessão com Contabilidade e Fiscal para fechar plano de contas, regras de natureza e a amarração item→classificação.

↑ Cobertura

›

Financeiro (execução do pagamento) não ouvido. A ponta que efetua o pagamento e sabe por que um pagamento falha não foi ouvida. Sem ela, o retorno de status de pagamento fica incompleto.

→ O que fazer: Ouvir o Financeiro sobre execução do pagamento, causas de falha (ex.: Pix errado) e como o status volta ao processo.

↑ Cobertura

›

Alçadas reais indefinidas. O fluxograma de quem aprova o quê, por valor, está pendente na Controladoria. Sem ele, a aprovação real do processo não pode ser mapeada.

→ O que fazer: Obter da Controladoria o fluxograma de alçadas (compra e pagamento) por valor e amarrá-lo à etapa de aprovação.

↑ Consistência + Profundidade

›

O que está em produção vs. homologação. O fluxo Fluig novo convive com o processo antigo. Não está claro o que de fato roda em produção hoje e o que ainda é protótipo.

→ O que fazer: Levantar com a TI e Compras o que já roda em produção e o que ainda é homologação, para separar AS-IS de TO-BE com precisão.

↑ Consistência

›

Volumes por fluxo e por filial. Há o número global (~1.040 compras/mês) mas não a distribuição por fluxo (ADM, contrato, expansão…), por filial ou por natureza. Isso dimensiona onde investir.

→ O que fazer: Extrair do Consinco a distribuição de volume por fluxo, filial e natureza, para dimensionar esforço e priorizar.

↑ Profundidade

›

Quem cria a requisição no ERP não está confirmado. As reuniões não são unânimes se é o solicitante ou a área de Compras quem gera manualmente a requisição no Consinco. É um detalhe pequeno, mas necessário para desenhar a automação da etapa.

→ O que fazer: Confirmar com Compras e TI quem gera a requisição hoje no Consinco e em que momento.

↑ Consistência

›

O propósito da requisição é incerto até para o time (S7). Na S7, o próprio Cláudio confessa não entender para que serve a requisição. O time levanta duas hipóteses não resolvidas: (a) só provisionar/consumir o orçamento no ERP, ou (b) ser o elo que falta entre Fluig e Consinco (que não se comunicam direto), funcionando como número de pedido. Precisa ser questionado com quem desenhou a integração antes de automatizar.

→ O que fazer: Questionar com quem desenhou a integração Fluig↔Consinco o papel exato da requisição (só orçamento ou elo/ponte) antes de automatizar a etapa.

↑ Consistência + Profundidade

Com quem falar a seguir

// vozes que mudam a nota

Solicitante de loja / área Operação

Quem abre a necessidade na ponta. Dificuldade real de preencher, frequência da formalização, o que falta no sistema.

Central de lançamento de notas Operação

Quem digita a nota no ERP. Tipos de erro, tempo por nota, gargalos reais do trabalho manual.

Contabilidade Operação

Classificação contábil, plano de contas, o que torna a natureza inconsistente.

Fiscal Operação

Regras fiscais, retenção de imposto, conformidade da nota.

Financeiro Operação

Execução do pagamento, por que um pagamento falha, como o status volta ao processo.

6 / 12

O que já foi decidido

Decisões

O que já foi batido o martelo nas reuniões, com quem decidiu e quando. Diferente das Lacunas (o que ainda não sabemos) e do TO BE (o que se propõe): aqui fica o que o cliente decidiu, para o processo não andar em círculos a cada nova conversa.

DecididoS718 jul 2026

Classificação contábil/fiscal passa a ser feita no item, não no fornecedor

Cláudio Machado (Controladoria)

"As is fornecedor, to be item." Orçamento sai deste ponto: quem define é a Controladoria.

DecididoS718 jul 2026

Cadastro é um processo separado, não subprocesso de Compras

Cláudio Machado (Controladoria)

Qualquer área pode precisar cadastrar. Pode ser acionado a partir da cotação, mas vive por conta própria. Meta: sair do Gestão X para o Fluig.

DecididoS718 jul 2026

A etapa de cotação vira cotação + negociação (dois mapas)

Cláudio + Pedro (Compras)

Primeiro mapa mostra o melhor de cada atributo; o segundo consolida pós-negociação num vencedor.

DecididoS718 jul 2026

Orçamento não entra no escopo da classificação (já tem trava)

Cláudio Machado (Controladoria)

A trava orçamentária já foi definida com a controladoria; retirado do slide para não confundir escopo.

Em abertoS718 jul 2026

Propósito da requisição precisa ser questionado antes de automatizar

Cláudio Machado (Controladoria)

Não decidido: falta confirmar com quem desenhou a integração se a requisição só provisiona orçamento ou se é o elo Fluig-Consinco.

7 / 12

Mensuração do processo

Métricas propostas

Métricas candidatas, derivadas das dores que o diagnóstico revelou. Nenhuma está medida ainda: a instrumentação entra como entrega do mapeamento dedicado. Os dois painéis do topo trazem o único número real disponível hoje, o andamento do próprio trabalho.

Andamento

Confiabilidade do AS IS

Nota atual do mapeamento.

Andamento

Automação (TO BE)

Redesenho automatizado ainda não iniciado.

Indicadores propostos · a instrumentar

% de compras que entram como formalização

% · ↓ quanto menor, melhor

aguardando dados

Hoje ~70% (relato). Meta: reduzir com a cultura de requisição antes da compra.

Assertividade da classificação de natureza

% · ↑ quanto maior, melhor

aguardando dados

Hoje ~80% (relato); meta citada ~95% com amarração item→natureza.

Tempo de lançamento manual de nota

min/nota · ↓ quanto menor, melhor

aguardando dados

~5 min/nota × 36 lojas (relato). Alvo de automação por leitura de XML/DANFE.

Taxa de reserva de orçamento efetivada

% · ↑ quanto maior, melhor

aguardando dados

Requisição criada / compras aprovadas. Hoje manual e sujeita a esquecimento.

Tempo médio de ciclo (necessidade → pagamento)

dias · ↓ quanto menor, melhor

aguardando dados

Ciclo real desconhecido; a integração manual torna o dado opaco.

8 / 12

Redesenho do processo

TO BE · o processo que o projeto está construindo

O projeto "Gestão e Registro das Despesas" redesenha este processo, e boa parte do desenho já foi discutida nas 6 reuniões. Este TO-BE não é uma proposta abstrata: é o que está sendo construído no Fluig hoje. Ele está em movimentação (ainda não virou o novo AS-IS) e depende de decisões técnicas e de negócio que continuam abertas. Abaixo, as transformações desenhadas e as tensões que ainda precisam ser resolvidas.

Em movimentação · desenho ativo, ainda não aprovado como novo AS IS

As transformações desenhadas

Requisição antes da compra

Inverter a cultura de "já comprei, pague" para "quero comprar": a solicitação e a reserva de orçamento passam a acontecer ANTES da nota, atacando os ~70% de compras que hoje entram como formalização.

Reserva de orçamento automática (Fluig → Consinco)

Ao aprovar, empenhar o orçamento no ERP automaticamente, eliminando a criação manual da requisição. Depende da rota de inserção que hoje não existe; a TI propôs um MVP em que o Fluig consulta se a requisição existe e bloqueia o avanço se não.

Classificação contábil/fiscal: do fornecedor para o item

Decisão da S7 (Cláudio): hoje a classificação contábil e fiscal é feita em cima do fornecedor; passa a ser feita em cima do item ("as is fornecedor, to be item"). Vincular a natureza ao item sobe a assertividade de ~80% para ~95% e tira a Controladoria da validação manual. Orçamento sai deste slide: quem define orçamento é a Controladoria (Tiago), não o contábil/fiscal.

Cotação + negociação (dois mapas)

Refinado na S7: o comprador não quer só cotar, quer negociar. Primeiro mapa mostra o melhor de cada atributo (preço, prazo, condição de pagamento) entre os fornecedores; o segundo, pós-negociação, consolida as melhores condições num vencedor. A etapa deixa de ser "cotação" e passa a ser "cotação/negociação".

Cadastro como processo próprio (fora de Compras)

Decisão da S7: cadastro de item e fornecedor não é subprocesso de Compras, é um processo separado, disponível a quem tiver permissão (qualquer área pode precisar cadastrar, não só compras). Pode ser acionado como subprocesso a partir da cotação quando faltar um fornecedor, mas o processo principal vive por conta própria. Meta: tirar o cadastro do Gestão X e trazê-lo para o Fluig, integrado ao ERP.

Alçadas de aprovação por valor

Definir as alçadas de compra e de pagamento (hoje quase tudo cai na alçada do solicitante). Despesa com contrato ativo tem alçada menor; despesa fora da norma vai sempre ao diretor financeiro. Fluxograma sob responsabilidade da Controladoria.

Cotação dentro do Fluig

Trazer a ferramenta caseira de Compras (e-mail automático, link externo, mapa comparativo, menor preço destacado) para dentro do fluxo, com o frete compondo o valor da cotação e a forma de pagamento pré-cadastrada. Cuidado para não perder a produtividade que a ferramenta já entrega.

Recebimento com conferência

Validar nota × pedido × físico, com recebimento cego (quantidade e valor conferidos contra a nota) e sinalização de parcial, com ressalvas, imobilizado ou não recebido, registrando data real e responsável.

Lançamento da NF automatizado

Leitura automática do XML/DANFE por leitor ou coletor, eliminando a digitação manual (~5 min/nota × 36 lojas). A central de lançamento passa a fazer gestão de contratos e monitoria.

Vencimento calculado e status de pagamento de volta

O vencimento deixa de ser digitado e passa a ser calculado (data de recebimento + condição negociada, DDF/DDE). E o Fluig passa a buscar no Consinco se a despesa foi paga, mostrando o status ao solicitante.

Desmembramento de pedidos

Uma única solicitação poder virar vários pedidos, um por fornecedor vencedor, cada um com sua própria requisição, e o lançamento aceitar as múltiplas notas correspondentes.

Cadastro robusto de item e fornecedor

Formalizar os desvios de cadastro (hoje o de fornecedor já roda; o de item está sendo construído), com um workflow que passe por Contabilidade e Fiscal para garantir a consistência do plano de contas, "cadastro é a alma do negócio".

Tensões em aberto · decisões ainda não tomadas

Direção da integração

Fluig como orquestrador do Consinco (visão da Praxis, preserva rastreabilidade) vs. todo o trâmite entrar pelo Fluig e virar pedido diretamente no ERP (visão da gestão do cliente). Adiado para a 2ª onda.

Customizar vs. comprar

Seguir customizando o Fluig ou adquirir uma ferramenta de compras de mercado e integrá-la ao Consinco. Levantado pela gestão, reconhecido como pertinente, em aberto.

Autonomia do solicitante

Se a regra contra escolher item mais caro / comprar antes da requisição será uma norma rígida ou um controle por indicadores. A Praxis defende coletar indicadores antes de engessar; a Controladoria quer regra firme.

O que é item imobilizado

A definição precisa do que conta como imobilizado (e portanto vai ao emplacamento) ainda será fechada pela Controladoria.

9 / 12

A régua que torna o diagnóstico honesto

O quanto você pode confiar neste retrato

Ponto de partida honesto, e ainda modesto. Este retrato NÃO vem de um mapeamento de processos dedicado: nunca houve, para este processo, uma rodada de entrevistas específica para levantá-lo. O entendimento aqui foi construído de 6 reuniões de ALINHAMENTO do projeto (dez/2025 a jul/2026), cujo objetivo era desenhar a solução no Fluig, não mapear o processo - então o AS-IS aparece de passagem, em serviço do TO-BE. Duas escolhas de honestidade: (1) o código do Fluig (o form DD_ComprasADM) foi deliberadamente excluído como fonte deste AS-IS - ele é o sistema em construção, mais próximo do TO-BE do que do processo vivido hoje, e por isso alimenta as camadas de Automatização e TO-BE, não esta; (2) as vozes ouvidas são as de quem RESPONDE pelo processo (gerências, TI, diretoria), não as de quem opera na ponta. Resultado: Preliminar (38). Serve para orientar, não para decidir. A nota pode subir muito - provavelmente para a faixa de Consolidado - quando for feito um mapeamento dedicado com os operadores.

Preliminar

Convergência peso 35%

40 / 100

Alguns fatos aparecem em 2+ vozes (lançamento manual, compra sem requisição, reserva de orçamento manual). Mas o cruzamento é entre gestores que RESPONDEM pelo processo, não entre operadores; e as reuniões eram de alinhamento do projeto, então o AS-IS foi descrito de passagem, não levantado de forma dedicada.

Cobertura peso 30%

30 / 100

Ouvidos: Compras, Controladoria, TI, Diretoria e Gestão - mas como participantes de reuniões de projeto, não de um mapeamento. Faltam os operadores da ponta (solicitante de loja, central de lançamento) e as áreas de Contabilidade, Fiscal e Financeiro.

Consistência peso 20%

62 / 100

As 6 reuniões contam uma história coerente. As tensões são de desenho da solução (direção da integração), não contradições sobre o processo de hoje.

Profundidade peso 15%

58 / 100

As reuniões trazem números e regras concretas (~1.040 compras/mês, 36 lojas, ~5 min/nota, alçadas, naturezas). Mas sem um mapeamento dedicado, falta o detalhe do vivido na ponta (exceções, jeitinhos, tempos reais).

Como a nota é composta · score da dimensão × peso

Convergência40 × 35%14,00

Cobertura30 × 30%9,00

Consistência62 × 20%12,40

Profundidade58 × 15%8,70

Índice de confiabilidadesoma14,00 + 9,00 + 12,40 + 8,70 → 44

⬡ O que falta para subir de nível

Fazer um mapeamento de processos dedicado: entrevistas específicas com os operadores da ponta - solicitante de loja, central de lançamento de notas - e com Contabilidade, Fiscal e Financeiro. É o que ainda não aconteceu; é o que mais move a nota. Reuniões de alinhamento do projeto não substituem esse levantamento.

0–39

Preliminar

Versão de poucos. Serve para orientar, não para decidir.

você está aqui

40–69

Em consolidação

Várias vozes cruzadas. Convergências confiáveis aparecem.

70–100

Consolidado

Retrato firme. Base sólida para redesenhar o processo.

10 / 12

Como a Praxis trabalha

O método por trás deste documento

Não mapeamos por opinião. Cruzamos versões de quem vive o processo, medimos a confiabilidade do que encontramos e só damos como verdade o que mais de uma voz confirma.

01

Entrevistas de campo

Ouvimos cada pessoa que toca o processo, na linguagem dela. A ferramenta de entrevista guiada extrai casos reais, não respostas genéricas.

02

Cruzamento de versões

Nenhuma entrevista isolada é a verdade do processo. A verdade emerge quando as versões se confirmam ou se contradizem.

03

Nota de confiabilidade

Medimos o quanto o retrato pode ser usado para decidir. Poucos respondentes, nota baixa. Sem maquiagem.

04

Redesenho (TO BE)

Com o retrato consolidado, desenhamos o processo melhor: mais rápido, rastreável e ligado aos objetivos da organização.

Registro de fontes · rastreabilidade

Cada informação deste retrato vem de uma entrevista. Abaixo, todas as sessões, identificadas por função e modalidade de coleta; a identificação nominal fica no registro interno da Praxis. Documentos de apoio produzidos pela Praxis a partir das entrevistas não contam como fonte independente.

Controladoria (gerência)

Dona do processo; orçamento, classificação, aprovação