O que é BPMN

BPMN (Business Process Model and Notation) é uma linguagem gráfica padronizada para descrever processos de negócio: quem faz o quê, em que ordem, com quais decisões e o que acontece quando algo sai do previsto.

A própria norma define o objetivo: ser compreensível por todos os envolvidos, dos analistas que fazem o primeiro rascunho aos desenvolvedores que implementam e às pessoas que gerenciam o processo. Ela chama isso de ponte entre o desenho e a implementação. ^[1]

Você não precisa conhecer todos os símbolos para começar. Eventos, tarefas, gateways e fluxos de sequência já resolvem boa parte dos diagramas. Este tutorial vai nessa ordem e usa o BPMN Simulator, um app em um único arquivo HTML: nada é enviado para a rede, e os diagramas ficam no seu navegador.

Abrir o BPMN Simulator →

Uma breve história

O BPMN nasceu da necessidade de uma notação comum entre analistas e tecnologia. A linha do tempo abaixo traz os marcos, com as datas das fontes consultadas.

• 2004. A Business Process Management Initiative (BPMI.org) anuncia o BPMN 1.0, então chamado Business Process Modeling Notation. Stephen White, da IBM, presidia o grupo de trabalho. Pelo menos 20 empresas se comprometeram a dar suporte à notação. ^[3]
• 2005. A BPMI se funde à Object Management Group (OMG), que passa a manter a norma. ^[5][6]
• 2007 a 2009. A OMG registra a versão 1.0 formal em março de 2007, a 1.1 em janeiro de 2008 e a 1.2 em janeiro de 2009. ^[2][1]
• 2010. O BPMN 2.0 acrescenta semântica de execução e um formato de intercâmbio com diagrama. O nome muda para Model and Notation, mantendo a sigla. ^[4][5]
• 2013. A norma é publicada também como ISO/IEC 19510. ^[7]
• 2014. A versão 2.0.2, com publicação em janeiro, é a atual na OMG. A única mudança declarada em relação à anterior está na cláusula 15. ^[1]

As fontes nem sempre concordam nos detalhes, e as divergências estão anotadas nas referências. O app segue a versão 2.0.2.

Definições essenciais

Os elementos da notação

Quase todo diagrama usa quatro famílias de elementos. A forma indica a família, e o ícone interno indica o tipo.

Eventos

A borda indica a posição: fina no início, dupla no meio e grossa no fim. O ícone indica o gatilho ou o resultado. Ícone vazado captura algo, e preenchido dispara. O app só oferece as combinações permitidas pela Tabela 10.93 da norma. ^[1]

Atividades

A tarefa é a unidade de trabalho, e o ícone no canto informa o tipo: usuário, serviço, manual, envio, recebimento, script ou regra de negócio. O + embaixo indica um subprocesso recolhido. Três barras indicam múltiplas instâncias, e a seta circular indica repetição.

Gateways

O símbolo dentro do losango muda completamente o comportamento. Sempre pergunte: quantas fichas saem e quantas a junção espera?

Como a ficha anda

A execução fica fácil de entender quando você acompanha uma ficha. O evento de início cria a ficha. Ela segue pelas setas, fica na atividade enquanto o trabalho dura e, no gateway, obedece à regra daquele tipo. O evento de fim a consome, e a instância termina quando não restam fichas nem atividades em andamento. ^[1]

Daí vem o erro mais comum de iniciantes: abrir caminhos com um tipo de gateway e fechar com outro.

O contrário também atrapalha: se um paralelo abre e um exclusivo fecha, cada ficha passa sozinha e o que vem depois roda duas vezes. A norma também trata o caso de uma condição não valer: em um gateway exclusivo sem condição verdadeira e sem fluxo padrão, ocorre uma exceção (Tabela 13.2). ^[1]

A tela do app

Selecione um elemento para ver as ações ao lado dele: acrescentar o próximo passo, conectar ou excluir. Com duplo clique ou F2 você escreve o nome. O próprio app escolhe o tipo de conexão conforme a norma e recusa, mostrando o motivo, as ligações proibidas, como um fluxo de sequência saindo de um evento de fim.

No menu Arquivo há cinco exemplos prontos, para explorar antes de desenhar. Admissão de funcionário mostra subprocessos, e Central de atendimento mostra filas.

Seu primeiro processo

Vamos desenhar uma versão curta deste reembolso. Faça cada passo no app, sem pressa:

1. Abra o BPMN Simulator e arraste um Evento de início para a área de desenho. Com duplo clique, escreva Despesa enviada.
2. Com o evento selecionado, clique em Acrescentar tarefa no painel ao lado dele e escreva Conferir comprovante.
3. Com a tarefa selecionada, clique em Acrescentar gateway e chame-o de Comprovante válido?. Nome de gateway de decisão funciona bem como pergunta.
4. A partir do gateway, acrescente a tarefa Pagar reembolso e, depois dela, um evento de fim Reembolso pago.
5. Selecione de novo o gateway e acrescente outro evento de fim: Pedido recusado.
6. Clique na seta que vai para Pagar reembolso. Em Propriedades, escreva o nome Sim e a Condição comprovante_ok.
7. Clique na outra seta, escreva o nome Não e marque É o fluxo padrão. Uma barrinha aparece na origem da seta.
8. Clique na área vazia e, em Dados iniciais, escreva comprovante_ok = chance(0.9). Em cada caso, há 90% de chance de o comprovante valer.
9. Abra a aba Verificar. Não deve haver erros de norma. Se houver, clique no item para ir até o elemento.

Para salvar, use Arquivo → Salvar .bpmn. O arquivo segue o formato BPMN 2.0 XML da norma, e outras ferramentas compatíveis podem abri-lo.

Simular

Clique em Simular. O relógio é virtual, em minutos, e a mesma Semente repete a mesma execução. Há quatro formas de usar:

Para quem está aprendendo, o Passo a passo é o melhor começo. Durações e efeitos ficam em cada atividade (random(5, 15), exponential(10), normal(10, 2)). Probabilidades ficam nos fluxos, e a capacidade fica em cada raia.

Um experimento com filas

Abra o exemplo Central de atendimento, com 2 atendentes e 1 especialista. Na aba Muitas execuções, rode 500 casos com uma chegada a cada 3 minutos em média. A tabela mostra o tempo de ciclo médio em 20 sementes, com a margem de 95%:

As duas raias começam muito ocupadas, mas dobrar os especialistas muda pouco: as margens se sobrepõem. Um atendente a mais faz o tempo cair muito, porque todo chamado passa por eles. Só com os dois reforços o tempo fica perto do trabalho em si. Isso é só um modelo, com números inventados para o exemplo: serve para comparar hipóteses, não para medir o processo real.

Cenários de teste

Simular mostra o que acontece. Testar confere se é o que deveria acontecer. Na aba Cenários de teste, cada cenário define entradas e resultado esperado, e o app dá o veredito.

O exemplo Pedido online já traz três cenários. Clique em Rodar todos e abra os detalhes. Depois experimente:

• Sugerir cenários: cria um cenário por caminho que acrescenta cobertura. Ele força as decisões e preenche o esperado com o que aconteceu, então revise se aquilo é mesmo o certo.
• Cobertura: o que nunca executou fica tracejado no diagrama. Cobertura de 100% não prova que o processo está correto: só diz que cada elemento rodou ao menos uma vez.
• Repetições: roda com várias sementes e aponta a que falhou, para modelos com sorteios.
• Salvar execução como cenário: guarda uma execução manual terminada, para repetir depois.

Verificar o modelo

A aba Verificar confere o modelo em dois níveis:

• Regras da norma: eventos permitidos em cada posição, conexões das Tabelas 7.3 e 7.4, fluxo padrão com condição e outras. Clicar no item leva ao elemento. ^[1]
• Análise de fichas: o botão Analisar percorre os estados possíveis de cada escopo e aponta impasses, laços sem saída, falta de sincronização e o que nunca executa. Ela supõe que qualquer caminho é possível, ignorando os dados. Por isso, pode acusar um caminho que seus dados nunca percorrem.

A importação do app foi conferida com 12 arquivos da suíte de intercâmbio do grupo MIWG, e os arquivos reexportados passaram no esquema XSD oficial. ^[8] Isso não é certificação: o app não é certificado pela OMG e não é um motor de produção. Diagramas de conversa e de coreografia ficam de fora. Os limites completos estão na Ajuda do app.

Prompts de IA

Uma IA ajuda a sair da página em branco, a achar lacunas e a escrever cenários. Ela também erra com segurança: inventa regras, esquece exceções e pode gerar XML inválido. Trate a saída como rascunho de um colega apressado. Para escrever prompts melhores, veja o tutorial de prompts.

