O que é monitoria de negócios

Monitoria de negócios é o acompanhamento contínuo, de preferência em tempo real, dos indicadores e eventos que mostram se a operação da empresa está funcionando como deveria. O foco não está nos servidores, na CPU ou na memória, mas na saúde dos processos de negócio: pedidos, transações, propostas, faturamento, integrações com parceiros.

Em inglês, a prática aparece como business monitoring ou business activity monitoring (BAM): o acompanhamento dos processos enquanto eles ainda estão em andamento, a partir dos eventos gerados pelos sistemas operacionais. ^[1] Ela herda ideias do processamento de eventos complexos, que trata cada pedido, pagamento ou mensagem como um evento de negócio a ser correlacionado com os demais. ^[2]

O negócio está acontecendo agora como deveria? Se não, onde, desde quando e quem precisa agir?

Na prática, a monitoria de negócios envolve cinco atividades:

• Definir o que importa: os KPIs e eventos críticos, como volume de pedidos, taxa de aprovação de transações, tempo de liquidação, falhas em integrações com parceiros e receita por hora.
• Coletar dados das fontes: ERP, APIs, bancos de dados e logs de integração.
• Comparar com o esperado: limites, metas, SLAs e o padrão histórico. Por exemplo: “às 10h costumamos ter 500 transações; hoje foram 50”.
• Alertar e dar visibilidade: painéis e alertas por e-mail, Slack ou Teams, para que o negócio e a TI ajam rápido.
• Investigar a causa: descobrir se a queda veio de um parceiro, de uma API ou de uma regra de negócio.

Uma nota de vocabulário: em português, “monitoria” também é a atividade do monitor acadêmico. Em contexto corporativo, “monitoramento de negócios” é igualmente correto e evita a ambiguidade; neste texto, os dois termos são usados como sinônimos.

Infraestrutura verde, negócio parado

A monitoria técnica responde se o sistema está no ar. O livro de Site Reliability Engineering do Google resume essa visão em quatro sinais de ouro: latência, tráfego, erros e saturação. ^[3] Métodos como o USE, de Brendan Gregg, e o RED, de Tom Wilkie, seguem a mesma linha, olhando para recursos e serviços. ^{[4] [5]}

Tudo isso é necessário, mas não basta. É comum a infraestrutura estar toda verde enquanto o negócio está parado: a API responde em 200 milissegundos, só que responde “não”.

As duas monitorias se complementam. A técnica costuma dizer onde está o defeito; a de negócios diz se o defeito importa e quanto ele custa. Quem só tem a primeira descobre o problema pelo cliente, pelo parceiro ou pelo fechamento do mês.

O ciclo da monitoria

Monitoria de negócios não é um painel pendurado na parede. É um ciclo que se repete, e cada alerta ensina algo sobre o processo que está sendo monitorado.

1. Definir. Parta das perguntas do negócio, não dos dados disponíveis. Para cada processo crítico, escolha poucos indicadores que mostrem volume, qualidade e tempo, e defina a meta e o dono de cada um.
2. Coletar. Leve os dados das fontes para um lugar onde possam ser comparados: consultas agendadas no banco, eventos de integração, logs das APIs. Guarde o histórico, porque sem ele não há padrão para comparar.
3. Comparar. Confronte o valor atual com uma referência: um limite fixo, um SLA acordado ou o padrão histórico para aquele dia e horário.
4. Alertar. Mostre o estado em painéis e avise quem precisa agir, no canal que essa pessoa usa. Todo alerta deve pedir uma ação; se ninguém precisa fazer nada, ele não deveria ter sido enviado. ^[3]
5. Investigar. Cruze o alerta de negócio com a monitoria técnica e com os parceiros para achar a causa: um parceiro fora do ar, uma mudança de regra, uma integração travada.
6. Melhorar. Depois de cada incidente, ajuste limites, crie os indicadores que faltaram e elimine os alertas que só geraram ruído.

Arquitetura de referência

A arquitetura de uma solução de monitoria de negócios tem cinco camadas. Ela pode começar com scripts em Python, consultas SQL e um e-mail, e evoluir para ferramentas de mercado de painéis, observabilidade e integração, sem mudar a lógica.

Foi esse o caminho de uma ferramenta que desenvolvi em Python para dar visibilidade à operação dos parceiros de API de um banco: começar pequeno, com consultas e alertas simples sobre os processos que mais doíam, e crescer conforme cada incidente mostrava o que faltava medir.

