Módulo 7 · Sistemas de Informação · Semana 4 · Aula 3

26/08/2026

Hands on — Gestão de Configuração e Escopo

Validação dos artefatos com o parceiro

Oficina de parametrização das regras de negócio, documentação da solução e rastreabilidade entre personas, user stories e comportamento do ERP.

Implantação da soluçãoDocumentação técnicaPersonas e user storiesEvidências e decisões
Regra de negócioCritério validado no processo do parceiro
ParametrizaçãoComportamento verificável no ambiente ERP
DocumentaçãoProcedimento reproduzível e evidência identificada
ExperiênciaNecessidade da persona expressa em user story

Ritual do projeto

Daily · 15 minutos

Cada grupo informa o avanço dos artefatos, a atividade prevista para o encontro e os impedimentos que exigem decisão.

15:00
O que foi concluídoO que será produzidoImpedimentosProgresso da entrega
Estrutura do encontro

Duas horas de produção guiada, com o tempo do parceiro reservado para validações e decisões.

15Daily e estado da entregaAvanço, plano e impedimentos.
20Revisão de BPMNElementos, raias, gateways e case.
5Triagem dos insumosRegra prioritária e papéis.
25ImplantaçãoParametrizar, demonstrar e evidenciar.
20DocumentaçãoRegistrar percurso, finalidade e uso.
20UXConsolidar personas e user stories.
10Validação cruzadaEliminar contradições entre artefatos.
5FechamentoDecisões, responsáveis e prazos.
Objetivo: apresentar ao parceiro uma trilha verificável que conecte processo, regra de negócio, parametrização no ERP, documentação operacional e necessidade da pessoa usuária. A revisão de BPMN precede a produção porque o modelo do processo indica onde cada regra incide.
Revisão de BPMN · 20 minutos

O processo indica onde a regra de negócio incide; a parametrização no ERP converte essa incidência em comportamento verificável.

Notação

Linguagem comum

BPMN 2.0, mantida pela OMG e publicada como ISO/IEC 19510, permite que parceiro, analista e implementador leiam o mesmo diagrama sem tradução intermediária.

Localização

Onde a regra incide

Toda regra priorizada incide sobre um elemento identificável do processo: uma atividade, um gateway, uma transição ou um evento.

Consequência

Insumo da configuração

Raia indica perfil de acesso; gateway indica condição parametrizável; evento de mensagem indica notificação ou integração.

ProcessoSequência observada na operação do parceiro
Ponto de decisãoGateway, validação ou alçada
RegraEnunciado com critério e exceção
ParametrizaçãoConfiguração aplicada no ERP
EvidênciaExecução demonstrada ao parceiro
Quatro grupos de elementos

A notação completa é extensa. O subconjunto apresentado abaixo é suficiente para modelar os processos tratados no projeto.

Evento Atividade Gateway
Objetos de fluxo. O que acontece, o que se faz e onde o caminho se divide.
Sequência Mensagem Associação
Conexões. Sequência ordena atividades no mesmo participante; mensagem atravessa participantes.
Pool Raia Raia
Piscinas e raias. A piscina delimita o participante; a raia identifica o papel responsável.
Regra R-07 aplicada aqui
Artefatos. Objeto de dados representa o documento tratado; a anotação registra a regra aplicada.
Critério de leitura: um diagrama legível emprega poucos tipos de elemento e nomeia todos eles. Símbolo sem rótulo não comunica processo e não sustenta decisão de configuração.
Eventos e atividades

O evento registra algo que ocorre; a atividade registra trabalho executado. Ambos exigem nome explícito.

Início Intermediário Fim Mensagem recebida Temporizador Fim de erro
Eventos. A borda distingue início (simples), intermediário (dupla) e fim (espessa); o símbolo interno declara a causa.
Registrar requisição Calcular imposto Executar cotação Tarefa de usuário Tarefa de serviço Subprocesso Nomeie a atividade com verbo no infinitivo e objeto: «Aprovar requisição», em lugar de «Aprovação» ou «Requisição».
Atividades. O marcador indica quem executa: pessoa em sistema, sistema sem intervenção ou processo detalhado à parte.
Regra de fechamento: todo processo modelado inicia em evento de início e termina em evento de fim. Fluxo interrompido no meio do diagrama indica caminho não analisado.
Gateways: onde o caminho se decide

O gateway encaminha o fluxo segundo uma condição, sem executar trabalho, e constitui o ponto em que a regra de negócio costuma se materializar.