Antes de colar: processos internos podem conter nomes, valores e regras sigilosas. Troque por dados fictícios e siga a política da sua organização para uso de IA. O app não envia nada para a rede, mas o serviço de IA recebe o que você colar nele.

Troque os trechos entre colchetes e cole na ferramenta de IA que você usa.

1. Entrevistar antes de desenhar

Faz a IA descobrir o que falta, em vez de supor. É o melhor começo quando o processo ainda está na cabeça das pessoas.

Você é um analista de processos experiente em BPMN 2.0.2.
Quero modelar este processo: [descreva em poucas frases].

Antes de propor qualquer diagrama, me entreviste:
- Faça uma pergunta por vez e espere minha resposta.
- Cubra: o que inicia o processo, quem participa, as etapas, as decisões e seus critérios, as exceções, os prazos, as esperas, os sistemas e o que indica o fim.
- Pergunte principalmente sobre o que dá errado, não só sobre o caminho feliz.
- Não invente respostas. Se eu não souber, registre como pendência.

Ao final, entregue: resumo do processo, tabela de atividades (atividade, responsável, entrada, saída), lista de decisões com critérios e lista de pendências.

2. Transformar um texto em estrutura

Para atas, procedimentos ou transcrições. Pede a origem de cada item, o que facilita conferir.

A partir do texto abaixo, extraia a estrutura de um processo para BPMN.

Regras:
- Use só o que está no texto. Para cada item, cite o trecho de origem.
- Marque como [SUPOSIÇÃO] tudo que você deduziu.
- Liste as contradições e o que falta saber.

Entregue: participantes, atividades em ordem, decisões (pergunta, opções, critério), eventos (o que inicia, termina, interrompe ou espera) e pendências.

Texto:
"""
[cole aqui, sem dados sensíveis]
"""

3. Gerar o BPMN para o BPMN Simulator

Gera um arquivo que o app abre, arruma e simula. Cole a resposta em Arquivo → Ver ou colar XML e clique em Aplicar XML. Depois vá a Verificar.

Gere um documento BPMN 2.0 XML, válido no esquema da OMG, para este processo:
[descreva o processo ou cole a estrutura].

Formato obrigatório:
- Raiz <definitions> com targetNamespace e estes namespaces:
  xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:sim="https://giovanipm.github.io/ns/bpmn-simulator"
- Um <process> com isExecutable="false". Se houver mais de um participante, use <collaboration> com <participant> e <messageFlow>, com um processo para cada participante.
- Não gere <bpmndi:BPMNDiagram>: o app arruma o desenho.
- IDs únicos e legíveis. Cada nó com <incoming> e <outgoing>, nessa ordem, antes das definições de evento.
- Em todo gateway exclusivo que decide, um fluxo padrão com o atributo default, e condições nos outros fluxos com <conditionExpression xsi:type="tFormalExpression">.
- Feche caminhos paralelos com gateway paralelo. Não use evento intermediário de captura sem definição de evento.

Para a simulação, use extensionElements, antes de <incoming>:
- No processo: <sim:config init="campo = expressão"/>, com &#10; entre as linhas.
- Nas atividades: <sim:config duration="random(5, 15)"/>, em minutos.
- Nas condições, use campos e os operadores: > >= < <= == != and or not.
- Funções disponíveis: random(a, b), exponential(m), normal(m, d), chance(p), round(x, d).

Responda só com o XML. No fim, dentro de um comentário XML, liste as suposições que você fez.

4. Revisar um modelo

Copie o XML em Ver ou colar XML. A IA olha o sentido do processo, que as regras automáticas não enxergam.

Revise este processo BPMN como um analista experiente.

Confira, nesta ordem:
1. Sentido de negócio: etapas ausentes, responsáveis estranhos, exceções sem tratamento.
2. Fluxo: impasses, caminhos sem fim, gateways que abrem de um tipo e fecham de outro.
3. Clareza: nomes de atividade com verbo e objeto, decisões em forma de pergunta.
4. Norma BPMN 2.0.2: conexões proibidas e eventos fora de posição.

Para cada problema, informe: id do elemento, problema, por que importa, correção sugerida e gravidade (alta, média, baixa). Separe o que é certeza do que é suspeita. Não invente regras do negócio: se depender delas, faça uma pergunta.

XML:
"""
[cole aqui]
"""

5. Explicar o processo em linguagem simples

Bom para validar com quem faz o trabalho e não lê BPMN.

Explique o processo abaixo para [público, como: equipe de atendimento], sem termos de BPMN.

Entregue:
- Em duas frases: para que serve e quando começa.
- O passo a passo, indicando quem faz o quê.
- Cada decisão, como pergunta, e o que acontece em cada resposta.
- O que acontece quando algo dá errado ou atrasa.
- Cinco perguntas para eu confirmar com a equipe se o desenho corresponde ao trabalho real.

Descreva só o que está no modelo. Se algo estiver ambíguo, diga isso.

XML:
"""
[cole aqui]
"""

6. Propor cenários de teste

A tabela resultante vira cenários na aba Cenários de teste. Use os ids reais do modelo.

Proponha cenários de teste para o processo BPMN abaixo.

Cubra: caminho principal, cada saída de cada decisão, valores no limite das condições, eventos de borda ocorrendo e não ocorrendo, e combinações que parecem arriscadas.

Para cada cenário, uma linha de tabela com:
- Nome
- Dado que: dados do caso, no formato campo = valor
- Quando: decisões forçadas e eventos que ocorrem ou não
- Então: elementos por onde passa e por onde não passa (com o id), e como o caso termina
- Por que este cenário importa

Marque com [REVISAR] os resultados esperados que dependem de uma regra de negócio não escrita no modelo. Prefira poucos cenários que revelem erros a muitos parecidos.

XML:
"""
[cole aqui]
"""

7. Estimar parâmetros de simulação

Sem dados reais, qualquer número é hipótese. Este prompt pede para deixar isso visível.

Quero simular este processo BPMN e preciso de durações, probabilidades e capacidades.

Dados reais que tenho: [cole médias, volumes ou escreva "nenhum"].

Para cada atividade e decisão, proponha:
- Valor em minutos, em uma destas formas: número, random(a, b), exponential(m) ou normal(m, d). Justifique a escolha.
- Origem: [DADO], se veio do que informei, ou [HIPÓTESE], se é estimativa.
- Como obter o dado real.

Depois, liste as três hipóteses que mais podem mudar o resultado, para eu testá-las primeiro.

XML:
"""
[cole aqui]
"""

8. Interpretar os resultados

Cole os números da aba Muitas execuções para discutir hipóteses, e não para obter um veredito.

Estes são os resultados de uma simulação de um processo BPMN. Os números vêm de um modelo com parâmetros estimados, não do processo real.

Processo: [descrição curta]
Parâmetros: [capacidades, durações e chegadas]
Resultados: [tempo de ciclo, ocupação por raia, filas por atividade]

Faça o seguinte:
1. Aponte o provável gargalo, usando os números.
2. Sugira no máximo três mudanças para testar, mudando uma coisa de cada vez, com o que você espera que aconteça.
3. Diga o que os dados não permitem concluir.
4. Indique o que medir no processo real antes de decidir.

Não recomende investimento com base só nessa simulação.

O que foi testado nestes prompts

O formato pedido no prompt 3 foi testado de fato: um XML nesse formato, escrito pelo Claude para um processo de reembolso, passou no esquema XSD da OMG, abriu no app, foi arrumado automaticamente e simulou até o fim. Os prompts não foram testados em outros modelos de IA, e as respostas mudam a cada vez. Por isso, a conferência em Verificar e nos cenários continua necessária.

Boas práticas e erros comuns

Revisão rápida

Tente responder antes de abrir.

Abrir o BPMN Simulator →

Referências

1. Object Management Group. Business Process Model and Notation, versão 2.0.2 (formal/13-12-09). Fonte das definições, tabelas e regras citadas, além das datas das versões 1.1, 1.2 e 2.0.2.
2. Object Management Group. BPMN 1.0: publicação formal em março de 2007, com copyright da BPMI.org de 2004.
3. BPMI.org. Comunicado de lançamento do BPMN 1.0, de 4 de maio de 2004. O cabeçalho traz 2004, e a linha da cidade traz 2003, um erro de digitação do original.
4. Object Management Group. BPMN 2.0: a OMG data de dezembro de 2010. A Wikipédia [5] cita janeiro de 2011.
5. Wikipédia. Business Process Model and Notation. Fonte da fusão em 2005 e da mudança de nome na versão 2.0. As páginas atuais da OMG usam o nome novo também para a versão 1.0.
6. Trisotech. BPMN Introduction and History. Fonte secundária, de um fabricante, para o mês da fusão (junho de 2005).
7. ISO e IEC. ISO/IEC 19510:2013; registro na IEC. Publicada em julho de 2013. As fontes divergem sobre a correspondência: a ISO indica a versão 2.0.1 da OMG, e a Trisotech [6], a 2.0.2.
8. BPMN Model Interchange Working Group. Suíte de testes de intercâmbio, usada para conferir a importação do app.