Limite fixo ou padrão histórico

A camada de regras é onde a monitoria de negócios ganha ou perde credibilidade. Uma regra mal calibrada gera alarmes falsos, as pessoas passam a ignorá-los e, no dia do problema real, ninguém olha. O inverso também acontece: uma regra frouxa demais deixa o problema passar.

Há cinco tipos de regra, e uma boa monitoria combina vários:

O capítulo sobre alertas baseados em SLOs do Site Reliability Workbook propõe avaliar cada regra por quatro critérios que servem também para o negócio: precisão (quantos alertas eram problemas reais), sensibilidade (quantos problemas reais geraram alerta), tempo de detecção e tempo para o alerta se encerrar depois que o problema acaba. ^[6]

Indicadores por segmento

Os indicadores mudam de um negócio para outro, mas a lógica é a mesma: volume, qualidade e tempo de cada processo crítico, recortados pela dimensão que ajuda a achar a causa, como parceiro, loja ou canal.

Para ligar os indicadores à estratégia e evitar medir só o que é fácil, vale olhar para o Balanced Scorecard, de Kaplan e Norton, que organiza as métricas em perspectivas financeira, de clientes, de processos internos e de aprendizado. ^[7] E para desenhar os painéis, os princípios de Stephen Few: tudo o que importa numa única tela, lido de relance, sem enfeites que disputem a atenção. ^[8]

Proposta de implantação

Esta seção pode ser usada como base de uma proposta para implantar a monitoria de negócios numa empresa ou numa área. Os prazos são uma referência para um primeiro ciclo e devem ser ajustados ao tamanho do escopo.

Objetivo

Detectar problemas nos processos críticos do negócio antes que clientes, parceiros ou o fechamento do mês os revelem, e dar a cada problema um dono e uma ação.

Escopo

Fases

1. Fase 0 · Diagnóstico · 2 semanasEntrevistas com as áreas de negócio, levantamento dos incidentes dos últimos meses, escolha dos processos do piloto e inventário das fontes de dados.
2. Fase 1 · Piloto · 4 a 6 semanasFichas dos indicadores, coleta, regras, painel e alertas para os processos escolhidos. Uma semana de alertas em modo silencioso para calibrar limites antes de avisar as pessoas.
3. Fase 2 · Expansão · 6 a 8 semanasNovos processos, padrão histórico por dia e horário, integração com o sistema de chamados e escalonamento.
4. Fase 3 · Operação contínuaRevisão mensal de indicadores e regras, análise de cada incidente e relatório de resultados para os patrocinadores.

Entregáveis

• Catálogo de indicadores: uma ficha por indicador, no modelo abaixo.
• Coletores e regras: código versionado, documentado e agendado.
• Painel: uma visão por processo, com o estado atual e a tendência do dia.
• Alertas e roteiros: cada alerta com canal, severidade, dono e a primeira ação esperada.
• Relatório do piloto: incidentes detectados, tempo de detecção, alarmes falsos e recomendações.

Modelo de ficha de indicador

Papéis

Critérios de sucesso

• Detecção antecipada: a maior parte dos incidentes de negócio detectada pela monitoria antes do cliente ou do parceiro.
• Tempo de detecção: de horas ou dias para minutos nos processos do piloto.
• Alertas úteis: pelo menos 8 em cada 10 alertas levam a uma ação.
• Uso: as áreas de negócio consultam o painel no dia a dia, e não só quando alguém avisa.

Riscos e como mitigá-los

• Fadiga de alertas. Alarmes demais fazem as pessoas pararem de olhar. Comece com poucas regras, use o modo silencioso para calibrar e elimine o que não gera ação.
• Indicador sem dono. Um alerta que chega para todos não chega para ninguém. Nenhum indicador entra em produção sem dono e primeira ação definidos.
• Dados de má qualidade. Cadastros incompletos e horários inconsistentes geram alarmes falsos. Inclua a qualidade da coleta na própria monitoria.
• Painel sem ação. Um painel bonito que ninguém usa não é monitoria. Cada indicador precisa responder a uma pergunta de negócio.
• Depender de uma só pessoa. Documente regras e coletores, versione o código e distribua o conhecimento na equipe.

Conclusões

