Quando o Jira sai do papel de ferramenta de desenvolvimento e vira plataforma corporativa (via Jira Service Management em modo Enterprise Service Management), ele começa a registrar a operação inteira da empresa: onboarding de novo colaborador no RH, aprovação de despesa no Financeiro, ordem de manutenção no Facilities, revisão de contrato no Jurídico. Segundo a Atlassian, esse modelo estende as práticas de service management do TI para todas as áreas, com portal único, SLAs, catálogo de serviços e workflows por time. O que ninguém está olhando é o dado gerado por trás disso. O BI da casa foi desenhado para acompanhar entrega de software e continua rodando sprint burndown enquanto a diretoria pergunta o custo médio de onboarding, o volume de chamados de RH por área e o tempo de resolução de despesa. É outro dataset, outro buyer e outra consultoria de BI, montada sobre o mesmo Jira.

O ponto cego: a diretoria já pergunta e a TI ainda entrega dashboard de sprint

A cena repete em empresa de porte que expandiu o Jira para além da TI. A liderança de RH quer saber quanto tempo leva um onboarding do início ao fim, cruzando o pedido inicial com o dia em que o colaborador está 100% operacional. O CFO quer o custo médio por tipo de solicitação de despesa, comparado ao mês anterior. O head de Facilities quer o ranking de tipos de chamado que mais consomem tempo do time de manutenção. Perguntas legítimas, com dado disponível, e sem resposta.

A resposta não chega por três razões que se combinam. Primeira: o BI foi montado para o time de desenvolvimento, com métricas de fluxo (cycle time, throughput) que respondem à operação técnica. Segunda: as áreas de negócio não têm autonomia para extrair sozinhas o dado que precisam, e a fila da BI da TI está cheia de solicitação de sprint. Terceira: quando o dashboard finalmente sai, ele mostra o que a TI conhece do JSM (número de chamados, tempo médio de resposta) e não o que a diretoria de negócio quer ver (custo, aderência de SLA por processo de negócio, produtividade cruzada).

A tese deste guia: BI que olha só desenvolvimento é BI que só serve à TI. Quando o Jira vira ferramenta corporativa via ESM, o BI precisa cruzar áreas, medir custo por serviço e responder à diretoria financeira, ao RH e ao Facilities. É outra consultoria de BI, com outro dataset, outra modelagem e outro buyer, não a mesma vestida com relatório diferente. E ela mora exatamente sobre o Jira que a empresa já paga.

O que o Jira em modo ESM gera de dado corporativo (e que ninguém está lendo)

A Atlassian documenta que times como RH, Financeiro, Jurídico, Marketing e Facilities operam no Jira Service Management com portais próprios, catálogos de serviço, SLAs e workflows por área. Cada uma dessas operações gera um dataset específico que a diretoria de negócio quer ver. Alguns exemplos concretos:

O ponto cross-área é o mais poderoso e o menos explorado. Um onboarding real envolve RH (pedido), TI (provisionamento de acesso), Facilities (mesa e crachá) e Financeiro (folha). Quando essas quatro operações estão no mesmo Jira, é possível medir a jornada inteira, e não só o pedaço de cada área. É análise de processo corporativo com dado, não com percepção.

As três camadas de BI que resolvem esse problema (na ordem de custo)

O erro comum é escolher a camada mais cara antes de entender qual é o problema. As três camadas se somam, cada uma resolvendo uma classe de pergunta:

Camada 1 · Relatórios nativos do JSM (o que o Jira já traz)

O JSM entrega, sem custo adicional, relatórios operacionais por projeto: volume de chamados, SLA por tipo, backlog, resolução por agente. Resolve a pergunta do gestor de área (“meu time está no prazo?”). Não resolve a pergunta da diretoria (“como estamos como empresa?”), porque cada projeto é uma ilha e nada cruza.

Camada 2 · Dashboards executivos consolidados

Quando a pergunta cresce, entra a camada de BI executivo. Duas opções ancoradas na plataforma: o Atlassian Analytics, documentado pela Atlassian como a ferramenta que quebra silos entre projetos e constrói dashboards interativos sobre dados de Jira e Confluence; e o Power BI conectado ao Jira, que a CSP Tech entrega via Power BI for Jira, conector no-code publicado no Atlassian Marketplace. Nas duas opções, o entregável é o mesmo: dashboards que consolidam áreas, com modelo semântico governado e métricas de negócio definidas uma vez para valer em toda leitura. Aqui aparecem a leitura por área, o cruzamento, o cross-área. Aqui a diretoria começa a responder as próprias perguntas sem abrir chamado.

Camada 3 · Analítica em escala e IA

Quando a leitura descritiva não basta (previsão de volume por sazonalidade, detecção automática de exceção, agente de IA respondendo sobre a operação inteira), o dado do JSM entra no pipeline analítico que já cobrimos no cluster. Não é substituição da camada 2, é continuação. E não é a primeira parada: só faz sentido quando as duas primeiras camadas já estão maduras e a pergunta genuinamente cresceu.

O que muda numa consultoria de BI de ESM em relação à consultoria de BI de desenvolvimento

Consultoria de BI para desenvolvimento (que já cobrimos em artigos anteriores) é sobre fluxo, ciclo, entrega. Consultoria de BI para ESM é outro trabalho, com três diferenças estruturais:

