Uma fábrica de produção sob encomenda gera um perfil de dados particular, diferente do de uma operação comercial. Entender esse perfil ajuda a estimar o benefício antes de investir.
O volume não vem do número de pedidos, que costuma ser modesto. Vem da granularidade do registro: cada ordem tem várias operações, cada operação gera eventos de início, fim e parada, e cada evento carrega recurso, pessoa e resultado. Uma carteira de poucas centenas de ordens abertas produz um número de eventos bem maior do que a intuição sugere.
Esse perfil favorece exatamente o desenho colunar, porque as consultas úteis agregam poucos campos sobre muitos eventos. Somar horas por centro de trabalho, calcular ocupação por período ou acumular custo por ordem são operações que leem poucas colunas e muitas linhas.
O efeito sobre a rotina de fechamento
Há um ganho pouco discutido no fechamento contábil. Quando a apuração de custo depende de processamento em lote, ela concorre com a operação e costuma ser executada fora do horário comercial.
Com cálculo na camada de banco e base única, a apuração deixa de ser um evento e passa a ser uma consulta. O fechamento continua existindo como rito contábil, sem ser o momento em que a empresa descobre o que aconteceu, o que altera a relação entre a contabilidade e a apuração de custo por ordem.
O que o SAP HANA não resolve
Esta seção existe porque a expectativa errada aqui é cara e frequente. Um banco mais rápido acelera as perguntas que já existem, sem criar capacidade de negócio.
Processo industrial é camada de aplicação
A lógica de planejamento, sequenciamento, apontamento e custeio industrial vive na aplicação. Se o sistema não sequencia com capacidade finita, trocar o banco não passa a sequenciar.
Problemas de processo se resolvem na camada de aplicação, o que em produção não seriada costuma significar um add-on de manufatura. O sequenciamento por capacidade finita é função de aplicação, não de banco.
Banco não é modelo de hospedagem
Adotar o SAP HANA e migrar para nuvem são decisões independentes. HANA é arquitetura de banco de dados, nuvem é modelo de hospedagem.
É possível operar o HANA em infraestrutura própria e é possível manter um banco tradicional em nuvem. Tratar as duas decisões como uma só costuma produzir comparação de custo mal formulada.
Quando migrar para HANA faz sentido
Três critérios objetivos ajudam a decidir, e nenhum deles é a reputação da tecnologia. Eles valem tanto para metal-mecânica quanto para os demais segmentos discretos.
- Volume transacional gerado pela operação, sobretudo por apontamento e movimentação de estoque.
- Dependência de análise sobre dado corrente, e não sobre o fechamento do dia anterior.
- Capacidade de sustentação do ambiente, própria ou pelo parceiro de implementação.
Revisar os relatórios antes de migrar
Existe um cuidado que raramente entra no projeto e que evita frustração. Muitos relatórios existentes foram desenhados para contornar a lentidão do banco anterior.
Eles agregam previamente, limitam períodos e escondem detalhe justamente para conseguir responder em tempo aceitável. Migrados sem revisão, continuam entregando a mesma resposta limitada, e a empresa conclui que a mudança não trouxe nada.
A mudança mais visível é quem consegue perguntar. Quando a consulta deixa de exigir pré-cálculo e desenvolvimento, a pergunta sai da fila da equipe de tecnologia.
O gerente de produção passa a olhar ocupação por centro de trabalho sem pedir relatório. O controller consulta o custo acumulado de ordens abertas, e não apenas o das encerradas. O efeito sobre o controle de ordem de produção é de acesso, mais do que de velocidade.