A monitoria técnica diz se os sistemas estão funcionando; a monitoria de negócios diz se a empresa está funcionando. Sem a segunda, a infraestrutura pode estar toda verde enquanto propostas são recusadas, pedidos ficam parados e parceiros deixam de operar, e o problema só aparece quando alguém de fora reclama.

Implantá-la não exige começar com uma plataforma cara. Exige escolher os processos que mais importam, dar um dono e uma ação a cada indicador, comparar com o que é normal para aquele dia e horário e aprender com cada incidente. O resto, da ferramenta ao painel, pode crescer aos poucos.

O ganho vai além de detectar falhas mais cedo. Ao colocar negócio e TI olhando para os mesmos números, a monitoria de negócios cria uma linguagem comum sobre o que é a operação funcionando bem, e essa talvez seja a sua maior contribuição.

Referências

1. Wikipedia, "Real-time business intelligence", seção "Business activity monitoring", acesso em 29/09/2026, en.wikipedia.org/wiki/Real-time_business_intelligence.
2. Luckham, David, The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems, Addison-Wesley, 2002.
3. Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard (orgs.), Site Reliability Engineering: How Google Runs Production Systems, O’Reilly, 2016, capítulo 6, "Monitoring Distributed Systems", sre.google/sre-book/monitoring-distributed-systems.
4. Gregg, Brendan, "The USE Method", acesso em 29/09/2026, brendangregg.com/usemethod.html.
5. Wilkie, Tom, "The RED Method: How to Instrument Your Services", Grafana Labs, 2018, grafana.com/blog.
6. Beyer, Betsy; Murphy, Niall Richard; Rensin, David K.; Kawahara, Kent; Thorne, Stephen (orgs.), The Site Reliability Workbook, O’Reilly, 2018, capítulo 5, "Alerting on SLOs", sre.google/workbook/alerting-on-slos.
7. Kaplan, Robert S.; Norton, David P., The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, 1996.
8. Few, Stephen, Information Dashboard Design: The Effective Visual Communication of Data, O’Reilly, 2006.

What business monitoring is

Business monitoring is the continuous tracking, ideally in real time, of the indicators and events that show whether the company’s operation is working as it should. The focus is not on servers, CPU or memory, but on the health of business processes: orders, transactions, proposals, billing, integrations with partners.

The practice is also known as business activity monitoring (BAM): following processes while they are still in progress, based on the events produced by operational systems. ^[1] It inherits ideas from complex event processing, which treats every order, payment or message as a business event to be correlated with the others. ^[2]

Is the business happening right now as it should? If not, where, since when, and who needs to act?

In practice, business monitoring involves five activities:

• Define what matters: the critical KPIs and events, such as order volume, transaction approval rate, settlement time, failures in partner integrations and revenue per hour.
• Collect data from the sources: the ERP, APIs, databases and integration logs.
• Compare against what is expected: thresholds, targets, SLAs and the historical pattern. For example: “at 10 am we usually see 500 transactions; today there were 50”.
• Alert and provide visibility: dashboards and alerts by email, Slack or Teams, so that business and IT can act quickly.
• Investigate the cause: find out whether the drop came from a partner, an API or a business rule.

A note on vocabulary: the Portuguese original uses “monitoria de negócios”. In Portuguese, “monitoria” also means academic tutoring, so “monitoramento de negócios” is an equally correct term that avoids the ambiguity. In English, “business monitoring” and “business activity monitoring” are used interchangeably.

Green infrastructure, stalled business

Technical monitoring answers whether the system is up. Google’s Site Reliability Engineering book sums up this view in four golden signals: latency, traffic, errors and saturation. ^[3] Methods such as Brendan Gregg’s USE and Tom Wilkie’s RED follow the same line, looking at resources and services. ^{[4] [5]}

All of this is necessary, but it is not enough. It is common for the infrastructure to be all green while the business has stopped: the API answers in 200 milliseconds, but it answers “no”.

The two complement each other. Technical monitoring usually says where the defect is; business monitoring says whether the defect matters and how much it costs. Those who only have the first find out about problems from the customer, the partner or the month-end close.

The monitoring cycle

Business monitoring is not a dashboard hanging on the wall. It is a cycle that repeats, and every alert teaches something about the process being monitored.