What BPMN is

BPMN (Business Process Model and Notation) is a standard graphical language for describing business processes: who does what, in what order, with which decisions, and what happens when something goes off plan.

The standard states its own goal: to be understandable by everyone involved, from the analysts who make the first draft to the developers who implement it and the people who manage the process. It calls this a bridge between design and implementation. ^[1]

You don’t need to know every symbol to begin. Events, tasks, gateways and sequence flows already cover a good part of most diagrams. This tutorial follows that order and uses the BPMN Simulator, an app in a single HTML file: nothing is sent over the network, and your diagrams stay in your browser.

Open the BPMN Simulator →

A brief history

BPMN grew out of the need for a common notation between analysts and technology. The timeline below shows the milestones, with the dates from the sources consulted.

• 2004. The Business Process Management Initiative (BPMI.org) announces BPMN 1.0, then called Business Process Modeling Notation. Stephen White, of IBM, chaired the working group. At least 20 companies committed to supporting the notation. ^[3]
• 2005. BPMI merges with the Object Management Group (OMG), which takes over the standard. ^[5][6]
• 2007 to 2009. The OMG lists formal version 1.0 in March 2007, 1.1 in January 2008 and 1.2 in January 2009. ^[2][1]
• 2010. BPMN 2.0 adds execution semantics and an interchange format that includes the diagram. The name changes to Model and Notation, keeping the acronym. ^[4][5]
• 2013. The standard is also published as ISO/IEC 19510. ^[7]
• 2014. Version 2.0.2, published in January, is the current one at the OMG. The only change it declares from the previous version is in clause 15. ^[1]

Sources do not always agree on the details, and the differences are noted in the references. The app follows version 2.0.2.

Key definitions

The elements of the notation

Almost every diagram uses four families of elements. The shape shows the family, and the inner icon shows the type.

Events

The border shows the position: thin at the start, double in the middle and thick at the end. The icon shows the trigger or the result. A hollow icon catches something, and a filled one throws. The app offers only the combinations allowed by Table 10.93 of the standard. ^[1]

Activities

A task is the unit of work, and the icon in the corner shows its type: user, service, manual, send, receive, script or business rule. A + at the bottom marks a collapsed sub-process. Three bars mark multiple instances, and a circular arrow marks a loop.

Gateways

The symbol inside the diamond completely changes the behavior. Always ask: how many tokens leave, and how many does the join wait for?

How the token moves

Execution becomes easy to understand when you follow one token. The start event creates it. It follows the arrows, stays in an activity for as long as the work lasts and, at a gateway, obeys the rule of that type. The end event consumes it, and the instance ends when no tokens or running activities remain. ^[1]

This explains the most common beginner’s mistake: opening paths with one type of gateway and closing them with another.

The reverse also causes trouble: if a parallel gateway opens and an exclusive one closes, each token passes through alone and whatever follows runs twice. The standard also covers a condition that does not hold: at an exclusive gateway with no true condition and no default flow, an exception occurs (Table 13.2). ^[1]

The app screen

Select an element to see the actions beside it: append the next step, connect or delete. Double-click or press F2 to write the name. The app itself picks the connection type according to the standard and refuses forbidden links, showing the reason, such as a sequence flow leaving an end event.

The File menu has five ready-made samples to explore before drawing. Employee onboarding shows sub-processes, and Service desk shows queues.

Your first process

Let’s draw a short version of this reimbursement. Do each step in the app, with no rush:

1. Open the BPMN Simulator and drag a Start event onto the canvas. Double-click it and write Expense submitted.
2. With the event selected, click Append task in the panel beside it and write Check receipt.
3. With the task selected, click Append gateway and name it Valid receipt?. A question works well as the name of a decision gateway.
4. From the gateway, append the task Pay reimbursement and, after it, an end event Reimbursement paid.
5. Select the gateway again and append another end event: Request declined.
6. Click the arrow that goes to Pay reimbursement. In Properties, enter the name Yes and the Condition comprovante_ok.
7. Click the other arrow, enter the name No and tick Is the default flow. A small slash appears at the start of the arrow.
8. Click the empty area and, under Initial data, write comprovante_ok = chance(0.9). In each case, the receipt has a 90% chance of being valid.
9. Open the Check tab. There should be no standard errors. If there are, click the item to go to the element.

To save, use File → Save .bpmn. The file follows the standard’s BPMN 2.0 XML format, and other compatible tools can open it.

Simulating

Click Simulate. The clock is virtual, in minutes, and the same Seed repeats the same run. There are four ways to use it:

If you are learning, Step by step is the best start. Durations and effects are set on each activity (random(5, 15), exponential(10), normal(10, 2)). Probabilities are set on the flows, and capacity on each lane.

An experiment with queues

Open the Service desk sample, with 2 agents and 1 specialist. In the Many runs tab, run 500 cases with one arrival every 3 minutes on average. The table shows the mean cycle time over 20 seeds, with the 95% margin:

Both lanes start out very busy, but doubling the specialists changes little: the margins overlap. One more agent brings the time down sharply, because every ticket goes through them. Only with both additions does the time get close to the work itself. This is only a model, with numbers made up for the example: use it to compare hypotheses, not to measure the real process.

Test scenarios

Simulating shows what happens. Testing checks whether it is what should happen. In the Test scenarios tab, each scenario sets the inputs and the expected result, and the app gives the verdict.

The Online order sample already has three scenarios. Click Run all and open the details. Then try:

• Suggest scenarios: creates a scenario for each path that adds coverage. It forces the decisions and fills in the expected result with what happened, so check that it is really correct.
• Coverage: what never ran is dashed on the diagram. 100% coverage does not prove the process is correct: it only says each element ran at least once.
• Runs: runs with several seeds and points out the one that failed, for models with random draws.
• Save run as scenario: keeps a finished manual run, to repeat later.

Checking the model

The Check tab reviews the model on two levels:

• Rules of the standard: events allowed in each position, connections from Tables 7.3 and 7.4, a default flow with a condition and others. Clicking an item takes you to the element. ^[1]
• Token analysis: the Analyze button walks through the possible states of each scope and points out deadlocks, endless loops, lack of synchronization and what never runs. It assumes any path is possible and ignores the data, so it can flag a path your data never takes.

The app’s import was checked with 12 files from the MIWG group’s interchange suite, and the re-exported files passed the official XSD schema. ^[8] This is not certification: the app is not certified by the OMG and is not a production engine. Conversation and choreography diagrams are out of scope. The full limits are in the app’s Help.

AI prompts

AI helps you get past the blank page, find gaps and write scenarios. It also makes mistakes with confidence: it invents rules, forgets exceptions and may produce invalid XML. Treat its output as a draft from a colleague in a hurry. To write better prompts, see the prompts tutorial.

Before pasting: internal processes may contain confidential names, amounts and rules. Replace them with fictitious data and follow your organization’s AI policy. The app sends nothing over the network, but the AI service receives whatever you paste into it.

Replace the parts in square brackets and paste into the AI tool you use.

1. Interview before drawing

Makes the AI find out what is missing instead of assuming. It is the best start when the process is still in people’s heads.

You are a process analyst experienced in BPMN 2.0.2.
I want to model this process: [describe it in a few sentences].

Before proposing any diagram, interview me:
- Ask one question at a time and wait for my answer.
- Cover: what starts the process, who takes part, the steps, the decisions and their criteria, the exceptions, the deadlines, the waits, the systems and what marks the end.
- Ask mainly about what goes wrong, not only about the happy path.
- Do not invent answers. If I don't know, record it as an open item.

At the end, deliver: a summary of the process, a table of activities (activity, owner, input, output), a list of decisions with criteria and a list of open items.

2. Turn a text into structure

For minutes, procedures or transcripts. It asks for the origin of each item, which makes checking easier.

From the text below, extract the structure of a process for BPMN.

Rules:
- Use only what is in the text. For each item, quote the source passage.
- Mark as [ASSUMPTION] anything you inferred.
- List contradictions and what is still unknown.

Deliver: participants, activities in order, decisions (question, options, criterion), events (what starts, ends, interrupts or waits) and open items.

Text:
"""
[paste here, with no sensitive data]
"""

3. Generate BPMN for the BPMN Simulator

Generates a file the app opens, lays out and simulates. Paste the answer into File → View or paste XML and click Apply XML. Then go to Check.

