“O IBP está lento.” É a frase que abre metade das reuniões de acompanhamento de uma implantação. Quase sempre ela está errada — não porque o sistema seja rápido, mas porque “o IBP” não é um lugar só. Entre o planejador apertar Refresh e o número aparecer na célula, o tempo se reparte em quatro camadas. Três delas ficam do lado de cá, na máquina e no desenho da planning view, e não dependem de chamado nem de release.
Primeiro meça, depois opine
Não se otimiza o que ninguém cronometrou. “Lento” não é um número, e a percepção do planejador mistura o tempo do refresh com o tempo de abrir o Excel, o tempo do logon e o tempo que ele levou para achar a aba certa.
A SAP publica um repositório de amostras em VBA para as APIs de planning view. Com elas você instrumenta a própria pasta de trabalho e registra o Time Elapsed de cada Refresh, Simulate, Run Forecast e Save. O pré-requisito é o parâmetro global EXCEL_PLANNING_VIEW_APIS habilitado com ao menos acesso de leitura. Quando o caso vira chamado, a KBA 2477564 descreve como gerar os logs e traces — inclusive os de performance — dentro do próprio add-in.
Uma semana de medição por planejador, antes de mexer em qualquer coisa. Você quase sempre descobre que “lento” é uma view específica, num horário específico, para dois planejadores.
Camada 1 — o Excel da máquina do planejador
É a camada mais barata de resolver e a mais ignorada, porque não parece assunto de planejamento. A SAP é explícita: a versão 64 bits do Microsoft Excel não tem limite de memória, e o erro “reached the memory limit of the local computer” vem de Excel 32 bits ou da memória da própria máquina. A mesma nota lista os paliativos do 32 bits — fechar pastas de trabalho abertas, sair e entrar de novo para reduzir o consumo, e habilitar o Large Address Aware descrito pela Microsoft na KB 3160741.
Paliativos são paliativos. Se a TI ainda distribui Excel 32 bits para quem planeja, migrar esse grupo para 64 bits costuma render mais do que três semanas redesenhando planning view — e é uma decisão de licenciamento e imagem de máquina, não de projeto.
Camada 2 — o logon
Se a demora é ao entrar, e não ao atualizar, o problema não está na view. Dois parâmetros globais explicam a maior parte desses casos:
MAX_DIM_MEMBERS controla quantos membros de dimensão são carregados no logon; reduzi-lo faz o add-in trazer menos dado logo de início. PV_COUNT_MAX limita quantas pastas de trabalho com planning view podem ficar abertas ao mesmo tempo — e é o parâmetro que resolve o planejador que deixa seis arquivos abertos desde segunda-feira.
São parâmetros de sistema. Mexer neles é decisão de administração, com teste e janela, não ajuste individual. Mas o sintoma — “demora horrores para abrir, depois vai bem” — aponta para cá e não para o desenho da view. Separar os dois sintomas antes de agir economiza o ciclo inteiro.
Camada 3 — o tamanho da planning view
Aqui está o grosso do tempo, e aqui a conta é honesta: o custo de um refresh acompanha o número de células pedidas, e o número de células é o produto de três coisas — as combinações de atributos nas linhas, os períodos nas colunas e as key figures. São três multiplicadores, não três somas. Cortar 30% de cada um não tira 30% do tempo; tira quase dois terços.
Atributos nas linhas. Uma view desenhada em produto × cliente × local, quando a decisão da reunião é tomada em família × região, está pedindo dez vezes mais linhas do que a reunião usa. Isso não se corrige com filtro: corrige-se com desenho. O nível da view tem de ser o nível em que alguém decide alguma coisa.
Períodos. O horizonte da view deve ser o horizonte da decisão. Trinta e seis meses numa view de ajuste semanal é dado que ninguém lê e todo mundo espera.
Key figures. É a coluna mais fácil de cortar e a que ninguém corta, porque cada uma foi pedida por alguém em algum momento. Key figure que se olha uma vez por trimestre não pertence à view do ciclo mensal — pertence a uma view de análise, separada, que roda quando for preciso.
E uma distinção que muda o resultado: filtrar antes não é a mesma coisa que filtrar depois. O filtro do add-in reduz o que é pedido ao servidor. Esconder linha no Excel depois não reduz nada — o dado já veio, já foi trafegado e já foi pago em segundos.
Camada 4 — os favoritos de cada um
Quando cada planejador monta o próprio favorito, você não tem uma view lenta: tem trinta. E ninguém otimiza trinta. Um conjunto pequeno de views padrão, com dono e com nome, é o que torna o ajuste possível — e, de quebra, é o que faz a reunião de ciclo discutir o mesmo número em vez de três versões dele.
A SAP mantém um repositório público de templates de planning view como ponto de partida. Vêm explicitamente “not meant for production use”, mas servem de referência de estrutura, e a Note 1790530 trata do desenvolvimento e das restrições de template. Três limitações documentadas que poupam uma tarde de diagnóstico: gráfico em template de fórmula enxerga no máximo 300 linhas e funciona só em inglês; a pasta precisa entrar em Trusted Locations do Excel; e copiar uma aba de planning view com o copiar/mover nativo do Excel não funciona — copia-se a aba vazia do template.
Quando otimizar é a resposta errada
Se a view precisa ser gigante para a reunião funcionar, o problema não é o add-in: é o nível de planejamento. Uma Revisão de Demanda que só fecha olhando SKU × cliente não está decidindo, está conferindo. Decisão de ciclo mensal se toma em família e em valor; conferência de item se faz no S&OE, na semana, com a view pequena que aquele caso exige.
O add-in é o termômetro. Quando ele acusa febre toda segunda-feira de manhã, o problema raramente é o termômetro.
Vinte minutos, nesta ordem
- Cronometre. Sem número, o resto é palpite.
- Descubra se o Excel do planejador é 32 ou 64 bits. Se for 32, pare aqui e resolva isso primeiro.
- Separe demora de logon de demora de refresh. São camadas diferentes com donos diferentes.
- Conte as células da view mais reclamada: linhas × períodos × key figures.
- Corte as key figures que ninguém usa naquela reunião. É o corte mais rápido.
- Encurte o horizonte até o horizonte da decisão.
- Conte quantos favoritos diferentes existem para a mesma reunião. Se forem mais de três, o problema virou de governança.
Fontes
SAP KBA 3517319 — limite de memória do computador local, 32/64 bits, MAX_DIM_MEMBERS e PV_COUNT_MAX. · SAP KBA 3550712 — lentidão no logon. · SAP KBA 2477564 — geração de logs e traces de performance. · SAP-samples: templates de planning view — limitações e Notes 1790530 e 2135948. · Microsoft KB 3160741 — Large Address Aware para Excel 32 bits. As recomendações de desenho de view, nível de planejamento e governança de favoritos são leitura da MRP-N sobre projetos de implantação, não documentação SAP.
Ver o método completo → · SAP IBP na MRP-N
Michel Nachbar, CSCP
Michel Nachbar, CSCP. 27 anos em supply chain, implantando S&OP e SAP IBP na indústria brasileira. Traduz cada release em decisão de planejamento.
Assine a IBP na prática →