1. Define. Start from the business questions, not from the data you happen to have. For each critical process, choose a few indicators that show volume, quality and time, and set the target and the owner of each one.
2. Collect. Bring the data from the sources to a place where it can be compared: scheduled database queries, integration events, API logs. Keep the history, because without it there is no pattern to compare against.
3. Compare. Check the current value against a reference: a fixed threshold, an agreed SLA or the historical pattern for that day and time.
4. Alert. Show the status on dashboards and notify whoever needs to act, on the channel that person uses. Every alert should call for an action; if nobody needs to do anything, it should not have been sent. ^[3]
5. Investigate. Cross the business alert with technical monitoring and with the partners to find the cause: a partner that is down, a rule change, a stuck integration.
6. Improve. After each incident, adjust thresholds, create the indicators that were missing and remove the alerts that only produced noise.

Reference architecture

A business monitoring solution has five layers. It can start with Python scripts, SQL queries and an email, and grow into off-the-shelf dashboard, observability and integration tools without changing the logic.

That was the path of a tool I built in Python to give visibility into the operation of a bank’s API partners: start small, with simple queries and alerts on the processes that hurt the most, and grow as each incident showed what was still missing.

Fixed threshold or historical pattern

The rules layer is where business monitoring gains or loses credibility. A badly calibrated rule produces false alarms, people start ignoring them and, on the day of the real problem, nobody looks. The opposite also happens: a rule that is too loose lets the problem through.

There are five kinds of rule, and good monitoring combines several of them:

The chapter on alerting on SLOs in The Site Reliability Workbook proposes judging each rule by four criteria that also work for the business: precision (how many alerts were real problems), recall (how many real problems raised an alert), detection time and reset time, the time the alert takes to clear after the problem ends. ^[6]

Indicators by industry

Indicators change from one business to another, but the logic is the same: volume, quality and time of each critical process, broken down by the dimension that helps find the cause, such as partner, store or channel.

To link indicators to strategy and avoid measuring only what is easy, look at Kaplan and Norton’s Balanced Scorecard, which organizes metrics into financial, customer, internal process and learning perspectives. ^[7] And to design the dashboards, Stephen Few’s principles: everything that matters on a single screen, read at a glance, with no decoration competing for attention. ^[8]

Implementation proposal

This section can serve as the basis of a proposal to put business monitoring in place in a company or a department. The timelines are a reference for a first cycle and should be adjusted to the size of the scope.

Objective

Detect problems in the critical business processes before customers, partners or the month-end close reveal them, and give each problem an owner and an action.

Scope

Phases

1. Phase 0 · Assessment · 2 weeksInterviews with the business areas, review of recent incidents, choice of the pilot processes and inventory of the data sources.
2. Phase 1 · Pilot · 4 to 6 weeksIndicator sheets, collection, rules, dashboard and alerts for the chosen processes. One week of alerts in silent mode to calibrate thresholds before notifying people.
3. Phase 2 · Expansion · 6 to 8 weeksNew processes, historical pattern by day and time, integration with the ticketing system and escalation.
4. Phase 3 · Ongoing operationMonthly review of indicators and rules, analysis of each incident and a results report for the sponsors.

Deliverables

• Indicator catalog: one sheet per indicator, following the template below.
• Collectors and rules: versioned, documented and scheduled code.
• Dashboard: one view per process, with the current status and the trend for the day.
• Alerts and runbooks: each alert with a channel, severity, owner and the first expected action.
• Pilot report: incidents detected, detection time, false alarms and recommendations.

Indicator sheet template

Roles

Success criteria

• Early detection: most business incidents detected by monitoring before the customer or the partner.
• Detection time: from hours or days down to minutes for the pilot processes.
• Useful alerts: at least 8 out of 10 alerts lead to an action.
• Usage: the business areas check the dashboard day to day, not only when someone warns them.

Risks and how to mitigate them

• Alert fatigue. Too many alarms make people stop looking. Start with few rules, use silent mode to calibrate and remove whatever does not lead to action.
• Indicator without an owner. An alert that goes to everyone reaches no one. No indicator goes live without an owner and a first action.
• Poor data quality. Incomplete master data and inconsistent timestamps produce false alarms. Include the quality of the collection in the monitoring itself.
• Dashboard without action. A beautiful dashboard nobody uses is not monitoring. Every indicator must answer a business question.
• Depending on a single person. Document rules and collectors, version the code and spread the knowledge across the team.

Conclusions

Technical monitoring tells you whether the systems are working; business monitoring tells you whether the company is working. Without the second, the infrastructure can be all green while proposals are rejected, orders sit still and partners stop operating, and the problem only shows up when someone outside complains.