Preparar bebida Cancelar pedido aprovado recusado Pagamento aprovado?
Exclusivo (XOR). Exatamente um caminho é seguido. As condições devem ser mutuamente excludentes e cobrir todos os casos.
Preparar bebida Emitir comanda sempre sempre Sem condição de saída
Paralelo (AND). Todos os caminhos são seguidos ao mesmo tempo. Não há condição nos fluxos de saída.
Adicionar leite Adicionar açúcar se solicitado se solicitado Complementos?
Inclusivo (OR). Um, alguns ou todos os caminhos são seguidos, conforme as condições satisfeitas.
Exigência: todo fluxo de saída de gateway exclusivo ou inclusivo declara sua condição, e toda divisão converge ou termina em evento de fim nomeado. Caminho que não converge nem alcança evento de fim produz processo cujo término não é determinável.
Piscinas e raias: quem responde por quê

A piscina delimita o participante autônomo; a raia identifica o papel interno responsável pela atividade.

Distribuidora Alfa Solicitante Gestão Suprimentos Necessidade Registrar requisição Analisar demanda Emitir pedido Pedido emitido Fornecedor pedido de compra Participante externo — processo próprio não representado.
Leitura do diagrama. O fluxo de sequência ordena as atividades dentro da distribuidora; a comunicação com o fornecedor ocorre por fluxo de mensagem.
Piscina

Representa a organização ou o sistema autônomo, com processo e fronteira de responsabilidade próprios.

Raia

Identifica o papel que executa a atividade. É a origem direta dos perfis de acesso no ERP.

Restrição

Fluxo de sequência não atravessa a fronteira da piscina; entre participantes emprega-se fluxo de mensagem.

Passo a passo da modelagem

A ordem de construção identifica quem responde por cada atividade antes de desenhá-la.

Empresa Solicitante Gestão
1. Delimitar. Identificar os participantes e os papéis antes de qualquer atividade.
Solicitante Gestão Início Fim
2. Ancorar. Marcar o que dispara o processo e o resultado que o encerra.
Registrar Aprovar
3. Sequenciar. Inserir as atividades na raia de quem as executa, na ordem observada.
Registrar aprovada reprovada Devolver
4. Decidir. Inserir os gateways e nomear a condição de cada caminho alternativo.
  • 5. Verificar se toda divisão converge ou termina em evento de fim nomeado.
  • 6. Anotar, junto ao elemento correspondente, o identificador da regra de negócio aplicada.
  • 7. Validar o modelo com quem executa o processo, além de quem o descreve.
Falhas recorrentes na modelagem

As quatro falhas abaixo são recorrentes na revisão de diagramas.

Verificar valor Aprovar direto Aprovar em alçada ✗ sem gateway e sem condição
Incorreto. Dois fluxos saem da mesma atividade sem gateway e sem condição declarada. O critério da decisão permanece implícito e não é parametrizável.
Registrar valor Valor da requisição ≤ R$ 5.000 > R$ 5.000 Aprovar — gestor Aprovar — duas alçadas
Correto. O gateway explicita a decisão; cada fluxo declara sua condição. O limite de R$ 5.000 torna-se parâmetro configurável no ERP.
FalhaConsequênciaCorreção
Atividade nomeada por substantivoNão se identifica quem age nem o que é produzido.Empregar verbo no infinitivo seguido do objeto.
Fluxo de sequência entre piscinasModelo inválido: pressupõe controle sobre processo alheio.Substituir por fluxo de mensagem entre os participantes.
Caminho sem evento de fimNão se determina o encerramento nem o resultado do processo.Encerrar cada caminho em evento de fim nomeado.
Exceção ausente do modeloA parametrização contempla apenas o caso nominal.Representar recusa, devolução e reprocessamento.
Case · Requisição de compra com alçada

Leia o enunciado e identifique, antes de desenhar, os participantes, os papéis e os pontos de decisão.

Situação

Indústria Vega — compras indiretas

Quando identifica uma necessidade, a pessoa solicitante registra a requisição no ERP informando item, quantidade, centro de custo e data de necessidade. A requisição segue para a gestão, que a aprova ou a devolve com justificativa. Aprovada, a requisição chega a Suprimentos, que emite o pedido e o transmite ao fornecedor.

  • Participantes: Indústria Vega e fornecedor externo.
  • Papéis internos: solicitante, gestão e suprimentos.
  • Documento tratado: requisição de compra e, em seguida, pedido de compra.
  • Desfechos possíveis: pedido emitido ao fornecedor ou requisição devolvida com justificativa.