•     O buyer muda. Não é o head de engenharia querendo entender o time. É a diretoria de negócio (CFO, head de RH, head de Facilities) querendo entender a operação corporativa. O que se apresenta no board é diferente do que se apresenta na reunião de engenharia.

•     As métricas são de negócio, não de fluxo. Aderência a SLA por processo, custo por unidade de serviço, produtividade cruzada. Story point não entra na conversa.

•     A modelagem tem que suportar cross-área. O modelo semântico precisa costurar dado de projetos diferentes (RH + TI + Facilities num onboarding) sem quebrar governança de acesso. É desenho de arquitetura que a consultoria de BI comum não faz.

É por isso que Atlassian Gold + expertise em Power BI é o cruzamento que faz diferença: a mesma consultoria precisa entender do lado Atlassian (como o JSM registra a operação de cada área, como o ESM se estrutura, como os projetos se relacionam) e do lado BI (modelo semântico com métricas de negócio definidas uma vez, governança de acesso cross-área, dashboards que a diretoria consome sem abrir chamado). É um único trabalho, não dois vendidos separados. A CSP Tech opera com essa combinação: Atlassian Gold na origem, Microsoft Gold no BI e produto próprio Power BI for Jira ligando os dois lados.

Quando ainda não vale investir nessa consultoria

•     O JSM ainda não é modo ESM. Se as áreas de negócio ainda operam por e-mail, planilha ou ferramenta separada, o dado corporativo não existe no Jira. A ordem é levar as áreas para o JSM primeiro (Enterprise Service Management é um trabalho anterior), e depois montar a leitura em BI.

•     O JSM está mal configurado nas áreas de negócio. Workflow que não reflete o processo real da área e campos preenchidos por obrigação produzem dado sujo, e o dashboard sobre dado sujo mente com autoridade. Higiene de configuração na origem vem antes.

•     A diretoria ainda não pergunta. Se a demanda por leitura de negócio ainda não chegou, montar o BI antes é dimensionar para pergunta que ninguém está fazendo. Consultoria de BI de ESM se justifica quando existe demanda concreta de leitura por parte do buyer de negócio.

Perguntas frequentes

O que é Enterprise Service Management (ESM) no Jira?

Segundo a Atlassian, ESM estende as práticas de IT Service Management (ITSM) para além da TI, aplicando-as a áreas como RH, Financeiro, Jurídico, Facilities e Marketing. Na prática, no Jira Service Management significa que essas áreas ganham portais próprios, catálogos de serviço, SLAs e workflows customizados, operando sob a mesma plataforma.

Preciso de Power BI para ter BI sobre o JSM?

Não obrigatoriamente. A Atlassian oferece o Atlassian Analytics para dashboards consolidados sobre Jira e Confluence, documentado como ferramenta para quebrar silos entre projetos. O Power BI conectado ao Jira, via conectores como o Power BI for Jira da CSP, entra quando a leitura precisa integrar dado de fora do Atlassian (ERP, CRM) ou aproveitar um investimento já feito em Microsoft 365. As duas opções são válidas e podem coexistir.

Qual a diferença entre BI de desenvolvimento e BI de ESM?

BI de desenvolvimento acompanha fluxo de entrega técnica (cycle time, throughput, sprint). BI de ESM acompanha operação corporativa por área de negócio (aderência de SLA, custo por processo, jornada cross-área). São datasets diferentes, buyers diferentes e modelagens diferentes, mesmo quando rodam sobre o mesmo Jira. Confundir os dois é o erro que faz a diretoria receber dashboard de sprint quando pediu leitura de RH.

Como começar? Precisamos refazer tudo?

Não. O caminho que reduz risco é começar por uma área com demanda clara da diretoria (tipicamente RH ou Facilities), montar a camada 2 de BI executivo sobre essa área, validar em produção, e expandir. É trabalho por onda, não big-bang. O primeiro passo é um diagnóstico que mapeia quais áreas já estão em ESM, quais perguntas a diretoria faz, e onde a leitura existe versus onde precisa ser construída.

Próximo passo

Se a sua diretoria de negócio já pergunta e o BI da casa continua entregando dashboard de sprint, o problema não é a ferramenta e não é a área de dados. É que ninguém desenhou o BI corporativo sobre o Jira que a empresa já tem. Solicite um diagnóstico de BI corporativo sobre Jira Service Management com a CSP Tech e receba o mapa das perguntas de negócio que já podem ser respondidas, das áreas mais maduras para começar e das camadas de BI que fazem sentido para o seu estágio.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google e Anthropic. Revisão técnica por especialistas Atlassian e Microsoft da CSP Tech (Atlassian Gold Partner, Microsoft Gold Partner, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).

Fontes (oficiais, acesso jul/2026): Atlassian, “Enterprise Service Management” (atlassian.com/software/jira/service-management/features/enterprise-service-management); Atlassian, “The complete guide to Enterprise Service Management (ESM)” (atlassian.com/software/jira/service-management/whats-new/expanding-service-management-beyond-it); Atlassian, “Jira Service Management for Enterprises” e Atlassian Analytics (atlassian.com/software/jira/service-management/for-enterprises); Atlassian, “Enterprise Service Management in Jira Service Management” (atlassian.com/.../product-guide/getting-started/enterprise-service-management). CSP Tech, Power BI for Jira, conector no-code no Atlassian Marketplace (csptech.com.br).