Putting it in place does not require starting with an expensive platform. It requires choosing the processes that matter most, giving each indicator an owner and an action, comparing with what is normal for that day and time, and learning from every incident. Everything else, from the tool to the dashboard, can grow step by step.

The gain goes beyond detecting failures earlier. By getting business and IT to look at the same numbers, business monitoring creates a shared language about what a well-running operation looks like, and that may be its greatest contribution.

References

1. Wikipedia, "Real-time business intelligence", section "Business activity monitoring", accessed 29/09/2026, en.wikipedia.org/wiki/Real-time_business_intelligence.
2. Luckham, David, The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems, Addison-Wesley, 2002.
3. Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard (eds.), Site Reliability Engineering: How Google Runs Production Systems, O’Reilly, 2016, chapter 6, "Monitoring Distributed Systems", sre.google/sre-book/monitoring-distributed-systems.
4. Gregg, Brendan, "The USE Method", accessed 29/09/2026, brendangregg.com/usemethod.html.
5. Wilkie, Tom, "The RED Method: How to Instrument Your Services", Grafana Labs, 2018, grafana.com/blog.
6. Beyer, Betsy; Murphy, Niall Richard; Rensin, David K.; Kawahara, Kent; Thorne, Stephen (eds.), The Site Reliability Workbook, O’Reilly, 2018, chapter 5, "Alerting on SLOs", sre.google/workbook/alerting-on-slos.
7. Kaplan, Robert S.; Norton, David P., The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, 1996.
8. Few, Stephen, Information Dashboard Design: The Effective Visual Communication of Data, O’Reilly, 2006.

Che cos’è il monitoraggio del business

Il monitoraggio del business è il controllo continuo, possibilmente in tempo reale, degli indicatori e degli eventi che mostrano se l’operatività dell’azienda funziona come dovrebbe. Il centro dell’attenzione non sono i server, la CPU o la memoria, ma la salute dei processi di business: ordini, transazioni, proposte, fatturazione, integrazioni con i partner.

In inglese la pratica è nota come business monitoring o business activity monitoring (BAM): seguire i processi mentre sono ancora in corso, a partire dagli eventi generati dai sistemi operativi. ^[1] Eredita idee dall’elaborazione di eventi complessi, che tratta ogni ordine, pagamento o messaggio come un evento di business da correlare con gli altri. ^[2]

Il business sta funzionando adesso come dovrebbe? Se no, dove, da quando e chi deve intervenire?

In pratica, il monitoraggio del business comprende cinque attività:

• Definire ciò che conta: i KPI e gli eventi critici, come il volume degli ordini, il tasso di approvazione delle transazioni, il tempo di regolamento, i guasti nelle integrazioni con i partner e i ricavi orari.
• Raccogliere i dati dalle fonti: ERP, API, database e log di integrazione.
• Confrontare con l’atteso: soglie, obiettivi, SLA e andamento storico. Per esempio: “alle 10 di solito abbiamo 500 transazioni; oggi sono state 50”.
• Allertare e dare visibilità: cruscotti e allarmi via e-mail, Slack o Teams, perché business e IT possano agire in fretta.
• Indagare la causa: capire se il calo dipende da un partner, da un’API o da una regola di business.

Una nota sul lessico: l’originale portoghese usa “monitoria de negócios”. In portoghese “monitoria” indica anche il tutorato accademico, per cui “monitoramento de negócios” è un termine altrettanto corretto che evita l’ambiguità. In italiano si parla di monitoraggio del business o dei processi di business.

Infrastruttura verde, business fermo

Il monitoraggio tecnico risponde alla domanda se il sistema è attivo. Il libro Site Reliability Engineering di Google riassume questa visione in quattro segnali d’oro: latenza, traffico, errori e saturazione. ^[3] Metodi come USE, di Brendan Gregg, e RED, di Tom Wilkie, seguono la stessa linea, guardando a risorse e servizi. ^{[4] [5]}

Tutto questo è necessario, ma non basta. Capita spesso che l’infrastruttura sia tutta verde mentre il business è fermo: l’API risponde in 200 millisecondi, ma risponde “no”.

I due monitoraggi si completano. Quello tecnico di solito dice dove si trova il difetto; quello del business dice se il difetto conta e quanto costa. Chi ha solo il primo scopre i problemi dal cliente, dal partner o dalla chiusura di fine mese.