Generate a BPMN 2.0 XML document, valid against the OMG schema, for this process:
[describe the process or paste the structure].

Required format:
- Root <definitions> with targetNamespace and these namespaces:
  xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:sim="https://giovanipm.github.io/ns/bpmn-simulator"
- One <process> with isExecutable="false". If there is more than one participant, use <collaboration> with <participant> and <messageFlow>, with one process for each participant.
- Do not generate <bpmndi:BPMNDiagram>: the app lays out the drawing.
- Unique, readable IDs. Each node with <incoming> and <outgoing>, in that order, before the event definitions.
- At every exclusive gateway that decides, a default flow with the default attribute, and conditions on the other flows with <conditionExpression xsi:type="tFormalExpression">.
- Close parallel paths with a parallel gateway. Do not use an intermediate catch event without an event definition.

For the simulation, use extensionElements, before <incoming>:
- On the process: <sim:config init="field = expression"/>, with &#10; between lines.
- On activities: <sim:config duration="random(5, 15)"/>, in minutes.
- In conditions, use fields and the operators: > >= < <= == != and or not.
- Available functions: random(a, b), exponential(m), normal(m, d), chance(p), round(x, d).

Reply only with the XML. At the end, inside an XML comment, list the assumptions you made.

4. Review a model

Copy the XML from View or paste XML. The AI looks at the meaning of the process, which automatic rules cannot see.

Review this BPMN process as an experienced analyst.

Check, in this order:
1. Business sense: missing steps, odd owners, unhandled exceptions.
2. Flow: deadlocks, paths with no end, gateways that open with one type and close with another.
3. Clarity: activity names with a verb and an object, decisions phrased as questions.
4. BPMN 2.0.2 standard: forbidden connections and events out of position.

For each problem, give: element id, problem, why it matters, suggested fix and severity (high, medium, low). Separate what is certain from what is a suspicion. Do not invent business rules: if something depends on them, ask a question.

XML:
"""
[paste here]
"""

5. Explain the process in plain language

Good for validating with those who do the work and don’t read BPMN.

Explain the process below to [audience, such as: the customer service team], with no BPMN terms.

Deliver:
- In two sentences: what it is for and when it starts.
- The step by step, showing who does what.
- Each decision, as a question, and what happens with each answer.
- What happens when something goes wrong or runs late.
- Five questions for me to confirm with the team whether the drawing matches the real work.

Describe only what is in the model. If something is ambiguous, say so.

XML:
"""
[paste here]
"""

6. Propose test scenarios

The resulting table becomes scenarios in the Test scenarios tab. Use the model’s real ids.

Propose test scenarios for the BPMN process below.

Cover: the main path, each outcome of each decision, values at the limit of the conditions, boundary events occurring and not occurring, and combinations that look risky.

For each scenario, one table row with:
- Name
- Given: case data, in the format field = value
- When: forced decisions and events that occur or not
- Then: elements it goes through and does not go through (with the id), and how the case ends
- Why this scenario matters

Mark with [REVIEW] the expected results that depend on a business rule not written in the model. Prefer a few scenarios that reveal errors to many similar ones.

XML:
"""
[paste here]
"""

7. Estimate simulation parameters

Without real data, any number is a hypothesis. This prompt asks to keep that visible.

I want to simulate this BPMN process and need durations, probabilities and capacities.

Real data I have: [paste averages, volumes or write "none"].

For each activity and decision, propose:
- A value in minutes, in one of these forms: a number, random(a, b), exponential(m) or normal(m, d). Justify the choice.
- Origin: [DATA], if it came from what I provided, or [HYPOTHESIS], if it is an estimate.
- How to obtain the real figure.

Then list the three hypotheses most likely to change the result, so I can test them first.

XML:
"""
[paste here]
"""

8. Interpret the results

Paste the figures from the Many runs tab to discuss hypotheses, not to get a verdict.

These are the results of a simulation of a BPMN process. The figures come from a model with estimated parameters, not from the real process.

Process: [short description]
Parameters: [capacities, durations and arrivals]
Results: [cycle time, utilization per lane, queues per activity]

Do the following:
1. Point out the likely bottleneck, using the figures.
2. Suggest at most three changes to test, changing one thing at a time, with what you expect to happen.
3. Say what the data does not allow us to conclude.
4. State what to measure in the real process before deciding.

Do not recommend investment based on this simulation alone.

What was tested in these prompts

The format requested in prompt 3 was actually tested: an XML in that format, written by Claude for a reimbursement process, passed the OMG XSD schema, opened in the app, was laid out automatically and simulated to the end. The prompts were not tested on other AI models, and answers vary each time. So checking in Check and with scenarios is still necessary.

Good practices and common mistakes

Quick review

Try to answer before opening.

Open the BPMN Simulator →

References

1. Object Management Group. Business Process Model and Notation, version 2.0.2 (formal/13-12-09). Source of the definitions, tables and rules cited, and of the dates of versions 1.1, 1.2 and 2.0.2.
2. Object Management Group. BPMN 1.0: formal publication in March 2007, with a 2004 BPMI.org copyright.
3. BPMI.org. BPMN 1.0 release announcement, May 4, 2004. The header says 2004 and the dateline says 2003, a typo in the original.
4. Object Management Group. BPMN 2.0: the OMG dates it December 2010. Wikipedia [5] says January 2011.
5. Wikipedia. Business Process Model and Notation. Source of the 2005 merger and of the name change at version 2.0. Current OMG pages also use the new name for version 1.0.
6. Trisotech. BPMN Introduction and History. A secondary source, from a vendor, for the month of the merger (June 2005).
7. ISO and IEC. ISO/IEC 19510:2013; IEC record. Published in July 2013. Sources differ on the match: ISO points to OMG version 2.0.1, and Trisotech [6] to 2.0.2.
8. BPMN Model Interchange Working Group. Interchange test suite, used to check the app’s import.

Che cos’è il BPMN

Il BPMN (Business Process Model and Notation) è un linguaggio grafico standard per descrivere i processi aziendali: chi fa cosa, in quale ordine, con quali decisioni e che cosa succede quando qualcosa va diversamente dal previsto.

La norma stessa ne definisce l’obiettivo: essere comprensibile a tutti gli interessati, dagli analisti che fanno la prima bozza agli sviluppatori che implementano e alle persone che gestiscono il processo. La chiama un ponte tra il disegno e l’implementazione. ^[1]

Non serve conoscere tutti i simboli per iniziare. Eventi, attività, gateway e flussi di sequenza coprono già buona parte dei diagrammi. Questo tutorial segue quest’ordine e usa il BPMN Simulator, un’app in un unico file HTML: nulla viene inviato in rete e i diagrammi restano nel tuo browser.

Apri il BPMN Simulator →

Una breve storia

Il BPMN nasce dal bisogno di una notazione comune tra analisti e tecnologia. La cronologia qui sotto riporta le tappe, con le date delle fonti consultate.

• 2004. La Business Process Management Initiative (BPMI.org) annuncia il BPMN 1.0, allora chiamato Business Process Modeling Notation. Stephen White, di IBM, presiedeva il gruppo di lavoro. Almeno 20 aziende si impegnarono a supportare la notazione. ^[3]
• 2005. BPMI si fonde con l’Object Management Group (OMG), che assume la gestione della norma. ^[5][6]
• Dal 2007 al 2009. OMG registra la versione 1.0 formale nel marzo 2007, la 1.1 nel gennaio 2008 e la 1.2 nel gennaio 2009. ^[2][1]
• 2010. Il BPMN 2.0 aggiunge la semantica di esecuzione e un formato di interscambio che include il diagramma. Il nome diventa Model and Notation, mantenendo la sigla. ^[4][5]
• 2013. La norma viene pubblicata anche come ISO/IEC 19510. ^[7]
• 2014. La versione 2.0.2, pubblicata a gennaio, è quella attuale presso OMG. L’unica modifica dichiarata rispetto alla precedente riguarda la clausola 15. ^[1]

Le fonti non sempre concordano sui dettagli, e le differenze sono annotate nei riferimenti. L’app segue la versione 2.0.2.

Definizioni essenziali

Gli elementi della notazione

Quasi ogni diagramma usa quattro famiglie di elementi. La forma indica la famiglia, e l’icona interna indica il tipo.

Eventi

Il bordo indica la posizione: sottile all’inizio, doppio nel mezzo e spesso alla fine. L’icona indica il trigger o il risultato. L’icona vuota riceve qualcosa, quella piena invia. L’app offre solo le combinazioni consentite dalla Tabella 10.93 della norma. ^[1]

Attività