RegraEnunciadoElemento afetado
R1Requisição sem centro de custo ou sem data de necessidade não é aceita.Atividade de registro
R2Requisição de até R$ 5.000 exige aprovação do gestor imediato; acima desse valor, exige também aprovação da diretoria.Gateway de alçada
R3Item sem contrato vigente exige três cotações antes da emissão do pedido.Gateway de contrato
R4Requisição reprovada retorna à pessoa solicitante com justificativa registrada.Caminho de exceção
Antes de ver o modelo: quantas piscinas o processo exige? Quantas raias? Em que ponto cada regra incide? A regra R4 termina em qual evento?
Case · Modelo resolvido

Duas piscinas, três raias, três decisões nomeadas e dois desfechos distintos.

Indústria Vega Solicitante Gestão Suprimentos Necessidade de compra Registrar requisição · R1 R2 · Valor da requisição ≤ R$ 5.000 > R$ 5.000 Aprovar — gestor imediato Aprovar — gestor e diretoria Requisição aprovada? R4 · reprovada Requisição devolvida aprovada R3 · Contrato vigente? sem contrato Coletar três cotações com contrato Emitir pedido de compra Pedido emitido Fornecedor pedido de compra Participante externo — processo próprio não representado; a comunicação ocorre por fluxo de mensagem.
Verificação: cada gateway declara a regra que o origina, cada caminho alternativo termina em evento de fim nomeado e a comunicação com o fornecedor não emprega fluxo de sequência.
Do modelo à parametrização

Cada elemento do diagrama indica um ponto de configuração no ERP e a evidência correspondente exigida na entrega.

Elemento BPMNLeitura no processoCorrespondência no ERPEvidência esperada
RaiaPapel responsável pela atividade.Perfil de acesso e segregação de funções.Atribuição do perfil e tentativa negada para papel indevido.
Tarefa de usuárioTrabalho executado por pessoa no sistema.Transação, tela ou formulário com campos obrigatórios.Execução completa da transação com dados de teste.
Gateway exclusivoDecisão com critério objetivo.Regra de alçada, condição de workflow ou validação.Execução dos dois caminhos, incluindo o de exceção.
Evento de mensagemComunicação com participante externo.Notificação, saída de documento ou integração.Registro de envio com identificação do destinatário.
Evento de fim de erroDesfecho por exceção do processo.Bloqueio, mensagem de erro ou devolução com justificativa.Captura da mensagem exibida e do estado resultante.
Aplicação imediata: na triagem, cada grupo indica em que elemento do processo a regra priorizada incide. A ficha de parametrização registra essa localização; a demonstração ao parceiro percorre o caminho nominal e o caminho de exceção do mesmo gateway.
Três artefatos da mesma solução

A coerência entre os documentos constitui o principal critério de qualidade do encontro.

1
Implantação

Parametrização das regras

Configurações, autorizações, validações, cálculos, workflows e alertas que materializam as regras priorizadas.

2
Documentação

Manual técnico-operacional

Registro do que foi configurado, por que a decisão foi adotada, como reproduzir o percurso e como operar a solução.

3
Experiência

Personas e user stories

Perfis fundamentados em evidências e necessidades rastreadas às funcionalidades e regras implementadas.

PersonaQuem executa ou recebe o resultado
NecessidadeResultado operacional requerido
User storyCapacidade esperada da solução
Regra e parâmetroComportamento configurado
EvidênciaDemonstração e aceite
Critério de entrada da oficina

O tempo do parceiro não deve ser consumido com localização de arquivos ou reconstrução de informações já disponíveis.

  • Catálogo de regras com identificadores estáveis, origem e prioridade.
  • Processo ou subprocesso em que cada regra é aplicada.
  • Acesso ao ambiente correto e perfis necessários para parametrização.
  • Versão corrente dos três artefatos aberta para edição.
  • Dados de demonstração que cubram caso nominal, fronteira e exceção.
  • Lista objetiva de dúvidas que dependem do conhecimento do parceiro.
  • Integrante responsável por operar o ERP e integrante responsável pelo registro.
  • Repositório organizado para armazenar evidências sem dados sensíveis.
Ausência de insumo: registrar a lacuna, atribuir responsável e definir prazo. Não se admite inventar regra, aprovação do parceiro ou evidência de execução.
Uso adequado do tempo com o parceiro

A equipe apresenta evidências e perguntas delimitadas; o parceiro valida significados, prioridades e exceções do negócio.

Preparar

Antes da conversa

