Times de planejamento já produzem algum tipo de previsão. O problema raramente é a ausência de um número: é o número não entrar no processo de verdade — no S&OP, no pedido, no estoque — porque a ferramenta não cabe no stack, no ritmo do time ou nas regras de segurança da empresa.
Uma aplicação que obriga todo mundo a abandonar o ERP não entra. Um modelo que vive só no notebook de um cientista de dados também não entra. O que entra é um motor de previsão que pode se encaixar de três jeitos, sem mudar a lógica que gera o resultado.
O QR Demand Planning foi desenhado assim: o mesmo motor, três formas de adoção, e duas opções de onde ele roda.
Mesmo motor, três encaixes
Toda operação de demand planning convive com a mesma tensão. De um lado, o time de negócio precisa de uma interface que dê para usar no ciclo: enviar dados, configurar o horizonte, acionar o modelo e olhar o resultado com calma o bastante para questioná-lo. De outro, o time de dados já tem plataforma, pipelines e governança — e não quer um silo novo. No meio, há empresas que já extraem venda do ERP ou do data warehouse toda noite e não deveriam voltar a copiar planilha.
Por isso a adoção não é um produto “tamanho único”. É um motor com três portas.
Aplicação web
UI executiva: upload, configuração, execução e visualização dos resultados.
Só o modelo
Motor robusto e agnóstico, plugado na plataforma de dados que você já tem.
App + integração
A mesma aplicação, com o histórico de vendas chegando por integração — não por planilha.
A escolha certa depende menos de preferência estética e mais de três fatos: onde o histórico de vendas mora hoje, quem é dono do ciclo de planejamento, e com que cadência a previsão precisa ser atualizada.
1. A aplicação web: UI executiva, do upload ao resultado
Este é o caminho mais direto — o site que você está vendo, usado como aplicação. Ele combina uma interface executiva, feita para quem decide, com o controle técnico de quem precisa defender o número.
Não é um laboratório escondido atrás de um notebook. É um fluxo guiado: o time envia o histórico, configura o recorte da previsão, aciona o modelo e lê o resultado no mesmo lugar. Planejadores operam sem um projeto de engenharia de dados. Quem quiser ir mais fundo ainda vê modelos candidatos, parâmetros e métricas por trás de cada série.
Aplicação web
O valor deste modo não é “ter uma tela”. É reduzir o custo de usar a previsão no ciclo real. Quando o upload, a configuração e a leitura do resultado cabem em uma UI que o time de planejamento entende, o modelo deixa de ser um exercício e passa a ser um insumo de decisão.
- 01
Upload
O histórico de vendas entra no formato que o time já mantém — planilha ou CSV — sem reescrever o schema da empresa.
- 02
Configuração
Horizonte, granularidade, modelos candidatos e regras de avaliação são definidos antes da execução, não depois.
- 03
Acionamento
O motor roda como um job rastreável: a mesma entrada, com os mesmos parâmetros, produz o mesmo tipo de artefato.
- 04
Resultados
A previsão aparece para ser lida, comparada e exportada — pronta para o S&OP, o pedido ou a ferramenta de planejamento.
Este modo é o encaixe certo quando o time de planejamento precisa começar sem esperar a plataforma de dados, quando o histórico ainda vive em arquivos, ou quando a prioridade é um ciclo curto até a primeira previsão defensável.
2. Só o modelo: um motor robusto na plataforma que você já tem
Há empresas em que a UI não é o gargalo. O gargalo é outro: o dado já está no lakehouse ou no warehouse, os pipelines já correm, e o time de dados não vai copiar história para uma ferramenta de fora a cada ciclo.
Nesses casos, o QR Demand Planning pode ser usado apenas como modelo. O motor é desacoplado da interface: ele recebe um contrato de entrada — série histórica e especificação da corrida — executa como job, e devolve artefatos versionados. A plataforma de dados continua sendo a fonte da verdade. O modelo entra como peça, não como silo.
Modelo agnóstico
Agnóstico, aqui, quer dizer isto: o motor não exige que a empresa troque de warehouse, de orquestrador ou de ferramenta de BI. Ele se pluga no que já existe, desde que o contrato de entrada e saída esteja claro. A mesma família de modelos — estatísticos e de gradient boosting, avaliados por série — continua responsável pelo número.
- 01
Contrato de entrada
A plataforma publica o histórico e a especificação da corrida no storage que o motor já sabe ler.
- 02
Job do motor
A execução acontece como carga isolada, com os mesmos parâmetros que a aplicação web usaria.
- 03
Artefatos de saída
Previsão, métricas e trilha da corrida voltam para a plataforma — prontos para o BI, o planejamento ou o próximo pipeline.
- 04
Governança nativa
Catálogo, permissão e linhagem continuam onde a empresa já os definiu. O modelo não inventa um segundo perímetro.
3. A aplicação, com vendas por integração — não por planilha
Há um terceiro encaixe, no meio dos dois anteriores. O time de planejamento continua na aplicação web: configura, aciona, lê e exporta. Mas o histórico de vendas não entra por upload. Ele chega por integração — do ERP, do data warehouse, ou de uma API já operada pela TI.
Planilha funciona para começar. Ela falha quando vira operação: versões divergem, colunas mudam de nome, alguém envia o arquivo da semana passada, e o ciclo inteiro herda o erro. Integração não é luxo de arquitetura. É o jeito de o dado de venda chegar com a mesma cadência com que a empresa já fecha o dia.
App + integração
A UI executiva permanece. O que desaparece é o gesto operacional de exportar, anexar e torcer para o arquivo estar certo. A aplicação passa a receber o histórico de forma contínua, e o modelo vê a mesma verdade que o restante da operação.
- 01
Origem
ERP, warehouse ou API de vendas publica o histórico no recorte combinado com a TI.
- 02
Ingestão
A aplicação recebe o dado autenticado — sem upload manual no browser.
- 03
Ciclo de planejamento
O time configura, aciona e lê o resultado como no modo web. A diferença está na entrada, não na decisão.
- 04
Retorno
A previsão volta para as ferramentas de planejamento por exportação ou integração de saída.
Este modo é o encaixe certo quando o planejamento quer continuar dono da interface, mas a TI não aceita planilha como contrato de dado — ou quando a cadência da previsão precisa acompanhar o fechamento de vendas, não o próximo e-mail com anexo.
Como escolher
Os três modos não são degraus obrigatórios. São respostas a contextos diferentes. Muitas empresas começam pela aplicação web, porque ela produz a primeira previsão defensável sem esperar o conector perfeito. Outras já têm plataforma madura e entram pelo modelo. Outras ainda têm S&OP forte e dado operacional confiável: aí a aplicação com integração é o caminho mais curto até um ciclo estável.
| Modo | Como o dado chega | Quem opera | Cadência típica |
|---|---|---|---|
| Aplicação web | Upload de planilha ou CSV | Planejamento | Por ciclo de S&OP |
| Só o modelo | Plataforma de dados existente | Dados / engenharia | Pipeline agendado |
| App + integração | ERP, DW ou API de vendas | Planejamento, com TI na origem | Contínua ou por fechamento |
O critério útil não é “qual modo é mais moderno”. É qual modo reduz o ponto em que a previsão é abandonada: se o time não consegue operar a ferramenta, se o dado chega errado, ou se a TI bloqueia o perímetro.
Onde implantar: cloud da empresa ou cloud da QR
Independente do modo, a carga precisa morar em algum lugar. Há duas respostas, e a escolha é de política — residência, rede, operação — não de capacidade do motor.
Operado por nós
Cloud da QR
A aplicação e o motor rodam na infraestrutura da QuantumRise. A empresa acessa o serviço, envia ou integra o dado, e opera o ciclo sem provisionar cluster, fila ou storage. É o caminho mais curto quando a prioridade é tempo até a primeira corrida, e quando a política de dados admite um processamento em ambiente gerenciado, com isolamento por organização.
Cloud ou on-premise
Cloud da empresa
A mesma aplicação e o mesmo motor são implantados no perímetro da empresa — em cloud própria ou em infraestrutura on-premise. O dado não precisa sair do ambiente que a TI já governa. Este é o caminho quando há requisito de residência, de rede privada, ou de operação sob o controle direto do time de infraestrutura.
Segurança, governança e auditoria — nos dois cenários
Um lead de TI pergunta, com razão, o que acontece com o histórico de vendas. A resposta precisa valer tanto na cloud da QR quanto na cloud da empresa, e tanto no upload quanto na integração.
O dado de negócio é isolado por organização. Ele é criptografado em trânsito e em repouso. Não é usado para treinar modelo de outro cliente. Acesso segue identidade, papel e o recorte da organização — não um compartilhamento implícito entre tenants.
Governança, aqui, não é um selo genérico. É a capacidade de dizer, para cada previsão: de onde veio o input, com quais parâmetros a corrida foi acionada, qual modelo venceu por série, e quais métricas de erro acompanham o número. Sem isso, o forecast não sobrevive à primeira reunião em que alguém discorda.
Acesso
Identidade, sessão e permissão por organização. Quem opera o ciclo vê o recorte que lhe cabe — não o dado de outra empresa, nem o de outro time sem autorização.
Isolamento
Histórico, corridas e artefatos ficam no escopo da organização. O motor processa para produzir a previsão daquele tenant; não mistura painéis nem treina um cliente com o outro.
Criptografia
Em trânsito e em repouso, no caminho do upload, da integração e dos artefatos de saída — na cloud da QR e na cloud da empresa.
Trilha de execução
Entradas versionadas, parâmetros registrados, métricas persistidas. A previsão pode ser reproduzida e questionada; não é um número que aparece sem origem.
Auditoria, no sentido útil para planejamento, é essa trilha: quem acionou, o que entrou, o que saiu, e com qual erro histórico o número se apresenta. É o que permite ao time comercial discordar com evidência, em vez de substituir o modelo por feeling na última reunião do ciclo.
O próximo passo não é escolher um logo de cloud
É desenhar o encaixe. Qual modo reduz o atrito do seu time. Qual perímetro a TI aceita. Qual cadência o S&OP realmente usa. O motor é o mesmo; a implantação é o que faz ele entrar.