L’attività è l’unità di lavoro, e l’icona nell’angolo ne indica il tipo: utente, servizio, manuale, invio, ricezione, script o regola di business. Il + in basso indica un sottoprocesso compresso. Tre barre indicano istanze multiple, e la freccia circolare indica una ripetizione.

Gateway

Il simbolo dentro il rombo cambia completamente il comportamento. Chiediti sempre: quanti token escono e quanti ne attende l’unione?

Come si muove il token

L’esecuzione diventa facile da capire se segui un token. L’evento di inizio lo crea. Il token segue le frecce, resta nell’attività per tutta la durata del lavoro e, al gateway, obbedisce alla regola di quel tipo. L’evento di fine lo consuma, e l’istanza termina quando non restano token né attività in corso. ^[1]

Da qui nasce l’errore più comune dei principianti: aprire i percorsi con un tipo di gateway e chiuderli con un altro.

Anche il contrario crea problemi: se un parallelo apre e un esclusivo chiude, ogni token passa da solo e ciò che segue viene eseguito due volte. La norma tratta anche il caso di una condizione non soddisfatta: in un gateway esclusivo senza condizione vera e senza flusso predefinito si verifica un’eccezione (Tabella 13.2). ^[1]

La schermata dell’app

Seleziona un elemento per vedere le azioni accanto: aggiungere il passo successivo, collegare o eliminare. Con doppio clic o F2 scrivi il nome. L’app stessa sceglie il tipo di collegamento secondo la norma e rifiuta, mostrando il motivo, i collegamenti vietati, come un flusso di sequenza che esce da un evento di fine.

Nel menu File ci sono cinque esempi pronti da esplorare prima di disegnare. Assunzione del dipendente mostra i sottoprocessi, e Centro assistenza mostra le code.

Il tuo primo processo

Disegniamo una versione breve di questo rimborso. Fai ogni passo nell’app, senza fretta:

1. Apri il BPMN Simulator e trascina un Evento di inizio sull’area di disegno. Con doppio clic, scrivi Spesa inviata.
2. Con l’evento selezionato, fai clic su Aggiungi attività nel pannello accanto e scrivi Verificare ricevuta.
3. Con l’attività selezionata, fai clic su Aggiungi gateway e chiamalo Ricevuta valida?. Una domanda funziona bene come nome di un gateway di decisione.
4. Dal gateway, aggiungi l’attività Pagare rimborso e, dopo di essa, un evento di fine Rimborso pagato.
5. Seleziona di nuovo il gateway e aggiungi un altro evento di fine: Richiesta rifiutata.
6. Fai clic sulla freccia verso Pagare rimborso. In Proprietà, scrivi il nome Sì e la Condizione comprovante_ok.
7. Fai clic sull’altra freccia, scrivi il nome No e seleziona È il flusso predefinito. All’origine della freccia appare una barretta.
8. Fai clic sull’area vuota e, in Dati iniziali, scrivi comprovante_ok = chance(0.9). In ogni caso, la ricevuta ha il 90% di probabilità di essere valida.
9. Apri la scheda Verifica. Non dovrebbero esserci errori di norma. Se ci sono, fai clic sulla voce per andare all’elemento.

Per salvare, usa File → Salva .bpmn. Il file segue il formato BPMN 2.0 XML della norma, e altri strumenti compatibili possono aprirlo.

Simulare

Fai clic su Simula. L’orologio è virtuale, in minuti, e lo stesso Seme ripete la stessa esecuzione. Ci sono quattro modi di usarlo:

Per chi sta imparando, Passo dopo passo è il miglior inizio. Durate ed effetti si impostano su ogni attività (random(5, 15), exponential(10), normal(10, 2)). Le probabilità si impostano sui flussi, e la capacità su ogni corsia.

Un esperimento con le code

Apri l’esempio Centro assistenza, con 2 operatori e 1 specialista. Nella scheda Molte esecuzioni, esegui 500 casi con un arrivo ogni 3 minuti in media. La tabella mostra il tempo di ciclo medio su 20 semi, con il margine del 95%:

Le due corsie partono molto occupate, ma raddoppiare gli specialisti cambia poco: i margini si sovrappongono. Un operatore in più fa scendere molto il tempo, perché tutti i ticket passano da loro. Solo con entrambi i rinforzi il tempo si avvicina a quello del lavoro stesso. È solo un modello, con numeri inventati per l’esempio: serve a confrontare ipotesi, non a misurare il processo reale.

Scenari di test

Simulare mostra ciò che accade. Testare verifica se è ciò che dovrebbe accadere. Nella scheda Scenari di test, ogni scenario definisce gli ingressi e il risultato atteso, e l’app dà il verdetto.

L’esempio Ordine online ha già tre scenari. Fai clic su Esegui tutti e apri i dettagli. Poi prova:

• Suggerisci scenari: crea uno scenario per ogni percorso che aumenta la copertura. Forza le decisioni e compila l’atteso con ciò che è successo, quindi verifica che sia davvero corretto.
• Copertura: ciò che non è mai stato eseguito è tratteggiato nel diagramma. Una copertura del 100% non prova che il processo sia corretto: dice solo che ogni elemento è stato eseguito almeno una volta.
• Ripetizioni: esegue con più semi e indica quello che ha fallito, per i modelli con estrazioni casuali.
• Salva esecuzione come scenario: conserva un’esecuzione manuale terminata, da ripetere in seguito.

Verificare il modello

La scheda Verifica controlla il modello su due livelli:

• Regole della norma: eventi consentiti in ogni posizione, collegamenti delle Tabelle 7.3 e 7.4, flusso predefinito con condizione e altre. Il clic sulla voce porta all’elemento. ^[1]
• Analisi dei token: il pulsante Analizza percorre gli stati possibili di ogni ambito e segnala stalli, cicli senza uscita, mancata sincronizzazione e ciò che non viene mai eseguito. Suppone che ogni percorso sia possibile e ignora i dati, quindi può segnalare un percorso che i tuoi dati non prendono mai.

L’importazione dell’app è stata verificata con 12 file della suite di interscambio del gruppo MIWG, e i file riesportati hanno superato lo schema XSD ufficiale. ^[8] Questa non è una certificazione: l’app non è certificata da OMG e non è un motore di produzione. I diagrammi di conversazione e coreografia sono esclusi. I limiti completi sono nella Guida dell’app.

Prompt di IA

L’IA aiuta a superare la pagina bianca, a trovare lacune e a scrivere scenari. Ma sbaglia anche con sicurezza: inventa regole, dimentica eccezioni e può generare XML non valido. Considera il risultato come la bozza di un collega di fretta. Per scrivere prompt migliori, vedi il tutorial sui prompt.

Prima di incollare: i processi interni possono contenere nomi, importi e regole riservati. Sostituiscili con dati fittizi e segui la politica della tua organizzazione sull’uso dell’IA. L’app non invia nulla in rete, ma il servizio di IA riceve ciò che vi incolli.

Sostituisci le parti tra parentesi quadre e incolla nello strumento di IA che usi.

1. Intervistare prima di disegnare

Fa sì che l’IA scopra ciò che manca invece di supporlo. È il miglior inizio quando il processo è ancora nella testa delle persone.

Sei un analista di processi esperto di BPMN 2.0.2.
Voglio modellare questo processo: [descrivilo in poche frasi].

Prima di proporre qualsiasi diagramma, intervistami:
- Fai una domanda alla volta e attendi la mia risposta.
- Copri: cosa avvia il processo, chi partecipa, i passi, le decisioni e i loro criteri, le eccezioni, le scadenze, le attese, i sistemi e cosa indica la fine.
- Chiedi soprattutto ciò che va storto, non solo il percorso ideale.
- Non inventare risposte. Se non lo so, registralo come punto aperto.

Alla fine, consegna: riassunto del processo, tabella delle attività (attività, responsabile, ingresso, uscita), elenco delle decisioni con i criteri ed elenco dei punti aperti.

2. Trasformare un testo in struttura

Per verbali, procedure o trascrizioni. Chiede l’origine di ogni voce, il che facilita la verifica.

Dal testo seguente, estrai la struttura di un processo per BPMN.

Regole:
- Usa solo ciò che è nel testo. Per ogni voce, cita il passaggio di origine.
- Segna come [IPOTESI] tutto ciò che hai dedotto.
- Elenca le contraddizioni e ciò che manca.

Consegna: partecipanti, attività in ordine, decisioni (domanda, opzioni, criterio), eventi (cosa avvia, termina, interrompe o attende) e punti aperti.

Testo:
"""
[incolla qui, senza dati sensibili]
"""

3. Generare il BPMN per il BPMN Simulator

Genera un file che l’app apre, dispone e simula. Incolla la risposta in File → Vedi o incolla XML e fai clic su Applica XML. Poi vai su Verifica.