Selecionar as regras prioritárias, organizar a demonstração e formular perguntas que admitam decisão objetiva.

Demonstrar

Durante a conversa

Exibir o comportamento configurado com dados controlados e explicar sua relação com o processo mapeado.

Validar

Decisão do parceiro

Confirmar intenção, condição, exceções, vocabulário, prioridade e impacto sobre as pessoas usuárias.

Registrar

Após a decisão

Atualizar os artefatos, identificar a evidência e registrar responsável, prazo e consequência de cada pendência.

Limite de responsabilidade: o parceiro valida a aderência ao negócio. A equipe continua responsável pela correção técnica, pela rastreabilidade e pela qualidade da documentação.
Protocolo de trabalho por regra priorizada

Cada rodada deve produzir uma decisão ou uma pendência formalizada.

1. EnunciarLer a regra e indicar sua origem.
2. LocalizarApontar processo, ator e momento de aplicação.
3. DemonstrarExecutar o comportamento configurado.
4. ConfrontarComparar resultado e intenção do parceiro.
5. RegistrarAtualizar decisão, evidência e responsável.
Aceita

Comportamento aderente

A evidência recebe identificador e é vinculada à regra e à seção correspondente da documentação.

Ajustar

Divergência delimitada

Registra-se a mudança requerida, seu impacto e o responsável pela nova demonstração.

Pendente

Decisão indisponível

A entrega explicita a dependência, a autoridade decisória e o prazo acordado; não presume aceite.

Artefato 1 · Implantação da solução

A parametrização deve representar regras efetivamente mapeadas, priorizadas e demonstráveis.

Configuração

Funcionalidade e dados

  • Opções e parâmetros do módulo
  • Dados mestres e valores de domínio
  • Condições e fórmulas automáticas
Controle

Acesso e fluxo

  • Perfis, autorizações e segregação
  • Workflow e níveis de aprovação
  • Restrições de campo e validações
Exceção

Resposta operacional

  • Alertas, mensagens e bloqueios
  • Tratamento de situação excepcional
  • Responsável e ação corretiva
Unidade de verificação: uma regra somente entra no percentual de cobertura quando a configuração está identificada, o comportamento foi executado e a evidência permite verificar o resultado.
Registro mínimo da parametrização

A tabela relaciona intenção do negócio, implementação e evidência sem depender da memória da equipe.

IDRegra e origemPonto do processoConfiguraçãoCenáriosEvidênciaDecisão
RN-014Desconto superior a 15% exige aprovação da diretoria.Confirmação do pedidoWorkflow por faixa de desconto e perfil aprovador15%; 15,01%; sem aprovadorEVD-014-A
EVD-014-B
Aceita em 26/08
RN-015Cliente inadimplente não recebe desconto.Cálculo comercialValidação do status financeiro antes do cálculoAdimplente; vencido > 30 diasEVD-015-AAjustar mensagem
RN-018Cliente estratégico possui faixa específica.Classificação do clienteCondição por segmento e faixa autorizadaRegular; estratégico; limiteEVD-018-APendente: faixa
Regra de integridade: identificadores de regra, evidência e decisão permanecem iguais nos três artefatos. Renomeações sem atualização integral rompem a rastreabilidade.
Demonstração verificável da regra

Uma captura isolada de tela não demonstra que o comportamento configurado satisfaz a regra.

A

Caso nominal

Executar a situação mais frequente e registrar entradas, usuário, resultado esperado e resultado observado.

B

Valor de fronteira

Executar o limite declarado na regra e o primeiro valor externo à faixa, evitando interpretações sobre inclusão.

C

Exceção ou bloqueio

Comprovar mensagem, restrição, rota de aprovação ou ação corretiva prevista para a condição excepcional.

A evidência contém

Identificador, data, ambiente, perfil utilizado, dados mascarados, ação executada, resultado e vínculo com a regra.

A evidência não contém

Credenciais, dados pessoais desnecessários, recortes sem contexto, tela de outro ambiente ou afirmação de aceite sem registro.

Artefato 2 · Documentação da solução

O documento deve permitir compreender, reproduzir e operar a configuração sem acompanhamento oral da equipe.

1

Contexto

Regra atendida, processo, responsável de negócio, versão e ambiente.

2

Decisão

Motivo da configuração, alternativas avaliadas e restrições adotadas.

3

Procedimento

Percurso real no sistema, parâmetros informados e dependências necessárias.

4

Operação

Uso esperado, exceções, mensagens, evidências e procedimento de reversão.