Il ciclo del monitoraggio

Il monitoraggio del business non è un cruscotto appeso al muro. È un ciclo che si ripete, e ogni allarme insegna qualcosa sul processo monitorato.

1. Definire. Partite dalle domande del business, non dai dati disponibili. Per ogni processo critico scegliete pochi indicatori che mostrino volume, qualità e tempo, e fissate l’obiettivo e il responsabile di ciascuno.
2. Raccogliere. Portate i dati dalle fonti in un luogo dove si possano confrontare: query pianificate sul database, eventi di integrazione, log delle API. Conservate lo storico, perché senza di esso non c’è un andamento con cui confrontarsi.
3. Confrontare. Mettete a confronto il valore attuale con un riferimento: una soglia fissa, uno SLA concordato o l’andamento storico per quel giorno e quell’ora.
4. Allertare. Mostrate lo stato nei cruscotti e avvisate chi deve intervenire, sul canale che quella persona usa. Ogni allarme deve richiedere un’azione; se nessuno deve fare nulla, non avrebbe dovuto essere inviato. ^[3]
5. Indagare. Incrociate l’allarme di business con il monitoraggio tecnico e con i partner per trovare la causa: un partner fuori servizio, una regola cambiata, un’integrazione bloccata.
6. Migliorare. Dopo ogni incidente, regolate le soglie, create gli indicatori che mancavano ed eliminate gli allarmi che hanno prodotto solo rumore.

Architettura di riferimento

Una soluzione di monitoraggio del business ha cinque livelli. Può partire con script Python, query SQL e un’e-mail, ed evolvere verso strumenti di mercato per cruscotti, osservabilità e integrazione, senza cambiare la logica.

È stato questo il percorso di uno strumento che ho sviluppato in Python per dare visibilità all’operatività dei partner API di una banca: partire in piccolo, con query e allarmi semplici sui processi più dolorosi, e crescere man mano che ogni incidente mostrava cosa mancava ancora da misurare.

Soglia fissa o andamento storico

Il livello delle regole è dove il monitoraggio del business guadagna o perde credibilità. Una regola tarata male genera falsi allarmi, le persone iniziano a ignorarli e, il giorno del problema vero, nessuno guarda. Succede anche il contrario: una regola troppo larga lascia passare il problema.

Esistono cinque tipi di regola, e un buon monitoraggio ne combina diversi:

Il capitolo sugli allarmi basati sugli SLO del Site Reliability Workbook propone di valutare ogni regola secondo quattro criteri che valgono anche per il business: precisione (quanti allarmi erano problemi reali), sensibilità (quanti problemi reali hanno generato un allarme), tempo di rilevamento e tempo di rientro dell’allarme dopo la fine del problema. ^[6]

Indicatori per settore

Gli indicatori cambiano da un business all’altro, ma la logica è la stessa: volume, qualità e tempo di ogni processo critico, suddivisi per la dimensione che aiuta a trovare la causa, come partner, negozio o canale.

Per collegare gli indicatori alla strategia ed evitare di misurare solo ciò che è facile, conviene guardare alla Balanced Scorecard di Kaplan e Norton, che organizza le metriche nelle prospettive finanziaria, dei clienti, dei processi interni e dell’apprendimento. ^[7] E per disegnare i cruscotti, i principi di Stephen Few: tutto ciò che conta in un’unica schermata, leggibile a colpo d’occhio, senza decorazioni che si contendano l’attenzione. ^[8]

Proposta di implementazione

Questa sezione può servire come base per una proposta di introduzione del monitoraggio del business in un’azienda o in un reparto. I tempi sono un riferimento per un primo ciclo e vanno adattati all’ampiezza del perimetro.

Obiettivo

Rilevare i problemi nei processi critici del business prima che li rivelino i clienti, i partner o la chiusura di fine mese, e dare a ogni problema un responsabile e un’azione.

Perimetro

Fasi

1. Fase 0 · Diagnosi · 2 settimaneInterviste con le aree di business, analisi degli incidenti degli ultimi mesi, scelta dei processi del pilota e inventario delle fonti dati.
2. Fase 1 · Pilota · 4–6 settimaneSchede degli indicatori, raccolta, regole, cruscotto e allarmi per i processi scelti. Una settimana di allarmi in modalità silenziosa per tarare le soglie prima di avvisare le persone.
3. Fase 2 · Estensione · 6–8 settimaneNuovi processi, andamento storico per giorno e ora, integrazione con il sistema di ticketing ed escalation.
4. Fase 3 · Operatività continuaRevisione mensile di indicatori e regole, analisi di ogni incidente e report dei risultati per gli sponsor.

