Btor Modeler — Ajuda
Voltar ao repositório
Guia de especificação

Como montar uma especificação completa de processo

Uma boa especificação de processo descreve não apenas o fluxo, mas também o contexto de negócio, regras, sistemas, riscos e indicadores. Use a lista abaixo como checklist no preenchimento do modelador.

1. Identificação do processo

  • Nome claro e objetivo do processo.
  • Código único (ex: FIN-001, RH-004).
  • Versão atual e histórico de revisões.
  • Área responsável e dono do processo.
  • Autor da especificação e data de atualização.

2. Objetivo

  • Por que o processo existe?
  • Qual resultado de negócio ele deve entregar?
  • Alinhamento com objetivos estratégicos da área/empresa.

3. Escopo

  • Ponto de início (gatilho que dispara o processo).
  • Ponto de fim (entregável ou estado final).
  • O que está dentro do processo (inclusões).
  • O que está fora do processo (exclusões).

4. Contexto e justificativa

  • Breve descrição do cenário de negócio.
  • Legislação, normas ou políticas internas aplicáveis.
  • Relacionamento com outros processos (entradas/saídas de processos vizinhos).

5. Gatilho / evento de início

  • Evento que começa o fluxo (requisição, alerta, prazo, e-mail, etc).
  • Quem ou qual sistema gera o gatilho.
  • Frequência esperada (diária, sob demanda, mensal).

6. Entradas e saídas

  • Entradas: documentos, dados, insumos, decisões ou autorizações necessárias.
  • Saídas: entregáveis, registros, aprovações, ordens de serviço, e-mails.
  • Formato das informações (PDF, planilha, JSON, etc).

7. Partes interessadas e responsáveis

  • Dono do processo (accountable).
  • Executor(es) das atividades.
  • Aprovadores e suas alçadas.
  • Clientes/destinatários do resultado.
  • Sistemas ou APIs que participam do fluxo.

8. Raias, pools e participantes

  • Mapeamento de pools (organizações ou sistemas externos).
  • Raias dentro de cada pool (papel, departamento ou sistema).
  • Quem executa cada passo do diagrama.

9. Fluxo detalhado (passo a passo)

  • Atividades, tarefas e subprocessos em ordem lógica.
  • Decisões (gateways exclusivos, paralelos, inclusivos).
  • Eventos intermediários (timers, mensagens, alertas).
  • Pontos de integração e troca de mensagens entre pools.
  • Narrativa em linguagem simples de cada passo.

10. Regras de negócio

  • Regras que definem como o fluxo deve se comportar.
  • Alçadas de aprovação e limites de valor.
  • Prazos e condições para avançar ou retornar.
  • Identificadores como RN-01, RN-02.

11. Sistemas e integrações

  • Ferramentas e sistemas utilizados em cada etapa.
  • APIs, webhooks, robôs (RPA) e planilhas envolvidas.
  • Requisitos de acesso, permissões e logs.

12. Indicadores (KPIs)

  • Métricas de desempenho (tempo, custo, qualidade, volume).
  • Meta esperada e frequência de medição.
  • Responsável pela coleta e análise do indicador.

13. Riscos e controles

  • Riscos operacionais, de conformidade, de segurança e fraude.
  • Controles preventivos, detectivos e corretivos.
  • Impacto e probabilidade de cada risco relevante.

14. Exceções e caminhos alternativos

  • Cenários fora do fluxo principal (erros, rejeições, falta de dados).
  • Como o processo se recupera ou volta ao fluxo principal.
  • Escalonamentos e tratativas especiais.

15. Documentos, anexos e referências

  • Modelos de documentos utilizados no processo.
  • Links para políticas, regulamentos ou manuais relacionados.
  • Anexos ao diagrama BPMN.

16. Aprovação e governança

  • Quem aprova a especificação.
  • Periodicidade de revisão (semestral, anual).
  • Critérios para nova versão ou descontinuação.

Modelo exemplo

Veja abaixo uma especificação completa baseada no processo de Solicitação e Aprovação de Compras. Você pode copiar a estrutura e adaptar para o seu processo.

# COM-001 — Solicitação e Aprovação de Compras

## 1. Identificação
- **Código:** COM-001
- **Versão:** 1.2
- **Área:** Suprimentos
- **Dono:** Gerente de Suprimentos
- **Atualizado em:** 28/08/2026

## 2. Objetivo
Garantir que toda aquisição passe por validação orçamentária e alçada de aprovação adequada.