Genera un documento BPMN 2.0 XML, valido secondo lo schema OMG, per questo processo:
[descrivi il processo o incolla la struttura].

Formato obbligatorio:
- Radice <definitions> con targetNamespace e questi namespace:
  xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:sim="https://giovanipm.github.io/ns/bpmn-simulator"
- Un <process> con isExecutable="false". Se c'è più di un partecipante, usa <collaboration> con <participant> e <messageFlow>, con un processo per ogni partecipante.
- Non generare <bpmndi:BPMNDiagram>: l'app dispone il disegno.
- ID unici e leggibili. Ogni nodo con <incoming> e <outgoing>, in quest'ordine, prima delle definizioni di evento.
- In ogni gateway esclusivo che decide, un flusso predefinito con l'attributo default, e condizioni sugli altri flussi con <conditionExpression xsi:type="tFormalExpression">.
- Chiudi i percorsi paralleli con un gateway parallelo. Non usare un evento intermedio di ricezione senza definizione di evento.

Per la simulazione, usa extensionElements, prima di <incoming>:
- Sul processo: <sim:config init="campo = espressione"/>, con &#10; tra le righe.
- Sulle attività: <sim:config duration="random(5, 15)"/>, in minuti.
- Nelle condizioni, usa campi e gli operatori: > >= < <= == != and or not.
- Funzioni disponibili: random(a, b), exponential(m), normal(m, d), chance(p), round(x, d).

Rispondi solo con l'XML. Alla fine, dentro un commento XML, elenca le ipotesi che hai fatto.

4. Rivedere un modello

Copia l’XML da Vedi o incolla XML. L’IA guarda il senso del processo, che le regole automatiche non vedono.

Rivedi questo processo BPMN come un analista esperto.

Controlla, in quest'ordine:
1. Senso di business: passi mancanti, responsabili strani, eccezioni non gestite.
2. Flusso: stalli, percorsi senza fine, gateway che aprono con un tipo e chiudono con un altro.
3. Chiarezza: nomi di attività con verbo e oggetto, decisioni in forma di domanda.
4. Norma BPMN 2.0.2: collegamenti vietati ed eventi fuori posizione.

Per ogni problema, indica: id dell'elemento, problema, perché è importante, correzione suggerita e gravità (alta, media, bassa). Separa ciò che è certo da ciò che è un sospetto. Non inventare regole di business: se dipende da esse, fai una domanda.

XML:
"""
[incolla qui]
"""

5. Spiegare il processo in modo semplice

Utile per validare con chi fa il lavoro e non legge il BPMN.

Spiega il processo seguente a [pubblico, ad esempio: il team di assistenza], senza termini BPMN.

Consegna:
- In due frasi: a cosa serve e quando inizia.
- Il passo dopo passo, indicando chi fa cosa.
- Ogni decisione, come domanda, e cosa succede con ogni risposta.
- Cosa succede quando qualcosa va storto o è in ritardo.
- Cinque domande per confermare con il team se il disegno corrisponde al lavoro reale.

Descrivi solo ciò che è nel modello. Se qualcosa è ambiguo, dillo.

XML:
"""
[incolla qui]
"""

6. Proporre scenari di test

La tabella risultante diventa scenari nella scheda Scenari di test. Usa gli id reali del modello.

Proponi scenari di test per il processo BPMN seguente.

Copri: il percorso principale, ogni uscita di ogni decisione, valori al limite delle condizioni, eventi di bordo che avvengono e non avvengono, e combinazioni che sembrano rischiose.

