A pressão para virar uma organização guiada por dados quase sempre chega antes da estrutura para sustentá-la. O roteiro se repete: a diretoria quer indicadores atualizados, a TI está sobrecarregada, e alguém aponta o Power BI direto para o banco de produção do sistema de gestão hospitalar.
No primeiro dia parece uma vitória. Os painéis carregam, os números são os reais, ninguém precisou montar projeto de dados. Semanas depois, o setor de atendimento começa a reclamar que o sistema “está pesado de manhã”. A TI investiga, não encontra nada de errado no servidor, e a queixa vira ruído de fundo até o dia em que a recepção do pronto atendimento simplesmente para.
O que está acontecendo por baixo
O banco transacional não travou. Ele está fazendo exatamente o que foi mandado fazer — e é justamente esse o problema.
Sistemas de gestão são dimensionados para um perfil de carga muito específico: milhares de operações pequenas, rápidas e cirúrgicas. Ler o cadastro de um paciente. Gravar uma prescrição. Atualizar o saldo de um item. Cada uma toca poucas linhas, usa índices e devolve resposta em milissegundos. O ambiente inteiro — memória, disco, dimensionamento de servidor — foi calibrado em cima desse perfil.
A consulta analítica tem o perfil exatamente oposto. Um indicador aparentemente simples, como taxa de ocupação por unidade nos últimos doze meses, vira uma consulta com dezenas de junções varrendo milhões de linhas históricas. E como operação e análise dividem o mesmo servidor, o mesmo disco e a mesma memória, essa varredura cobra o preço em quatro frentes ao mesmo tempo:
- Saturação de I/O e CPU. A leitura massiva de dados históricos disputa disco e processamento diretamente com as transações do atendimento. Não existe fila preferencial para quem está com o paciente na frente.
- Poluição da memória de cache. Os dados que a operação acessa o tempo todo — agenda, prescrição, censo — são expulsos da memória para dar lugar a dados históricos que ninguém mais vai ler. A partir daí, cada tela do sistema volta a buscar informação em disco, que é ordens de grandeza mais lento.
- Consumo de memória de trabalho e área temporária. Ordenações e agrupamentos em grande volume estouram a memória disponível e derramam para a área temporária, compartilhada com todos os outros usuários.
- Ocupação dos recursos de processamento paralelo. Uma única consulta analítica pode tomar a capacidade que rotinas legítimas de fechamento, faturamento ou integração precisariam usar no mesmo horário.
O sintoma, do ponto de vista de quem está na ponta, não é uma mensagem de erro. É a tela que respondia em duzentos milissegundos passando a responder em oito segundos. Multiplicado por cada atendimento do turno, isso é fila na recepção e médico esperando o sistema abrir. E quando a consulta se arrasta demais, é comum que ela própria termine em erro ou timeout — depois de já ter degradado o ambiente inteiro no caminho.
O resultado é o pior dos dois mundos: a operação sofre e o relatório nem sempre chega.
A arquitetura correta
A saída é conhecida há décadas e não tem mistério conceitual: separar o operacional do analítico.
Bancos transacionais são projetados para operações unitárias rápidas sobre estruturas altamente normalizadas. Ambientes analíticos são projetados para varreduras amplas sobre estruturas desnormalizadas. Pedir que o mesmo banco faça as duas coisas é pedir que ele seja bom em objetivos que se contradizem.
A arquitetura saudável tem três camadas:
- Replicação e ingestão Em vez de consultar a produção ao vivo, uma esteira extrai os dados de forma programada e leve, respeitando janelas de baixo movimento ou trabalhando sobre réplicas de leitura.
- Repositório analítico isolado Os dados chegam a um ambiente dedicado exclusivamente à análise, onde nenhuma consulta pesada disputa recurso com o atendimento.
- Modelagem dimensional A complexidade de dezenas de tabelas do sistema de origem é reorganizada em fatos e dimensões. O que exigia quinze junções passa a ser uma leitura direta, e o painel que demorava minutos responde em segundos.
Com essa estrutura, o BI atualiza rápido e a operação sequer percebe que o processo aconteceu.
Por que tantos projetos assim não saem do papel
O conceito é simples. A execução é onde a maioria trava.
Construir pipelines confiáveis, tratar as inconsistências do sistema de origem, modelar as áreas de negócio e manter tudo isso funcionando exige engenharia de dados dedicada. Feito internamente, o trabalho cai sobre a mesma equipe que já sustenta a operação do dia a dia — e perde para a operação toda vez que houver conflito de prioridade. Projetos assim se arrastam por meses e frequentemente entregam números que a diretoria não confia.
E há um problema mais silencioso, que aparece mesmo quando o pipeline funciona: a métrica sem dono. Taxa de ocupação calculada de um jeito no painel da diretoria clínica, de outro no relatório do faturamento, de um terceiro na planilha da enfermagem. Todo mundo com um número diferente, todo mundo tecnicamente certo dentro da própria regra, e nenhuma reunião conseguindo avançar porque a primeira meia hora vai embora discutindo qual número é o verdadeiro.
Nenhuma ferramenta de visualização resolve isso. É um problema de definição, não de gráfico.
A stack WRO
Foi para atacar essas duas frentes — a arquitetura e a definição — que desenhamos nossa plataforma em três componentes que funcionam juntos.
wroDataBridge — os dados fora do caminho da operação
O wroDataBridge é a camada de replicação. Ele extrai os dados do sistema transacional de forma controlada e os entrega estruturados em um ambiente analítico próprio, sem que consultas de BI toquem o banco de produção. O ambiente onde o hospital atende deixa de ser o ambiente onde o hospital analisa.
wroDash — a métrica com dono, os painéis prontos e a pergunta em linguagem natural
O wroDash é a plataforma de BI, e o que a diferencia é a camada semântica nativa: cada métrica e cada regra de negócio é definida uma única vez, com a lógica do cliente, e passa a valer igual em todo painel, todo relatório e toda análise. Não existe mais versão paralela da mesma métrica.
As regras são ajustadas sob medida — a definição de ocupação, de tempo de permanência ou de glosa que faz sentido para aquela instituição, não uma média de mercado. E a instituição não começa do zero: já entregamos painéis prontos para Atendimento, Suprimentos, Exames e Financeiro, que servem como ponto de partida e são ajustados a partir dali.
É essa mesma camada que sustenta a análise conversacional do wroDash. O gestor pode perguntar em linguagem natural sobre os indicadores já modelados — abrir um número por unidade, comparar com o mês anterior, entender o que mudou — e receber a resposta junto com o gráfico correspondente, sem depender da TI para cada recorte novo.
A diferença está em como a resposta é construída. A pergunta não vira uma consulta livre inventada na hora sobre as tabelas do sistema: ela é resolvida em cima das métricas e regras já definidas com o cliente. O número que aparece na conversa é o mesmo número do painel, calculado pela mesma regra, porque a definição é única e vive na camada semântica. Sem esse alicerce, conversar com dados apenas multiplica o problema da métrica sem dono — cada pergunta produz uma interpretação nova do mesmo indicador, e nenhuma delas é auditável.
wroMessenger — o indicador que procura a pessoa
Painel só funciona para quem abre o painel. O wroMessenger inverte a lógica: gatilhos definidos sobre os próprios dados já analisados disparam avisos por e-mail, Telegram ou WhatsApp para quem precisa agir.
Ocupação de uma unidade cruzando o limite. Item crítico de suprimentos abaixo do ponto de reposição. Exame com resultado pendente além do prazo. O gestor recebe a informação no momento em que ela ainda permite decisão, sem depender de alguém lembrar de abrir o dashboard.
Em resumo
Conectar o BI direto na produção não é um atalho — é uma dívida que a operação paga todo dia, em segundos de espera na recepção. A alternativa não precisa ser um projeto de dois anos com uma equipe de engenharia montada do zero.