## 3. Escopo
- **Início:** Necessidade de material ou serviço identificada pela área requisitante.
- **Fim:** Pedido de compra emitido ao fornecedor homologado.
- **Incluso:** Solicitação, validação orçamentária, aprovações e emissão do pedido.
- **Excluso:** Pagamento ao fornecedor e recebimento físico da mercadoria.

## 4. Contexto
Processo vinculado à política de compras da empresa e ao controle orçamentário do ERP.

## 5. Gatilho
Requisição interna de compra aberta no sistema pelo solicitante.

## 6. Entradas e saídas
- **Entradas:** requisição interna, orçamento aprovado da área, catálogo de fornecedores.
- **Saídas:** pedido de compra emitido, registro de aprovação, reserva orçamentária.

## 7. Partes interessadas
- Solicitante (executa a requisição)
- Gestor da área (aprova até R$ 10.000)
- Diretoria (aprova acima de R$ 10.000)
- Suprimentos (emite o pedido)
- ERP (valida saldo orçamentário)

## 8. Raias e pools
- Pool "Empresa": raias "Solicitante", "Gestor", "Diretoria", "Suprimentos".
- Pool "Sistemas": raia "ERP".

## 9. Fluxo detalhado
1. Requisição de compra é registrada.
2. ERP valida saldo orçamentário.
3. Gateway verifica valor:
   - Acima de R$ 10.000 → aprovação da diretoria.
   - Até R$ 10.000 → aprovação do gestor.
4. Suprimentos emite o pedido ao fornecedor homologado.
5. Processo encerra com o pedido emitido.

## 10. Regras de negócio
- RN-01: compras acima de R$ 10.000 exigem aprovação de diretoria.
- RN-02: só é permitido comprar de fornecedor homologado.
- RN-03: sem saldo orçamentário, a solicitação é devolvida.

## 11. Sistemas e integrações
- ERP (módulo de compras)
- Portal do Fornecedor
- E-mail corporativo

## 12. Indicadores
- Lead time médio da solicitação ao pedido (meta: 5 dias úteis).
- % de compras fora da política.

## 13. Riscos e controles
- Risco: aprovação fora de alçada → Controle: configuração de limites no ERP.
- Risco: compra sem cobertura orçamentária → Controle: bloqueio automático de saldo.

## 14. Exceções
- Compra emergencial: aprovação verbal do diretor com regularização em até 48h.

## 15. Documentos
- Formulário de requisição de compras
- Política de compras v3.1

## 16. Aprovação e governança
- Aprovação: Gerente de Suprimentos
- Revisão anual ou em caso de mudança na política de compras.

Gerar a especificação em outra IA e importar

O Btor Modeler lê um formato JSON próprio (btor-spec-1). Peça a qualquer IA para gerar a especificação nesse padrão, importe o arquivo e o modelador desenha o fluxo BPMN (pool, raias, decisões e condições), preenche a especificação, gera a narrativa, valida o modelo e libera o relatório executivo de saída.

  1. Abra a tela Importar de IA e copie o prompt padrão.
  2. Cole o prompt na IA de sua preferência junto com a descrição do seu processo.
  3. Cole o JSON de volta no Btor Modeler e clique em “Gerar fluxo e especificação”.
  4. Ajuste o diagrama no modelador e exporte BPMN, especificação e relatório executivo.

Prompt padrão

Você é um analista de processos. Gere APENAS um JSON válido (sem markdown, sem comentários)
no formato "btor-spec-1" do Btor Modeler, descrevendo o processo solicitado.

Estrutura obrigatória:
{
  "versaoSchema": "btor-spec-1",
  "processo": { "nome": "", "codigo": "", "area": "", "dono": "", "versao": "1.0", "descricao": "" },
  "especificacao": {
    "objetivo": "", "escopo": "", "gatilho": "", "entradas": "", "saidas": "",
    "regras": "", "sistemas": "", "indicadores": "", "riscos": "", "excecoes": ""
  },
  "raias": ["Nome da raia 1", "Nome da raia 2"],
  "elementos": [
    { "id": "e1", "tipo": "inicio", "nome": "Evento de início", "raia": "Nome da raia 1" },
    { "id": "t1", "tipo": "tarefaUsuario", "nome": "Atividade", "raia": "Nome da raia 1", "sistema": "ERP", "descricao": "" }
  ],
  "fluxos": [ { "de": "e1", "para": "t1", "condicao": "" } ]
}