Deliverable

• Catalogo degli indicatori: una scheda per indicatore, secondo il modello qui sotto.
• Collettori e regole: codice versionato, documentato e pianificato.
• Cruscotto: una vista per processo, con lo stato attuale e l’andamento della giornata.
• Allarmi e procedure: ogni allarme con canale, gravità, responsabile e prima azione prevista.
• Report del pilota: incidenti rilevati, tempo di rilevamento, falsi allarmi e raccomandazioni.

Modello di scheda dell’indicatore

Ruoli

Criteri di successo

• Rilevamento anticipato: la maggior parte degli incidenti di business rilevata dal monitoraggio prima del cliente o del partner.
• Tempo di rilevamento: da ore o giorni a minuti per i processi del pilota.
• Allarmi utili: almeno 8 allarmi su 10 portano a un’azione.
• Utilizzo: le aree di business consultano il cruscotto ogni giorno, non solo quando qualcuno le avvisa.

Rischi e come mitigarli

• Affaticamento da allarmi. Troppi allarmi fanno smettere di guardare. Iniziate con poche regole, usate la modalità silenziosa per tarare ed eliminate ciò che non porta ad azioni.
• Indicatore senza responsabile. Un allarme che arriva a tutti non arriva a nessuno. Nessun indicatore va in produzione senza responsabile e prima azione definiti.
• Dati di scarsa qualità. Anagrafiche incomplete e orari incoerenti generano falsi allarmi. Includete la qualità della raccolta nel monitoraggio stesso.
• Cruscotto senza azione. Un bel cruscotto che nessuno usa non è monitoraggio. Ogni indicatore deve rispondere a una domanda di business.
• Dipendere da una sola persona. Documentate regole e collettori, versionate il codice e distribuite la conoscenza nel team.

Conclusioni

Il monitoraggio tecnico dice se i sistemi funzionano; il monitoraggio del business dice se l’azienda funziona. Senza il secondo, l’infrastruttura può essere tutta verde mentre le proposte vengono rifiutate, gli ordini restano fermi e i partner smettono di operare, e il problema emerge solo quando qualcuno da fuori si lamenta.

Introdurlo non richiede di partire da una piattaforma costosa. Richiede di scegliere i processi che contano di più, dare a ogni indicatore un responsabile e un’azione, confrontare con ciò che è normale per quel giorno e quell’ora e imparare da ogni incidente. Il resto, dallo strumento al cruscotto, può crescere per gradi.

Il guadagno va oltre il rilevare prima i guasti. Mettendo business e IT davanti agli stessi numeri, il monitoraggio del business crea un linguaggio comune su che cosa significhi un’operatività che funziona bene, e forse è questo il suo contributo più grande.

Riferimenti

1. Wikipedia, "Real-time business intelligence", sezione "Business activity monitoring", consultato il 29/09/2026, en.wikipedia.org/wiki/Real-time_business_intelligence.
2. Luckham, David, The Power of Events: An Introduction to Complex Event Processing in Distributed Enterprise Systems, Addison-Wesley, 2002.
3. Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard (a cura di), Site Reliability Engineering: How Google Runs Production Systems, O’Reilly, 2016, capitolo 6, "Monitoring Distributed Systems", sre.google/sre-book/monitoring-distributed-systems.
4. Gregg, Brendan, "The USE Method", consultato il 29/09/2026, brendangregg.com/usemethod.html.
5. Wilkie, Tom, "The RED Method: How to Instrument Your Services", Grafana Labs, 2018, grafana.com/blog.
6. Beyer, Betsy; Murphy, Niall Richard; Rensin, David K.; Kawahara, Kent; Thorne, Stephen (a cura di), The Site Reliability Workbook, O’Reilly, 2018, capitolo 5, "Alerting on SLOs", sre.google/workbook/alerting-on-slos.
7. Kaplan, Robert S.; Norton, David P., The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, 1996.
8. Few, Stephen, Information Dashboard Design: The Effective Visual Communication of Data, O’Reilly, 2006.