Configurações gerais e específicas: o documento separa parâmetros transversais do ambiente das configurações próprias do módulo do grupo e explica a relação de ambas com o processo do parceiro.
Evidência visual com contexto operacional

Cada figura deve cumprir função probatória ou instrucional claramente declarada.

Legenda obrigatória

FIG-CFG-014-02

Onde: módulo, menu e tela.
O que: parâmetro alterado e valor final.
Por quê: regra atendida.
Resultado: comportamento observado.
Versão: ambiente e data.

Revisão da captura
  • Recorte preserva o contexto necessário.
  • Campo relevante está legível e destacado.
  • Informações sensíveis estão mascaradas.
  • Sequência das telas coincide com o texto.
  • Identificador permite localizar a evidência original.
Constitui falha: inserir capturas em sequência sem explicar a finalidade dos parâmetros, a regra atendida ou o comportamento resultante.
Artefato 3 · Personas fundamentadas

A persona representa um padrão de comportamento relevante para a solução e fundamenta-se em evidência de pesquisa.

Identidade operacional
  • Nome representativo e função
  • Empresa, setor e contexto de uso
  • Responsabilidades e nível de acesso
  • Frequência e ambiente de trabalho
Resultado esperado
  • Objetivos e indicadores de desempenho
  • Necessidades e decisões recorrentes
  • Informações requeridas no processo
  • Critérios de sucesso observáveis
Evidência de pesquisa
  • Dores e restrições relatadas
  • Fonte da informação coletada
  • Padrão observado entre participantes
  • Hipótese ainda não confirmada
Mínimo da entrega: duas personas que representem perfis distintos e cubram as pessoas afetadas pelas regras e pelos fluxos prioritários do módulo.
User stories e critérios de aceite

A história traduz a necessidade da persona e permanece rastreável ao comportamento configurado.

História

US-07

Como diretor comercial, quero receber pedidos com desconto acima da alçada gerencial em uma fila de aprovação, para decidir sem interromper o processamento dos demais pedidos.

Vínculos: persona PER-02 · regra RN-014 · configuração CFG-014.
Aceite verificável

Dado um pedido com desconto de 16% e vendedor sem alçada;
quando o vendedor solicitar a confirmação;
então o pedido deve permanecer bloqueado e integrar a fila da diretoria, com mensagem identificável ao vendedor.

Evidência: EVD-014-B demonstra o bloqueio e o encaminhamento.
Teste de consistência: se a user story exige comportamento não representado por regra ou parametrização, existe uma lacuna que deve ser resolvida ou explicitamente registrada.
Matriz de consistência entre artefatos

A validação cruzada identifica componentes fantasmas e requisitos sem implementação.

PersonaNecessidadeUser storyRegraConfiguraçãoEvidênciaEstado
PER-02Decidir exceções comerciaisUS-07RN-014CFG-014EVD-014-BValidado
PER-01Conhecer motivo do bloqueioUS-08RN-015CFG-015EVD-015-AAjustar mensagem
PER-03Auditar decisõesUS-11RN-014Não identificadaAusentePendência crítica

Componente fantasma

Configuração ou captura sem regra, processo ou necessidade que justifique sua existência.

Lacuna funcional

Necessidade ou user story sem regra, configuração e evidência correspondentes.

Contradição

Documento, ERP e relato do parceiro expressam limites, papéis ou exceções diferentes.

Execução da oficina em três ciclos

Em cada ciclo, a equipe produz, submete uma questão ao parceiro e registra o resultado.

25 min
ProduzirParametrizar uma regra prioritária e preparar os três cenários.
ValidarDemonstrar o comportamento e confirmar intenção e exceções.
RegistrarAtualizar cobertura, evidência e decisão.
20 min
ProduzirDocumentar percurso, parâmetros, finalidade e operação.
ValidarConfirmar linguagem, sequência e resultado de negócio.
RegistrarVincular figuras, regra e versão.
20 min
ProduzirConsolidar duas personas e histórias prioritárias.
ValidarConfirmar papéis, dores, objetivos e decisões recorrentes.
RegistrarVincular persona, história, regra e evidência.
Distribuição recomendada: operador do ERP, relator técnico, responsável por UX e interlocutor do parceiro. Os papéis podem alternar entre os ciclos.
Registro de validação do parceiro

O registro diferencia decisão, recomendação e pendência; cada uma exige tratamento específico.

