Processo ITSM Alinhado com ITIL

Análise de negócio

Processo end-to-end com requisitos, business cases, modelação e análise de viabilidade

Descarregar pack completo

Âmbito e objectivos

Objectivo

Analisar uma parte ou a totalidade do negócio, definir as suas necessidades e recomendar soluções que respondam a essas necessidades, assegurando que os investimentos em TI geram valor mensurável.

Trigger

Solicitação de novo projecto ou iniciativa, identificação de uma lacuna ou oportunidade de melhoria, revisão estratégica ou pedido formal de análise por parte da gestão.

Âmbito

Desde a recolha de requisitos dos stakeholders até à validação final dos requisitos aprovados e entrega do business case ou documento de requisitos.

Fora do âmbito

Implementação das soluções identificadas (gestão de projectos), design técnico detalhado das soluções e gestão operacional dos serviços resultantes.

Output

Documento de requisitos aprovado, business case validado, análise de gap documentada, opções de solução avaliadas e recomendação formal entregue às partes interessadas.

Diagrama do processo

Diagrama BPMN simplificado do processo de análise de negócio (3 swimlanes). Percorra horizontalmente em dispositivos móveis.

Actividades macro

# Actividade Responsável Input Output
1 Requisitos dos stakeholders Business analyst Solicitação, objectivos de negócio Lista de requisitos de alto nível
2 Análise do estado actual Business analyst / Service owner Documentação existente, entrevistas Diagnóstico do estado actual (as-is)
3 Análise de gap Business analyst Estado actual, requisitos, estado desejado Registo de lacunas e prioridades
4 Opções de solução Business analyst / Arquitectura Análise de gap, restrições técnicas Opções de solução avaliadas
5 Estudo de viabilidade Business analyst / Gestão Opções de solução, restrições financeiras Avaliação de viabilidade por opção
6 Business case Business analyst / Project manager Opção seleccionada, estimativas de custo/benefício Business case para aprovação
7 Documentação de requisitos Business analyst Requisitos validados, business case aprovado Documento de requisitos (BRD/FRD)
8 Validação com stakeholders Business analyst / Service owner Documento de requisitos Requisitos aprovados e assinados

Descrição detalhada das actividades

O processo inicia com a identificação e recolha sistemática dos requisitos de todos os stakeholders relevantes. As técnicas utilizadas incluem entrevistas, workshops, questionários e observação directa dos processos actuais.

Passos chave

  • Identificar todos os stakeholders com interesse na iniciativa
  • Realizar entrevistas e workshops de elicitação de requisitos
  • Documentar requisitos funcionais e não funcionais
  • Classificar requisitos por prioridade (MoSCoW ou similar)
  • Validar a lista de requisitos com os stakeholders
Critério de saída: lista de requisitos de alto nível documentada e validada pelos principais stakeholders.

A análise do estado actual (as-is) documenta como os processos, sistemas e capacidades funcionam hoje, identificando pontos de dor, ineficiências e limitações que a solução deve endereçar.

Passos chave

  • Mapear os processos actuais com diagramas de fluxo
  • Identificar pontos de dor e ineficiências operacionais
  • Analisar dados de desempenho e métricas existentes
  • Documentar sistemas, ferramentas e integrações actuais
  • Validar o diagnóstico com os service owners responsáveis
Critério de saída: diagnóstico do estado actual documentado, com mapeamento de processos e identificação de pontos de dor.

A análise de gap compara o estado actual com o estado desejado e identifica as lacunas que precisam de ser colmatadas. Este passo é a base para definir o âmbito e as prioridades da solução a implementar.

Passos chave

  • Definir o estado desejado (to-be) com base nos requisitos
  • Comparar estado actual e estado desejado por dimensão
  • Identificar e documentar as lacunas prioritárias
  • Quantificar o impacto de cada lacuna no negócio
  • Ordenar as lacunas por prioridade de endereçamento
Critério de saída: registo de lacunas documentado com impacto e prioridade definidos para cada gap identificado.

Com base na análise de gap, o business analyst e a arquitectura definem e avaliam múltiplas opções de solução, comparando-as em termos de custo, complexidade, tempo de implementação e alinhamento com os requisitos.

Passos chave

  • Gerar pelo menos três opções de solução alternativas
  • Avaliar cada opção contra os requisitos definidos
  • Estimar custo e esforço de implementação por opção
  • Identificar riscos e restrições técnicas de cada opção
  • Apresentar as opções aos stakeholders para deliberação
Critério de saída: opções de solução avaliadas com análise comparativa e recomendação da opção preferida.

O estudo de viabilidade avalia se a opção recomendada é exequível do ponto de vista técnico, financeiro e organizacional. Este passo reduz o risco de investir em soluções que não são implementáveis nas condições da organização.