Per ogni scenario, una riga di tabella con:
- Nome
- Dato che: dati del caso, nel formato campo = valore
- Quando: decisioni forzate ed eventi che avvengono o no
- Allora: elementi da cui passa e da cui non passa (con l'id), e come termina il caso
- Perché questo scenario è importante

Segna con [RIVEDERE] i risultati attesi che dipendono da una regola di business non scritta nel modello. Preferisci pochi scenari che rivelano errori a molti simili.

XML:
"""
[incolla qui]
"""

7. Stimare i parametri di simulazione

Senza dati reali, ogni numero è un’ipotesi. Questo prompt chiede di renderlo visibile.

Voglio simulare questo processo BPMN e mi servono durate, probabilità e capacità.

Dati reali che ho: [incolla medie, volumi o scrivi "nessuno"].

Per ogni attività e decisione, proponi:
- Un valore in minuti, in una di queste forme: numero, random(a, b), exponential(m) o normal(m, d). Giustifica la scelta.
- Origine: [DATO], se viene da ciò che ho fornito, o [IPOTESI], se è una stima.
- Come ottenere il dato reale.

Poi elenca le tre ipotesi che possono cambiare di più il risultato, così le testo per prime.

XML:
"""
[incolla qui]
"""

8. Interpretare i risultati

Incolla i numeri della scheda Molte esecuzioni per discutere ipotesi, non per ottenere un verdetto.

Questi sono i risultati di una simulazione di un processo BPMN. I numeri vengono da un modello con parametri stimati, non dal processo reale.

Processo: [breve descrizione]
Parametri: [capacità, durate e arrivi]
Risultati: [tempo di ciclo, occupazione per corsia, code per attività]

Fai quanto segue:
1. Indica il probabile collo di bottiglia, usando i numeri.
2. Suggerisci al massimo tre cambiamenti da testare, cambiando una cosa alla volta, con ciò che ti aspetti che accada.
3. Di' cosa i dati non permettono di concludere.
4. Indica cosa misurare nel processo reale prima di decidere.

Non raccomandare investimenti basandoti solo su questa simulazione.

Cosa è stato testato in questi prompt

Il formato richiesto nel prompt 3 è stato testato davvero: un XML in quel formato, scritto da Claude per un processo di rimborso, ha superato lo schema XSD di OMG, si è aperto nell’app, è stato disposto automaticamente e simulato fino alla fine. I prompt non sono stati testati su altri modelli di IA, e le risposte cambiano ogni volta. Perciò il controllo in Verifica e con gli scenari resta necessario.

Buone pratiche ed errori comuni

Ripasso rapido

Prova a rispondere prima di aprire.

Apri il BPMN Simulator →

Riferimenti

1. Object Management Group. Business Process Model and Notation, versione 2.0.2 (formal/13-12-09). Fonte delle definizioni, tabelle e regole citate, e delle date delle versioni 1.1, 1.2 e 2.0.2.
2. Object Management Group. BPMN 1.0: pubblicazione formale nel marzo 2007, con copyright di BPMI.org del 2004.
3. BPMI.org. Annuncio del BPMN 1.0, 4 maggio 2004. L’intestazione riporta 2004 e la riga con la città riporta 2003, un refuso dell’originale.
4. Object Management Group. BPMN 2.0: OMG lo data dicembre 2010. Wikipedia [5] indica gennaio 2011.
5. Wikipedia. Business Process Model and Notation. Fonte della fusione del 2005 e del cambio di nome alla versione 2.0. Le pagine attuali di OMG usano il nuovo nome anche per la versione 1.0.
6. Trisotech. BPMN Introduction and History. Fonte secondaria, di un produttore, per il mese della fusione (giugno 2005).
7. ISO e IEC. ISO/IEC 19510:2013; scheda IEC. Pubblicata nel luglio 2013. Le fonti divergono sulla corrispondenza: ISO indica la versione 2.0.1 di OMG, e Trisotech [6] la 2.0.2.
8. BPMN Model Interchange Working Group. Suite di test di interscambio, usata per verificare l’importazione dell’app.

Qué es BPMN

BPMN (Business Process Model and Notation) es un lenguaje gráfico estándar para describir procesos de negocio: quién hace qué, en qué orden, con qué decisiones y qué ocurre cuando algo se sale de lo previsto.

La propia norma define el objetivo: ser comprensible para todos los implicados, desde los analistas que hacen el primer borrador hasta los desarrolladores que implementan y las personas que gestionan el proceso. Lo llama un puente entre el diseño y la implementación. ^[1]

No necesitas conocer todos los símbolos para empezar. Eventos, tareas, gateways y flujos de secuencia ya cubren buena parte de los diagramas. Este tutorial sigue ese orden y usa el BPMN Simulator, una app en un único archivo HTML: nada se envía a la red, y los diagramas quedan en tu navegador.

Abrir el BPMN Simulator →

Una breve historia

BPMN nació de la necesidad de una notación común entre analistas y tecnología. La cronología de abajo muestra los hitos, con las fechas de las fuentes consultadas.

• 2004. La Business Process Management Initiative (BPMI.org) anuncia BPMN 1.0, entonces llamado Business Process Modeling Notation. Stephen White, de IBM, presidía el grupo de trabajo. Al menos 20 empresas se comprometieron a dar soporte a la notación. ^[3]
• 2005. BPMI se fusiona con el Object Management Group (OMG), que pasa a mantener la norma. ^[5][6]
• De 2007 a 2009. La OMG registra la versión 1.0 formal en marzo de 2007, la 1.1 en enero de 2008 y la 1.2 en enero de 2009. ^[2][1]
• 2010. BPMN 2.0 añade semántica de ejecución y un formato de intercambio que incluye el diagrama. El nombre cambia a Model and Notation, manteniendo la sigla. ^[4][5]
• 2013. La norma se publica también como ISO/IEC 19510. ^[7]
• 2014. La versión 2.0.2, publicada en enero, es la actual en la OMG. El único cambio declarado respecto a la anterior está en la cláusula 15. ^[1]

Las fuentes no siempre coinciden en los detalles, y las diferencias están anotadas en las referencias. La app sigue la versión 2.0.2.

Definiciones esenciales

Los elementos de la notación

Casi todo diagrama usa cuatro familias de elementos. La forma indica la familia, y el icono interno indica el tipo.

Eventos

El borde indica la posición: fino al inicio, doble en medio y grueso al final. El icono indica el disparador o el resultado. El icono hueco captura algo, y el relleno dispara. La app solo ofrece las combinaciones permitidas por la Tabla 10.93 de la norma. ^[1]

Actividades

La tarea es la unidad de trabajo, y el icono de la esquina indica el tipo: usuario, servicio, manual, envío, recepción, script o regla de negocio. El + abajo indica un subproceso contraído. Tres barras indican instancias múltiples, y la flecha circular indica repetición.

Gateways

El símbolo dentro del rombo cambia por completo el comportamiento. Pregúntate siempre: ¿cuántas fichas salen y cuántas espera la unión?

Cómo se mueve la ficha

La ejecución se entiende fácilmente si sigues una ficha. El evento de inicio la crea. Sigue las flechas, permanece en la actividad mientras dura el trabajo y, en el gateway, obedece la regla de ese tipo. El evento de fin la consume, y la instancia termina cuando no quedan fichas ni actividades en curso. ^[1]

De ahí viene el error más común de los principiantes: abrir caminos con un tipo de gateway y cerrarlos con otro.

Lo contrario también causa problemas: si un paralelo abre y un exclusivo cierra, cada ficha pasa sola y lo que sigue se ejecuta dos veces. La norma también trata el caso de una condición que no se cumple: en un gateway exclusivo sin condición verdadera y sin flujo predeterminado, se produce una excepción (Tabla 13.2). ^[1]

La pantalla de la app

Selecciona un elemento para ver las acciones a su lado: añadir el siguiente paso, conectar o eliminar. Con doble clic o F2 escribes el nombre. La propia app elige el tipo de conexión según la norma y rechaza, mostrando el motivo, las conexiones prohibidas, como un flujo de secuencia que sale de un evento de fin.

En el menú Archivo hay cinco ejemplos listos para explorar antes de dibujar. Alta de empleado muestra subprocesos, y Centro de atención muestra colas.

Tu primer proceso

Vamos a dibujar una versión corta de este reembolso. Haz cada paso en la app, sin prisa:

1. Abre el BPMN Simulator y arrastra un Evento de inicio al área de dibujo. Con doble clic, escribe Gasto enviado.
2. Con el evento seleccionado, haz clic en Añadir tarea en el panel de al lado y escribe Revisar comprobante.
3. Con la tarea seleccionada, haz clic en Añadir gateway y llámalo ¿Comprobante válido?. Una pregunta funciona bien como nombre de un gateway de decisión.
4. Desde el gateway, añade la tarea Pagar reembolso y, después de ella, un evento de fin Reembolso pagado.
5. Selecciona de nuevo el gateway y añade otro evento de fin: Solicitud rechazada.
6. Haz clic en la flecha que va a Pagar reembolso. En Propiedades, escribe el nombre Sí y la Condición comprovante_ok.
7. Haz clic en la otra flecha, escribe el nombre No y marca Es el flujo predeterminado. Aparece una barrita en el origen de la flecha.
8. Haz clic en el área vacía y, en Datos iniciales, escribe comprovante_ok = chance(0.9). En cada caso, el comprobante tiene un 90% de probabilidad de ser válido.
9. Abre la pestaña Verificar. No debería haber errores de norma. Si los hay, haz clic en el elemento de la lista para ir a él.

Para guardar, usa Archivo → Guardar .bpmn. El archivo sigue el formato BPMN 2.0 XML de la norma, y otras herramientas compatibles pueden abrirlo.

Simular

Haz clic en Simular. El reloj es virtual, en minutos, y la misma Semilla repite la misma ejecución. Hay cuatro formas de usarlo:

Si estás aprendiendo, Paso a paso es el mejor comienzo. Las duraciones y los efectos se definen en cada actividad (random(5, 15), exponential(10), normal(10, 2)). Las probabilidades se definen en los flujos, y la capacidad en cada carril.

Un experimento con colas

Abre el ejemplo Centro de atención, con 2 agentes y 1 especialista. En la pestaña Muchas ejecuciones, ejecuta 500 casos con una llegada cada 3 minutos de media. La tabla muestra el tiempo de ciclo medio en 20 semillas, con el margen del 95%:

Los dos carriles empiezan muy ocupados, pero duplicar los especialistas cambia poco: los márgenes se solapan. Un agente más hace bajar mucho el tiempo, porque todos los tickets pasan por ellos. Solo con los dos refuerzos el tiempo se acerca al del trabajo en sí. Esto es solo un modelo, con números inventados para el ejemplo: sirve para comparar hipótesis, no para medir el proceso real.

Escenarios de prueba

Simular muestra lo que ocurre. Probar comprueba si es lo que debería ocurrir. En la pestaña Escenarios de prueba, cada escenario define las entradas y el resultado esperado, y la app da el veredicto.

El ejemplo Pedido en línea ya trae tres escenarios. Haz clic en Ejecutar todos y abre los detalles. Después prueba:

• Sugerir escenarios: crea un escenario por cada camino que añade cobertura. Fuerza las decisiones y rellena lo esperado con lo que ocurrió, así que revisa que sea realmente lo correcto.
• Cobertura: lo que nunca se ejecutó queda punteado en el diagrama. Una cobertura del 100% no demuestra que el proceso sea correcto: solo dice que cada elemento se ejecutó al menos una vez.
• Repeticiones: ejecuta con varias semillas e indica la que falló, para modelos con sorteos.
• Guardar ejecución como escenario: conserva una ejecución manual terminada, para repetirla después.

Verificar el modelo

La pestaña Verificar revisa el modelo en dos niveles:

• Reglas de la norma: eventos permitidos en cada posición, conexiones de las Tablas 7.3 y 7.4, flujo predeterminado con condición y otras. Al hacer clic en el elemento de la lista vas a él. ^[1]
• Análisis de fichas: el botón Analizar recorre los estados posibles de cada ámbito e indica bloqueos, bucles sin salida, falta de sincronización y lo que nunca se ejecuta. Supone que cualquier camino es posible e ignora los datos, así que puede señalar un camino que tus datos nunca recorren.

La importación de la app se comprobó con 12 archivos de la suite de intercambio del grupo MIWG, y los archivos reexportados pasaron el esquema XSD oficial. ^[8] Esto no es una certificación: la app no está certificada por la OMG y no es un motor de producción. Los diagramas de conversación y de coreografía quedan fuera. Los límites completos están en la Ayuda de la app.

Prompts de IA

Una IA ayuda a salir de la página en blanco, a encontrar lagunas y a escribir escenarios. También se equivoca con seguridad: inventa reglas, olvida excepciones y puede generar XML no válido. Trata el resultado como el borrador de un colega con prisa. Para escribir mejores prompts, mira el tutorial de prompts.

Antes de pegar: los procesos internos pueden contener nombres, importes y reglas confidenciales. Sustitúyelos por datos ficticios y sigue la política de tu organización sobre el uso de IA. La app no envía nada a la red, pero el servicio de IA recibe lo que pegues en él.

Sustituye las partes entre corchetes y pega en la herramienta de IA que uses.

1. Entrevistar antes de dibujar

Hace que la IA descubra lo que falta en lugar de suponerlo. Es el mejor comienzo cuando el proceso aún está en la cabeza de las personas.

Eres un analista de procesos con experiencia en BPMN 2.0.2.
Quiero modelar este proceso: [descríbelo en pocas frases].

Antes de proponer ningún diagrama, entrevístame:
- Haz una pregunta cada vez y espera mi respuesta.
- Cubre: qué inicia el proceso, quién participa, los pasos, las decisiones y sus criterios, las excepciones, los plazos, las esperas, los sistemas y qué indica el fin.
- Pregunta sobre todo por lo que sale mal, no solo por el camino ideal.
- No inventes respuestas. Si no lo sé, regístralo como pendiente.

Al final, entrega: resumen del proceso, tabla de actividades (actividad, responsable, entrada, salida), lista de decisiones con criterios y lista de pendientes.

2. Convertir un texto en estructura

Para actas, procedimientos o transcripciones. Pide el origen de cada elemento, lo que facilita la comprobación.

A partir del texto siguiente, extrae la estructura de un proceso para BPMN.

Reglas:
- Usa solo lo que está en el texto. Para cada elemento, cita el fragmento de origen.
- Marca como [SUPOSICIÓN] todo lo que hayas deducido.
- Enumera las contradicciones y lo que falta saber.

Entrega: participantes, actividades en orden, decisiones (pregunta, opciones, criterio), eventos (qué inicia, termina, interrumpe o espera) y pendientes.

Texto:
"""
[pega aquí, sin datos sensibles]
"""

3. Generar el BPMN para el BPMN Simulator

Genera un archivo que la app abre, organiza y simula. Pega la respuesta en Archivo → Ver o pegar XML y haz clic en Aplicar XML. Después ve a Verificar.

Genera un documento BPMN 2.0 XML, válido según el esquema de la OMG, para este proceso:
[describe el proceso o pega la estructura].

Formato obligatorio:
- Raíz <definitions> con targetNamespace y estos namespaces:
  xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:sim="https://giovanipm.github.io/ns/bpmn-simulator"
- Un <process> con isExecutable="false". Si hay más de un participante, usa <collaboration> con <participant> y <messageFlow>, con un proceso para cada participante.
- No generes <bpmndi:BPMNDiagram>: la app organiza el dibujo.
- ID únicos y legibles. Cada nodo con <incoming> y <outgoing>, en ese orden, antes de las definiciones de evento.
- En todo gateway exclusivo que decide, un flujo predeterminado con el atributo default, y condiciones en los otros flujos con <conditionExpression xsi:type="tFormalExpression">.
- Cierra los caminos paralelos con un gateway paralelo. No uses un evento intermedio de captura sin definición de evento.

Para la simulación, usa extensionElements, antes de <incoming>:
- En el proceso: <sim:config init="campo = expresión"/>, con &#10; entre las líneas.
- En las actividades: <sim:config duration="random(5, 15)"/>, en minutos.
- En las condiciones, usa campos y los operadores: > >= < <= == != and or not.
- Funciones disponibles: random(a, b), exponential(m), normal(m, d), chance(p), round(x, d).

Responde solo con el XML. Al final, dentro de un comentario XML, enumera las suposiciones que hiciste.

4. Revisar un modelo

Copia el XML de Ver o pegar XML. La IA mira el sentido del proceso, que las reglas automáticas no ven.

Revisa este proceso BPMN como un analista con experiencia.

Comprueba, en este orden:
1. Sentido de negocio: pasos ausentes, responsables extraños, excepciones sin tratar.
2. Flujo: bloqueos, caminos sin fin, gateways que abren con un tipo y cierran con otro.
3. Claridad: nombres de actividad con verbo y objeto, decisiones en forma de pregunta.
4. Norma BPMN 2.0.2: conexiones prohibidas y eventos fuera de posición.

Para cada problema, indica: id del elemento, problema, por qué importa, corrección sugerida y gravedad (alta, media, baja). Separa lo que es certeza de lo que es sospecha. No inventes reglas de negocio: si algo depende de ellas, haz una pregunta.

XML:
"""
[pega aquí]
"""

5. Explicar el proceso en lenguaje sencillo

Bueno para validar con quien hace el trabajo y no lee BPMN.

Explica el proceso siguiente a [público, por ejemplo: el equipo de atención], sin términos de BPMN.

Entrega:
- En dos frases: para qué sirve y cuándo empieza.
- El paso a paso, indicando quién hace qué.
- Cada decisión, como pregunta, y qué ocurre con cada respuesta.
- Qué ocurre cuando algo sale mal o se retrasa.
- Cinco preguntas para confirmar con el equipo si el dibujo corresponde al trabajo real.

Describe solo lo que está en el modelo. Si algo es ambiguo, dilo.

XML:
"""
[pega aquí]
"""

6. Proponer escenarios de prueba

La tabla resultante se convierte en escenarios en la pestaña Escenarios de prueba. Usa los id reales del modelo.

Propón escenarios de prueba para el proceso BPMN siguiente.

Cubre: el camino principal, cada salida de cada decisión, valores en el límite de las condiciones, eventos de borde que ocurren y que no ocurren, y combinaciones que parezcan arriesgadas.

Para cada escenario, una fila de tabla con:
- Nombre
- Dado que: datos del caso, en el formato campo = valor
- Cuando: decisiones forzadas y eventos que ocurren o no
- Entonces: elementos por los que pasa y por los que no pasa (con el id), y cómo termina el caso
- Por qué importa este escenario

Marca con [REVISAR] los resultados esperados que dependan de una regla de negocio no escrita en el modelo. Prefiere pocos escenarios que revelen errores a muchos parecidos.

XML:
"""
[pega aquí]
"""

7. Estimar parámetros de simulación

Sin datos reales, cualquier número es una hipótesis. Este prompt pide dejarlo a la vista.

Quiero simular este proceso BPMN y necesito duraciones, probabilidades y capacidades.

Datos reales que tengo: [pega medias, volúmenes o escribe "ninguno"].

Para cada actividad y decisión, propón:
- Un valor en minutos, en una de estas formas: número, random(a, b), exponential(m) o normal(m, d). Justifica la elección.
- Origen: [DATO], si viene de lo que indiqué, o [HIPÓTESIS], si es una estimación.
- Cómo obtener el dato real.

Después, enumera las tres hipótesis que más pueden cambiar el resultado, para probarlas primero.

XML:
"""
[pega aquí]
"""

8. Interpretar los resultados

Pega los números de la pestaña Muchas ejecuciones para discutir hipótesis, no para obtener un veredicto.

Estos son los resultados de una simulación de un proceso BPMN. Los números vienen de un modelo con parámetros estimados, no del proceso real.

Proceso: [descripción breve]
Parámetros: [capacidades, duraciones y llegadas]
Resultados: [tiempo de ciclo, ocupación por carril, colas por actividad]

Haz lo siguiente:
1. Indica el probable cuello de botella, usando los números.
2. Sugiere como máximo tres cambios para probar, cambiando una cosa cada vez, con lo que esperas que ocurra.
3. Di qué no permiten concluir los datos.
4. Indica qué medir en el proceso real antes de decidir.

No recomiendes inversiones basándote solo en esta simulación.

Qué se probó en estos prompts

El formato pedido en el prompt 3 se probó de verdad: un XML en ese formato, escrito por Claude para un proceso de reembolso, pasó el esquema XSD de la OMG, se abrió en la app, se organizó automáticamente y se simuló hasta el final. Los prompts no se probaron en otros modelos de IA, y las respuestas cambian cada vez. Por eso, la comprobación en Verificar y con escenarios sigue siendo necesaria.

Buenas prácticas y errores comunes

Repaso rápido

Intenta responder antes de abrir.

Abrir el BPMN Simulator →

Referencias

1. Object Management Group. Business Process Model and Notation, versión 2.0.2 (formal/13-12-09). Fuente de las definiciones, tablas y reglas citadas, y de las fechas de las versiones 1.1, 1.2 y 2.0.2.
2. Object Management Group. BPMN 1.0: publicación formal en marzo de 2007, con copyright de BPMI.org de 2004.
3. BPMI.org. Anuncio de BPMN 1.0, 4 de mayo de 2004. El encabezado dice 2004 y la línea de la ciudad dice 2003, una errata del original.
4. Object Management Group. BPMN 2.0: la OMG lo fecha en diciembre de 2010. Wikipedia [5] cita enero de 2011.
5. Wikipedia. Business Process Model and Notation. Fuente de la fusión de 2005 y del cambio de nombre en la versión 2.0. Las páginas actuales de la OMG usan el nombre nuevo también para la versión 1.0.
6. Trisotech. BPMN Introduction and History. Fuente secundaria, de un fabricante, para el mes de la fusión (junio de 2005).
7. ISO e IEC. ISO/IEC 19510:2013; registro en IEC. Publicada en julio de 2013. Las fuentes difieren sobre la correspondencia: ISO indica la versión 2.0.1 de la OMG, y Trisotech [6], la 2.0.2.
8. BPMN Model Interchange Working Group. Suite de pruebas de intercambio, usada para comprobar la importación de la app.