IDObjeto apresentadoManifestaçãoClassificaçãoAçãoResponsávelPrazo
VAL-01Faixa de aprovação da RN-014Limite de 15% confirmado para o cenário vigente.DecisãoManter configuração e anexar evidência.Equipe26/08
VAL-02Mensagem da RN-015Indicar também o título vencido que originou o bloqueio.RecomendaçãoAvaliar viabilidade e atualizar documentação.Operador ERP28/08
VAL-03Perfil auditorAutoridade de acesso ainda não definida.PendênciaConsultar responsável do processo.Parceiro29/08
Proteção da evidência: registrar nome ou papel do participante somente quando necessário e autorizado. Dados pessoais e comerciais não pertinentes devem ser omitidos ou mascarados.
Definição de pronto da entrega

O fechamento avalia a qualidade da trilha completa; o volume de telas ou de configurações, isoladamente, não constitui critério.

  • Regras prioritárias possuem configuração identificada.
  • Cobertura do checklist foi calculada com base verificável.
  • Cenários nominal, de fronteira e de exceção foram executados.
  • Evidências estão legíveis, versionadas e sem dados sensíveis.
  • Configurações gerais e específicas estão separadas.
  • Cada procedimento explica finalidade, percurso e resultado.
  • Diagramas e fluxos coincidem com a solução implantada.
  • Exceções e operação posterior estão documentadas.
  • Existem ao menos duas personas fundamentadas.
  • User stories possuem critérios de aceite verificáveis.
  • A matriz conecta persona, história, regra e evidência.
  • Decisões e pendências do parceiro têm responsável e prazo.
Pacote de saída do encontro

Cada grupo encerra a aula com arquivos atualizados e um registro objetivo do trabalho restante.

01

ERP demonstrável

Ao menos uma regra prioritária parametrizada ou ajustada, com cenários reproduzíveis.

02

Documento atualizado

Seção correspondente à configuração, com percurso, decisão, figuras e operação.

03

UX rastreada

Personas e user stories revisadas frente aos papéis e necessidades do parceiro.

04

Registro de validação

Decisões, recomendações, pendências, responsáveis, prazos e próxima demonstração.

Encerramento: o grupo informa qual regra foi validada, qual evidência a comprova e qual pendência apresenta maior risco para a entrega da Semana 4.
Fechamento do grupo

A apresentação final sintetiza a evidência produzida e torna explícito o trabalho ainda necessário.

A entrega é verificável quando o parceiro reconhece a regra, a equipe demonstra o comportamento e a documentação permite reproduzir a decisão.
Pergunta de fechamento

Qual elo da trilha ainda depende de hipótese não validada?

Registre a hipótese, a evidência necessária, a pessoa responsável por validá-la e a data acordada.

Hipótese

Afirmação ainda não confirmada e seu impacto sobre a entrega.

Evidência

Registro necessário para aceitar ou rejeitar a hipótese.

Próxima validação

Responsável, interlocutor e data acordada para a decisão.

Sobre este encontro

Hands on — Gestão de Configuração e Escopo · 26/08/2026 · Prof. Afonso

Objetivo de aprendizagem

Ao final do encontro, o estudante deve ser capaz de localizar em um modelo BPMN o ponto em que a regra de negócio incide, demonstrar ao parceiro a parametrização dessa regra no ERP, documentar sua finalidade e seu procedimento operacional e verificar sua rastreabilidade com personas e user stories, registrando evidências, decisões e pendências.

Estratégia do encontro

Revisão expositiva de BPMN — elementos, piscinas, raias, gateways e case resolvido de requisição de compra — seguida de oficina de produção em três ciclos sobre os artefatos reais de cada grupo: parametrização e demonstração no ERP, documentação técnico-operacional e revisão de personas e user stories. O parceiro valida a aderência ao negócio; o docente orienta a consistência técnica e a rastreabilidade da entrega.

Estrutura do encontro

  1. Daily e diagnóstico do estado dos três artefatos — 15 min
  2. Revisão de BPMN: elementos, piscinas, raias, gateways e case de requisição de compra — 20 min
  3. Triagem dos insumos, seleção da regra prioritária e distribuição dos papéis — 5 min
  4. Ciclo 1: parametrização, demonstração e evidências da implantação — 25 min
  5. Ciclo 2: documentação da configuração, do procedimento e das exceções — 20 min
  6. Ciclo 3: revisão de personas, user stories e critérios de aceite — 20 min
  7. Validação cruzada da rastreabilidade e registro das decisões do parceiro — 10 min
  8. Fechamento: regra validada, evidência principal, pendências e responsáveis — 5 min