Regras:
- "tipo" deve ser um de: inicio | fim | tarefa | tarefaUsuario | tarefaServico | tarefaManual | subprocesso | decisao | paralelo | eventoIntermediario.
- Todo "id" é único; todo fluxo referencia ids existentes.
- Deve haver ao menos um elemento "inicio" e um "fim".
- Toda saída de "decisao" deve ter "condicao" preenchida (ex.: "Sim", "Não", "Valor > 10.000").
- "raia" indica o papel/área responsável pela execução do elemento.
- Campos de texto em português, objetivos e específicos. Regras de negócio numeradas (RN-01, RN-02...).
- Responda somente com o JSON.

Exemplo de arquivo aceito

{
  "versaoSchema": "btor-spec-1",
  "processo": {
    "nome": "Solicitação e Aprovação de Compras",
    "codigo": "SUP-001",
    "area": "Suprimentos",
    "dono": "Gerência de Suprimentos",
    "versao": "1.0",
    "descricao": "Da identificação da necessidade até a emissão do pedido ao fornecedor."
  },
  "especificacao": {
    "objetivo": "Garantir que toda aquisição passe por validação orçamentária e alçada adequada.",
    "escopo": "Inicia na necessidade da área requisitante e termina com o pedido emitido.",
    "gatilho": "Necessidade de material ou serviço identificada.",
    "entradas": "Requisição interna; orçamento da área; catálogo de fornecedores.",
    "saidas": "Pedido de compra emitido; registro de aprovação.",
    "regras": "RN-01 Acima de R$ 10.000 exige diretoria.\nRN-02 Só fornecedor homologado.",
    "sistemas": "ERP (compras); Portal do Fornecedor.",
    "indicadores": "Lead time da solicitação ao pedido (meta 5 dias úteis).",
    "riscos": "Aprovação fora de alçada; compra sem cobertura orçamentária.",
    "excecoes": "Compra emergencial regularizada em até 48h."
  },
  "raias": [
    "Requisitante",
    "Suprimentos",
    "Diretoria"
  ],
  "elementos": [
    {
      "id": "e1",
      "tipo": "inicio",
      "nome": "Necessidade identificada",
      "raia": "Requisitante"
    },
    {
      "id": "t1",
      "tipo": "tarefaUsuario",
      "nome": "Registrar solicitação",
      "raia": "Requisitante"
    },
    {
      "id": "t2",
      "tipo": "tarefaServico",
      "nome": "Validar orçamento no ERP",
      "raia": "Suprimentos",
      "sistema": "ERP"
    },
    {
      "id": "g1",
      "tipo": "decisao",
      "nome": "Valor acima de R$ 10.000?",
      "raia": "Suprimentos"
    },
    {
      "id": "t3",
      "tipo": "tarefaUsuario",
      "nome": "Aprovar na diretoria",
      "raia": "Diretoria"
    },
    {
      "id": "t4",
      "tipo": "tarefaUsuario",
      "nome": "Aprovar com gestor",
      "raia": "Suprimentos"
    },
    {
      "id": "t5",
      "tipo": "tarefa",
      "nome": "Emitir pedido ao fornecedor",
      "raia": "Suprimentos"
    },
    {
      "id": "e2",
      "tipo": "fim",
      "nome": "Pedido emitido",
      "raia": "Suprimentos"
    }
  ],
  "fluxos": [
    {
      "de": "e1",
      "para": "t1"
    },
    {
      "de": "t1",
      "para": "t2"
    },
    {
      "de": "t2",
      "para": "g1"
    },
    {
      "de": "g1",
      "para": "t3",
      "condicao": "Sim"
    },
    {
      "de": "g1",
      "para": "t4",
      "condicao": "Não"
    },
    {
      "de": "t3",
      "para": "t5"
    },
    {
      "de": "t4",
      "para": "t5"
    },
    {
      "de": "t5",
      "para": "e2"
    }
  ]
}

Relatório executivo de saída: além da especificação, o Btor Modeler gera um relatório em formato de análise de mercado, com sumário executivo, principais achados, premissas, avaliação de maturidade (escala 1 a 5), recomendações priorizadas por impacto e esforço, riscos, indicadores e roadmap (0–30 dias, 0–90 dias, 3–12 meses).

Ir para a importação por IA

Dica rápida

Comece desenhando o fluxo principal no modelador BPMN. Depois, volte à aba "Especificação" e preencha cada tópico na ordem sugerida. A narrativa e a validação são geradas automaticamente a partir do diagrama.