Passos chave

  • Avaliar viabilidade técnica com a equipa de arquitectura
  • Confirmar disponibilidade de orçamento com gestão financeira
  • Avaliar capacidade organizacional para absorver a mudança
  • Identificar dependências com outros projectos ou iniciativas
  • Documentar pressupostos e restrições da viabilidade
Critério de saída: avaliação de viabilidade documentada com confirmação de exequibilidade técnica e financeira.

O business case formaliza a justificação do investimento, detalhando os custos, benefícios quantificados, riscos e cronograma esperado. É o documento central que suporta a decisão de aprovação ou rejeição da iniciativa pela gestão.

Passos chave

  • Quantificar os benefícios esperados com métricas concretas
  • Detalhar todos os custos (implementação, operação, formação)
  • Calcular ROI, payback period e NPV quando aplicável
  • Identificar riscos e estratégias de mitigação
  • Submeter o business case para aprovação formal
Critério de saída: business case completo submetido à gestão para aprovação formal.

Após aprovação do business case, os requisitos são documentados de forma detalhada no documento de requisitos de negócio (BRD) ou no documento de requisitos funcionais (FRD). Este documento serve de contrato entre o negócio e a equipa de implementação.

Passos chave

  • Elaborar o BRD com requisitos funcionais detalhados
  • Documentar requisitos não funcionais (desempenho, segurança, disponibilidade)
  • Definir critérios de aceitação para cada requisito
  • Criar casos de uso ou user stories quando aplicável
  • Rever o documento com a equipa de arquitectura e projecto
Critério de saída: documento de requisitos completo, revisto pela arquitectura e pronto para validação final pelos stakeholders.

A validação final garante que o documento de requisitos reflecte correctamente as necessidades do negócio e que todos os stakeholders principais concordam com o âmbito e prioridades definidas. A aprovação formal fecha o processo de análise.

Passos chave

  • Realizar sessão de walkthrough do documento com os stakeholders
  • Recolher e incorporar feedback final
  • Resolver ambiguidades ou conflitos entre requisitos
  • Obter assinatura de aprovação dos stakeholders principais
  • Entregar o documento aprovado à equipa de projecto
Critério de saída: requisitos aprovados e assinados pelos stakeholders, documento entregue formalmente à equipa de projecto.

Modelo RACI

Actividade Bus. analyst
(BA)
Service owner
(SO)
Arquitectura
(AR)
Proj. manager
(PM)
Gestão
(GT)
Requisitos dos stakeholders R C I I A
Análise do estado actual R C C I A
Análise de gap R C C I A
Opções de solução R C R I A
Estudo de viabilidade R C C C A
Business case R C I C A
Documentação de requisitos R C C I A
Validação com stakeholders R A I I I
R Responsible - executa a actividade A Accountable - responde pelo resultado C Consulted - é consultado I Informed - é informado

Métricas e KPIs

Métrica Descrição Target sugerido
Requisitos aprovados no prazo Percentagem de documentos de requisitos entregues e aprovados dentro do prazo acordado com o projecto > 85%
Taxa de retrabalho Percentagem de requisitos que são revistos ou alterados após aprovação formal, indicando qualidade da análise inicial < 15%
Satisfação dos stakeholders Classificação média dos stakeholders sobre a qualidade e clareza dos requisitos entregues pelo business analyst > 4,0/5,0
Business cases aprovados Percentagem de business cases submetidos que recebem aprovação formal da gestão sem necessidade de revisão significativa > 75%
Tempo médio de análise Duração média do ciclo completo de análise, desde a solicitação até à entrega dos requisitos aprovados < 4 semanas

Interfaces com outros processos

Saida

Service design (SDP)

Os requisitos aprovados alimentam o processo de service design para criação ou redesenho do serviço de acordo com as necessidades identificadas.

Saida

Gestão de projectos

O business case aprovado e o documento de requisitos são a base de arranque formal para a iniciação do projecto de implementação.

Entrada

Strategy

Os objectivos estratégicos da organização definem as prioridades e o contexto para a análise de negócio.

Entrada

Melhoria contínua

Oportunidades de melhoria identificadas no processo de melhoria contínua podem originar solicitações formais de análise de negócio.

Saida

Financial management

O business case elaborado pela análise de negócio fornece os dados necessários para a gestão financeira aprovar o orçamento do projecto.

Entrada

Todos os processos

Qualquer processo ITSM pode originar solicitações de análise de negócio quando é identificada necessidade de mudança ou melhoria.

Descarregar o pack completo

Inclui o processo documentado, template de BRD, modelo RACI em Excel e template de business case.