Processo

Trata-se de um cadastro bastante completo e que impacta todo o sistema, pois um processo bem configurado pode envolver usuários de diversos departamentos e até referenciar dados de módulos como Vendas, Financeiro ou Estoque. A seguir, explicamos detalhadamente como acessar a área de Processos BPM, utilizar a tela de pesquisa e realizar o cadastro de um novo processo em suas seis etapas (Dados Básicos, Formulário, Etapas, Aprovação, Acesso, Recorrência). Também discutiremos o impacto dessas configurações e daremos um exemplo prático de utilização.

1. Acessando o cadastro de Processos de Negócio (BPM)

Certifique-se de que você tem permissão para gerir processos no módulo BPM. No menu superior do BomControle, clique em BPM > Cadastros > Processos. Isso exibirá a tela de listagem de Processos de Negócio já cadastrados. (Em alguns ambientes, o menu pode aparecer como “Processos” diretamente dentro de BPM.)

2. Tela de Pesquisa de Processos de Negócio

Imagem da tela de pesquisa/listagem de Processos BPM

A tela inicial permite pesquisar, visualizar e gerenciar os processos existentes. As principais características dessa tela são:

• Filtro de busca: utilize o campo de pesquisa para filtrar processos pelo nome. Digite parte do nome do processo e pressione Enter (ou aguarde a atualização automática) – a grade listará apenas os processos cujo nome contenha o texto informado. Caso o filtro esteja em branco, todos os processos cadastrados serão exibidos.

• Colunas exibidas:

• Ícone: um ícone ilustrativo associado ao processo (escolhido no cadastro). Facilita a identificação visual de processos diferentes na interface.

• Nome: nome do processo de negócio. Logo abaixo do nome, é indicado se o processo “Necessita aprovação” ou “Não necessita aprovação”, de acordo com sua configuração (essa informação vem da etapa de Aprovação do cadastro).

• Tempo: mostra dois prazos configurados: primeiro, o Tempo de Execução previsto do processo; em seguida, o Tempo de Espera. 

Por exemplo: “Execução: 5 Dias; Espera: 2 Dias”. O Tempo de Execução corresponde ao prazo estimado para concluir o processo, enquanto o Tempo de Espera (também chamado de Prazo de Apropriação) geralmente representa um tempo de espera ou intervalo que o processo admite (por exemplo, tempo que pode ficar aguardando início ou entre etapas – esse campo não é configurado diretamente pelo usuário na UI padrão, podendo ser definido internamente ou via API; se não aplicável, pode aparecer como zero ou vazio). Esses prazos são definidos na etapa de Dados Básicos (execução) e, possivelmente, em configurações internas do fluxo para espera.

• Ações: à direita de cada linha, há botões de ação: Editar (ícone de lápis) para modificar o processo; Bloquear/Desbloquear (ícone de cadeado) para inativar ou reativar o processo. Note que não há opção de excluir processos via interface – uma vez criado, um processo pode ser apenas bloqueado (inativado) caso não deva mais ser utilizado. Bloquear um processo o torna indisponível para início de novas instâncias, mas não afeta instâncias já em andamento.

• Paginação: se houver muitos processos listados, navegue pelas páginas usando os controles de paginação no rodapé (Anterior/Próximo).

• Cadastrar Novo: clique no botão Cadastrar Novo (na barra de ações fixa, geralmente no canto inferior) para iniciar o cadastro de um novo processo de negócio. Será aberta a tela de configuração em múltiplas etapas (wizard) para você definir todos os parâmetros do processo.

3. Cadastro de um novo Processo – Visão Geral

Ao criar um novo processo, o BomControle apresenta um assistente dividido em 6 etapas sequenciais: Dados Básicos, Formulário, Etapas, Aprovação, Acesso e Recorrência. Você deverá preencher as informações de cada etapa e avançar para a próxima até concluir o cadastro. 

A interface indica as etapas no topo (normalmente com uma barra de progresso ou numeração de 1 a 6) e só permite avançar quando os requisitos mínimos de cada passo são atendidos. A qualquer momento, é possível usar o botão Voltar para revisar ou alterar etapas anteriores antes de finalizar.

Imagem das Etapas para cadastro de um Processo BPM  

• Dados Básicos: configura informações gerais do processo (nome, prazo, ícone, categoria de fluxo e papéis envolvidos na execução).

• Formulário: define os campos que o formulário inicial do processo terá – ou seja, quais informações o solicitante deverá fornecer ao iniciar o processo.

• Etapas: permite cadastrar as etapas de trabalho (atividades/tarefas) que compõem o fluxo do processo, em ordem sequencial, incluindo checklists de tarefas dentro de cada etapa.

• Aprovação: configura se o processo exige aprovação inicial (e por quem), definindo prazos de aprovação e papéis responsáveis por aprovar.

• Acesso: determina quem pode iniciar o processo (todos os usuários, apenas certos departamentos/papéis ou usuários específicos, etc.), controlando o acesso ao processo.

• Recorrência: opcionalmente, possibilita agendar execuções automáticas do processo em intervalos definidos (diário, mensal, etc.), criando instâncias recorrentes sem intervenção manual.

A seguir, detalhamos cada etapa e campo do cadastro de processo, com as respectivas regras de preenchimento e impactos no funcionamento do BPM e demais módulos.

3.1. Etapa 1 – Dados Básicos

Nesta primeira etapa, preencha os campos fundamentais de identificação e configuração do processo.

Imagem das Etapas para cadastro de um Processo BPM  - Dados Básicos

• Nome: nome do processo de negócio. Escolha um título claro e conciso que descreva a finalidade do processo (ex.: Aprovação de Desconto, Pedido de Compra, Inventário Mensal).
  Regras: campo obrigatório; até 100 caracteres. O nome não deve estar em branco e deve ser único o suficiente para não gerar confusão com outros processos (o sistema permite nomes iguais, mas isso não é recomendável para administração).
  Impacto: o nome aparece em toda a interface para os usuários finais – na lista de processos disponíveis para iniciar, no painel de tarefas, nos relatórios e notificações. Um nome bem definido ajuda os usuários a identificarem e escolherem o processo correto.

• Tempo de execução: prazo estimado para concluir uma instância do processo. É composto de dois sub-campos: um número e uma unidade de tempo.

• Quantidade: insira um número inteiro que represente a duração esperada.

• Unidade de Tempo: selecione se o número corresponde a Dias, Horas ou Minutos, etc. (as opções típicas são Minuto(s), Hora(s), Dia(s)).
  Regras: campo obrigatório (deve definir pelo menos “0” na quantidade se a métrica for irrelevante, porém recomenda-se um valor positivo). A unidade de tempo deve ser selecionada; caso tente avançar sem escolher a unidade, o sistema alertará para preencher este campo.

Impacto: esse tempo de execução serve como SLA (acordo de nível de serviço) ou referência de prazo para o processo. Ele pode ser utilizado para cálculo de atrasos e monitoramento: por exemplo, o painel de BPM poderá destacar processos cuja execução ultrapassou esse prazo. Também aparece na listagem de processos (coluna Tempo de Execução) para informação dos gestores. (Observação: Este campo não impõe encerramento automático do processo; é informativo/gerencial, mas pode habilitar futuras automações ou alertas se combinadas com outras regras do sistema).

• Imagem (Ícone): um ícone ilustrativo para o processo. Ao lado do campo é exibido um pequeno botão/seleção que permite escolher um ícone dentre uma biblioteca (geralmente ícones Font Awesome ou similares).
  Regras: campo obrigatório; selecione um ícone gráfico que melhor represente o processo. Ao clicar no campo, será aberta uma janela de seleção de ícones – escolha e confirme. O ícone escolhido será mostrado dentro do campo.
  Impacto: o ícone é exibido ao lado do nome do processo em diversas telas (por exemplo, na listagem de processos e possivelmente em botões de atalho). É puramente visual, servindo para ajudar na identificação rápida do processo pelos usuários. Não afeta a lógica ou integração com outros módulos, mas um ícone consistente melhora a usabilidade.

• Fluxo de Trabalho: categoria ou tipo de fluxo ao qual o processo pertence. Este campo apresenta uma lista suspensa de opções predefinidas de Fluxos de Trabalho BPM. Exemplos de fluxos (dependendo da configuração do sistema) podem incluir: Padrão BPM, Service Desk, Ordem de Serviço, Projeto, etc.
  Regras: campo obrigatório; selecione uma das opções disponíveis. As opções são cadastradas separadamente na configuração de Fluxos de Trabalho BPM do sistema (se nenhuma opção existir, é necessário cadastrar pelo menos um fluxo em BPM > Cadastros > Fluxo de Trabalho antes de prosseguir, ou solicitar ao administrador).
  Impacto: o Fluxo de Trabalho escolhido define o contexto e possivelmente regras adicionais do processo. Em muitos casos, ele agrupa processos por finalidade ou módulo relacionado. Por exemplo, se você selecionar Service Desk, o processo pode ser tratado como um ticket de helpdesk internamente, integrando-se a filas de atendimento; se selecionar Ordem de Serviço, o processo pode se vincular ao módulo de Ordens de Serviço. Em geral, esse campo influencia:

• Integração com outros módulos ou telas: alguns fluxos podem estar associados a funcionalidades específicas. (Ex: um processo com fluxo Service Desk pode aparecer no dashboard de suporte, enquanto um fluxo Financeiro poderia habilitar opções contábeis).

• Status e etapas padrão: certos fluxos possuem etapas/status padrão que o processo deve abranger. O sistema pode exigir que cada status principal seja contemplado em alguma etapa (por exemplo, aberto, em andamento, concluído, cancelado – garantindo que o processo tenha etapas cobrindo esses estados).

• Relatórios e indicadores: os processos podem ser filtrados e contabilizados por tipo de fluxo em relatórios gerenciais.
  Em resumo, escolha o fluxo que mais se adequa à natureza do processo para assegurar que ele se comporte adequadamente dentro do BomControle. (Dica: Se estiver em dúvida, use um fluxo genérico como “Padrão BPM” – isso geralmente não impõe regras extras específicas.)

• Papéis Executantes: nesta seção, você define quem, na organização, irá executar as etapas do processo. Consiste em selecionar um Departamento e um Papel Organizacional dentro dele, e adicioná-los à lista de executores. Em outras palavras, você está indicando quais grupos de usuários (por cargo e setor) serão responsáveis por realizar as tarefas das etapas de trabalho. A interface apresenta: um campo Departamento, um campo Papel Organizacional e um botão Adicionar (+). Ao lado, uma tabela listará os papéis adicionados.

• Departamento (Executante): escolha primeiro o departamento cuja equipe participará do processo.

• Papel Organizacional (Executante): em seguida, selecione um papel (cargo/função) dentro do departamento escolhido. A lista de papéis exibirá apenas os papéis organizacionais vinculados àquele departamento. (Você pode cadastrar rapidamente um novo papel pelo atalho “+”, caso necessário, sem sair da tela.)

• Clique em Adicionar (botão +) para incluir o par Departamento & Papel na lista de Papéis Executantes do processo.
  
  

Regras: é obrigatório adicionar pelo menos um papel executante antes de prosseguir para a próxima etapa (o sistema emitirá um erro “Adicione um papel executante” se tentar avançar sem nenhum). Você pode adicionar vários papéis executantes, de departamentos iguais ou distintos, caso o processo envolva diferentes áreas. 

Por exemplo, num processo de compras pode-se incluir Departamento Financeiro – Papel Aprovador e Departamento Almoxarifado – Papel Conferente. Cada papel executante inserido aparece na tabela abaixo com sua identificação. É possível editar um item da lista (selecionando-o na tabela e alterando os campos, o botão de adicionar muda para Atualizar) ou remover usando o ícone X na tabela (lixeira). Evite duplicar o mesmo papel na lista – o sistema normalmente previne isso; se tentar adicionar novamente um papel já listado, nada acontecerá.

Impacto: os Papéis Executantes definem quem será encarregado de realizar as etapas operacionais do processo. Quando você for configurar as Etapas (na terceira etapa do cadastro), cada etapa poderá ser atribuída a um papel executante específico. Somente papéis que estejam nesta lista poderão ser selecionados para assumir etapas. Portanto, essa configuração limita e orienta a distribuição de tarefas: usuários pertencentes aos papéis aqui listados serão os que receberão tarefas quando o processo estiver em execução. 

Exemplo: Se em Papéis Executantes constam “Almoxarifado – Conferente” e “Financeiro – Analista”, na definição das etapas você poderá dizer que a etapa X será executada pelo Conferente do Almoxarifado, e a etapa Y pelo Analista Financeiro. Nenhum outro usuário fora desses papéis poderá ser designado diretamente às tarefas via configuração. (Entretanto, note que você pode listar múltiplos papéis do mesmo departamento ou de departamentos distintos para cobrir todos os envolvidos.) 

Essa configuração não impacta diretamente outros módulos, mas tem forte impacto no workflow interno – garante que as tarefas sejam encaminhadas aos setores corretos.

Imagem mostrando a seção de Papéis Executantes preenchida

Após preencher todos os campos da etapa Dados Básicos, clique em Próximo para avançar. O sistema validará se nenhum campo obrigatório ficou vazio e se há pelo menos um papel executante adicionado. Caso falte algo, uma mensagem de atenção será exibida e você deverá completar antes de prosseguir.

3.2. Etapa 2 – Formulário

Nesta etapa, você definirá o formulário que será apresentado quando alguém iniciar este processo. Ou seja, são os campos de entrada de dados que o solicitante/preenchedor deverá fornecer ao abrir uma nova instância do processo. É possível configurar diversos campos de vários tipos (texto, número, data, listas etc.), agrupá-los em seções e marcar campos obrigatórios. Pense no formulário como as “perguntas” ou informações que precisam ser coletadas no início do processo.

Imagem das Etapas para cadastro de um Processo BPM  - Formulário

A tela do Formulário apresenta campos para você configurar um campo por vez e adicioná-lo à lista. Cada campo do formulário possui as seguintes propriedades configuráveis: Nome do Campo, Tipo, Itens da lista (se aplicável), Entidade (se aplicável), Grupo, Obrigatório, Mostrar no Grid. Após preencher as propriedades de um campo, você clica em Adicionar (+) para incluir esse campo na lista do formulário do processo. Repita até que todos os campos desejados estejam adicionados. Abaixo, há uma tabela que lista os campos já criados para este formulário, permitindo edição ou exclusão deles.

Imagem da etapa Formulário com um campo sendo adicionado e a lista de campos 

Campos de configuração do Formulário:

• Nome do Campo: o rótulo ou identificação do campo que aparecerá para o usuário final no formulário. Deve indicar claramente o que se deseja informar. Ex.: “Data da Compra”, “Descrição da Solicitação”, “Valor do Pedido”.
  Regras: campo obrigatório; até 100 caracteres. Não é possível haver dois campos com o mesmo nome exatamente igual no mesmo formulário (embora o sistema não trave explicitamente nomes repetidos, isso causaria confusão – recomenda-se nomes únicos).
  Impacto: o nome definido aqui será exibido como o título do campo no formulário quando o processo for iniciado. Também será usado como referência nos relatórios e na visualização dos detalhes do processo. Internamente, ao adicionar o campo, o sistema define também atributos Título e Descrição do campo iguais ao nome (esses atributos adicionais são utilizados eventualmente para fins de documentação ou como help texts, mas não são editados separadamente na UI; logo, preencha o nome de forma que sirva tanto como título quanto como breve descrição).

• Tipo: define o tipo de dado que o campo irá capturar. Ao selecionar o tipo, a interface pode exibir campos adicionais relacionados (por exemplo, se escolher tipo Lista, aparecerá a opção de itens da lista; se escolher tipo Entidade, aparecerá a seleção de entidade). Os tipos disponíveis geralmente são:

  • Texto Curto: um campo de texto simples (linha única) – use para nomes, assuntos etc.

  • Texto Longo: um campo de texto multilinha (como uma descrição detalhada) – permite parágrafos.

  • Número: campo numérico (inteiro) – para quantidades, IDs, etc.

  • Decimal: campo numérico com casas decimais – para valores monetários, porcentagens etc.

  • Data: um campo para data (com seletor de calendário).

  • Data/Hora: campo para data e hora combinadas (se o sistema oferecer, pode ser um tipo distinto).

  • Sim/Não (booleano): um campo lógico, exibido como um toggle ou checkbox (Sim/Não).

  • Lista de Opções: uma lista pré-definida de valores para escolher (campo do tipo dropdown/múltipla escolha).

  • Entidade: um campo de seleção de registro de outra entidade do sistema (ex.: selecionar um Cliente, Fornecedor, Produto, Pedido etc. já existentes no BomControle).
    (OBS: A nomenclatura exata dos tipos pode variar. No código do sistema, tipos são identificados por ID numérico – ex.: 1=Texto, 2=Textarea, 3=Número, 4=Data, 5=Lógico, 6=Lista, 7=Entidade. Você não vê os números na interface, apenas os nomes correspondentes.)
    Regras: campo obrigatório – selecione o tipo mais adequado aos dados que deseja coletar. Após adicionar um campo, evite mudar seu tipo posteriormente, pois isso pode afetar processos já iniciados; se precisar de alteração drástica, melhor excluir o campo e criar outro.
    Impacto: o tipo determina o formato de entrada de dados que o usuário verá ao iniciar o processo. Ele também influencia validações: por exemplo, se é Numérico, o sistema só permitirá dígitos; se é Data, exibirá um calendário e exigirá uma data válida; se é Lista, você deve fornecer opções (ver próximo item). O tipo também pode afetar relatórios – campos de data podem ser filtrados por período, campos booleanos contados como sim/não, etc. Além disso, o tipo “Entidade” cria um vínculo direto com um dado de outro módulo (isso é detalhado mais adiante). Escolher o tipo correto garante integridade dos dados e melhor usabilidade no preenchimento.

• Itens da Lista: (visível somente quando Tipo = Lista de Opções). Nesse campo, você define as opções que estarão disponíveis para seleção quando o tipo do campo for uma lista. Ao selecionar o tipo “Lista” (ou equivalente), a seção Itens da lista aparece, permitindo inserir múltiplos valores. A interface geralmente oferece um componente onde você digita um valor e pressiona Enter para adicioná-lo, podendo marcar um deles como padrão (selecionando um radio button ao lado do item).

Regras: é obrigatório definir pelo menos duas opções para listas (o sistema não permitirá salvar um campo do tipo lista com menos de 2 itens – pois uma lista de uma opção só não faz sentido). Você pode adicionar vários itens; marque um como padrão se desejar que ele venha selecionado por default no formulário (apenas um item pode ser padrão). Itens duplicados exatos não são permitidos. Caso não defina nenhum padrão, o formulário inicial não marcará nenhum (obrigando o usuário a escolher ativamente se o campo for obrigatório).

Impacto: os valores fornecidos aqui serão as únicas opções que o usuário poderá escolher ao preencher o campo. Garantir que cobrem todas as possibilidades necessárias é importante. Esse campo não interage diretamente com outros módulos, mas a escolha do usuário poderá ser usada em etapas posteriores do processo (por exemplo, via checklist ou condição manual por parte de quem executa). Lembre-se: alterar a lista após o processo em uso pode invalidar opções antes selecionadas em instâncias já iniciadas, então planeje com cuidado os itens.

• Entidade: (visível somente quando Tipo = Entidade). Se o campo for do tipo “Entidade”, este dropdown aparecerá para que você escolha qual entidade do sistema o campo irá referenciar. As entidades disponíveis podem incluir: Clientes, Fornecedores, Produtos, Usuários, Pedidos, Contratos etc., conforme as integrações previstas. Por exemplo, se você quer que o usuário selecione um cliente existente ao iniciar o processo, escolha a entidade “Cliente”.
  Regras: obrigatório selecionar uma das entidades listadas quando o tipo é Entidade. Ao selecionar, o sistema já conhece como buscar os registros dessa entidade. Quando o usuário for preencher o formulário, o campo aparecerá como um seletor (geralmente um autocomplete ou dropdown) carregando os dados reais da entidade escolhida.
  Impacto: esse é um campo poderoso, pois cria um vínculo direto entre a instância do processo e um registro de outro módulo. Impactos principais:

  • Integridade de dados: o usuário não digita livremente, ele escolhe um registro existente (evitando erros de digitação e permitindo consistência).

  • Referência cruzada: o processo “sabe” a qual objeto externo está relacionado. Por exemplo, se for um campo Pedido, ao iniciar um processo o usuário escolherá um Pedido existente; assim, a instância do processo fica relacionada a esse pedido. Isso possibilita, futuramente, que no detalhamento do pedido no módulo Vendas haja um link ou indicação desse processo associado (dependendo das implementações do BomControle, processos podem ser consultados a partir do registro da entidade).

  • Ações automáticas: embora não seja padrão out-of-the-box, campos de entidade permitem base para automações – por exemplo, uma etapa do processo poderia atualizar algum status no registro associado ou puxar informações dele (se houver customizações ou scripts configurados).
    Em resumo, ao usar campos de entidade, você está estendendo o alcance do processo a outros módulos: não há impacto imediato (o ato de selecionar um cliente não altera o cliente em nada), mas a existência dessa ligação enriquece o contexto e possivelmente as consultas integradas no sistema.

• Grupo: este campo opcional serve para agrupar campos do formulário em seções lógicas. Por exemplo, você pode querer separar campos de “Dados do Solicitante” e “Detalhes do Pedido” no formulário. Para isso, crie grupos correspondentes. O campo Grupo permite selecionar um grupo existente ou criar um novo (há um atalho “+” que abre uma modal de cadastro de grupo de campos).

Regras: não é obrigatório atribuir grupo – se não selecionar nada, o campo ficará sob um grupo genérico (muitas vezes exibido como “Sem Grupo” no formulário, ou simplesmente sem cabeçalho). Se muitos campos forem configurados, recomenda-se agrupar para melhor organização visual. Ao cadastrar novo grupo via atalho, dê um nome curto ao grupo (ex.: “Informações do Cliente”) e salve; ele já ficará selecionado para o campo atual.

Impacto: grupos definidos aqui se refletem como títulos/separadores no formulário apresentado ao usuário final. Eles não afetam dados, apenas a forma de exibição. Entretanto, do ponto de vista do usuário, tornam o preenchimento mais claro, e internamente podem ajudar a segmentar os campos por assunto. Em relatórios de instâncias de processo, os grupos também podem aparecer como seções. Em suma, é um elemento de formatação e organização.

• Obrigatório: indica se o preenchimento deste campo será obrigatório no momento em que o usuário iniciar o processo. É uma alternância Sim/Não (um toggle ou checkbox). Marque Sim para exigir que o campo não seja deixado vazio.

Regras: por padrão, os campos novos geralmente vêm como “Não obrigatórios” (depende do sistema – alguns podem já iniciar como não obrigatório, cabendo a você marcar se necessário). Se marcado Sim, o sistema impedirá a submissão do formulário inicial sem que haja um valor preenchido pelo usuário. Use obrigatoriedade somente para informações essenciais.

Impacto: campos obrigatórios influenciam diretamente a execução do processo: uma instância não pode ser iniciada sem aqueles dados. Isso garante qualidade mínima da informação coletada. Além disso, há impacto em Recorrência: se você planeja usar recorrência (processo auto-iniciado em intervalos regulares), tenha cuidado – processos agendados não têm um humano preenchendo o formulário toda vez, portanto se houver campos obrigatórios, o sistema poderá não conseguir criar a instância automaticamente. O BomControle até emite um alerta se você marcar um campo como obrigatório depois de ter configurado recorrências ativas, indicando que pode ser necessário ajustar as recorrências. (Ver seção Recorrência para detalhes.) Em suma, campos obrigatórios garantem dados completos, mas em processos automáticos podem exigir configuração adicional para fornecer esses dados.

• Mostrar no Grid: esta opção, geralmente um toggle Sim/Não, define se o valor preenchido neste campo deverá aparecer na grade de listagem de instâncias do processo. Em outras palavras, quando várias instâncias (requisições) desse processo forem listadas no módulo de BPM (por exemplo, numa fila de solicitações ou tela de monitoramento), você pode escolher até 3 campos do formulário para serem exibidos como colunas adicionais nessa listagem, facilitando a identificação de cada instância.

Regras: você pode marcar “Sim” para alguns campos relevantes. Porém, há um limite: no máximo 3 campos podem estar marcados como “Mostrar no Grid” para um processo. Se tentar marcar mais que 3, o sistema impedirá (exibindo erro e não deixando adicionar o quarto campo com essa opção). Esse limite existe para não poluir as listagens com muitas colunas e também por restrição técnica. Caso você já tenha 3 campos marcados e deseje trocar, terá que desmarcar um antes. Além disso, se você editar um campo e marca “Mostrar no Grid” quando já havia 3 outros marcados, o sistema bloqueará essa ação enquanto um não for desmarcado.

Impacto: campos marcados para exibição no grid facilitarão o acompanhamento do processo. Por exemplo, se você tem um campo “Valor do Pedido” e marca para mostrar no grid, ao olhar a lista de instâncias desse processo, você verá uma coluna com o valor de pedido de cada solicitação, sem precisar abrir uma por uma. Isso agiliza triagens e análises. Não há impacto em outros módulos diretamente, mas no uso diário é um recurso poderoso de visualização. Dica: escolha para o grid campos curtos e significativos (IDs, valores resumidos, status personalizados, etc.), evitando campos longos de texto.

Depois de configurar o Nome, Tipo, e eventuais Itens/Entidade/Grupo, e definir Obrigatoriedade e Exibição no Grid conforme desejado, clique em Adicionar (+) para inserir o campo na lista. O campo aparecerá na tabela abaixo, que possui colunas: Nome do Campo, Descrição, Título, Tipo, Obrigatório, Mostrar no Grid, Grupo, e Ações. Nessa tabela você pode:

- Verificar os campos adicionados e seus atributos (por exemplo, na coluna “Obrigatório” aparecerá “Sim” ou “Não” conforme marcado).
- Editar um campo adicionado: clicando no ícone de lápis na linha correspondente. Isso traz os valores de volta aos controles acima para edição; faça as alterações e clique em Atualizar (o botão de adicionar muda de ícone para refresh quando em modo edição). Atenção: editar campos já adicionados deve ser feito com cuidado, especialmente se o processo já estiver em uso – mudanças de tipo ou remoção de opções de lista podem afetar instâncias em andamento.
- Excluir um campo: clicando no ícone de lixeira na linha. O campo será removido da configuração do formulário (isso não afeta instâncias já existentes; elas apenas não terão mais esse dado novo nas futuras – campos removidos perdem os dados nas instâncias antigas para visualização futura, então só remova se tiver certeza).

Após adicionar todos os campos necessários do formulário, revise a tabela para conferir se estão corretos. A ordem dos campos na tabela será a ordem que aparecerá no formulário final (de cima para baixo). Se desejar reordenar, geralmente é preciso excluí-los e adicioná-los novamente na ordem certa, pois a interface não possui um recurso de drag-and-drop para ordenação (alternativamente, você poderia editar a “Ordem” nos metadados via API, mas isso foge do escopo do usuário final). Então, planeje e insira na sequência desejada.

Quando estiver satisfeito com o formulário definido, clique em Próximo para avançar à etapa Etapas. O sistema verificará se pelo menos um campo foi adicionado; caso nenhum campo tenha sido incluído, exibirá um erro (“Nenhum campo foi adicionado”) e não permitirá prosseguir – todo processo deve ter ao menos um campo no formulário (nem que seja algo simples como um campo “Assunto” ou “Descrição”). Preencha ao menos um para continuar.

3.3. Etapa 3 – Etapas (Fluxo de Trabalho)

Nesta etapa, você vai cadastrar as etapas de execução do processo, ou seja, as fases pelas quais ele passa após o formulário inicial ser preenchido. Cada etapa pode ser vista como um conjunto de tarefas ou ações a serem realizadas por um responsável. No BomControle BPM, as etapas que você definir aqui se tornarão tarefas sequenciais quando o processo for iniciado. 

Imagem das Etapas para cadastro de um Processo BPM  - Etapas

Por exemplo, num processo de compra, as etapas podem ser: “Análise da Solicitação”, “Cotação de Preços”, “Aprovação da Diretoria”, “Entrega do Produto”, etc. Você deverá definir o nome de cada etapa, a ordem (sequência), se ela é obrigatória, e pode especificar um checklist de itens dentro de cada etapa. O checklist serve para listar sub-atividades ou critérios que devem ser verificados naquela etapa.

A interface da etapa Etapas apresenta um botão Nova Etapa. Ao clicar nesse botão, uma janela/modal de cadastro de etapa se abre para você preencher os detalhes da etapa. Após salvar, a etapa é adicionada à lista exibida em forma de tabela. Você pode repetir o processo para várias etapas. Vamos detalhar os campos de uma etapa:

Imagem da modal “Nova Etapa” 

• Nome da Etapa: nome curto que descreve a etapa de forma clara. Por exemplo: “Análise Inicial”, “Execução do Serviço”, “Validação Final”.
  Regras: campo obrigatório; até 100 caracteres (suficiente para títulos curtos). Deve ser único dentro do processo – não repita nomes de etapas para evitar confusão.
  Impacto: o nome da etapa aparecerá para os usuários como título da tarefa quando o processo estiver em execução. Também é usado nos indicadores de progresso do processo. Escolha um nome que reflita bem o conteúdo da etapa, pois isso orienta o responsável sobre o que esperar.

• Ordem: número que indica a posição sequencial da etapa no fluxo do processo. A primeira etapa deve ter ordem “1”, a seguinte “2” e assim por diante.
  Regras: obrigatório; deve ser um número inteiro positivo. Não podem existir duas etapas com o mesmo número de ordem. Se você tentar usar um número já atribuído, o sistema avisará (“Essa ordem já foi inserida”) e não permitirá duplicar – use outro valor ou ajuste a outra etapa. Recomenda-se numerar em sequência sem saltos (1, 2, 3,...), mas tecnicamente saltos são aceitos (ex: 10, 20… – apenas a ordem relativa importa). A interface geralmente atribui automaticamente o próximo número disponível ao abrir “Nova Etapa”, mas você pode alterar antes de salvar.
  Impacto: a ordem define a sequência de execução. O processo sempre seguirá a ordem crescente das etapas: primeiro executa a etapa 1, ao concluir passa para a 2, e assim por diante até a última. Certifique-se de ordenar logicamente as etapas conforme o fluxo real de trabalho. Uma ordem incorreta poderia quebrar a lógica (por exemplo, “Concluir Processo” não pode vir antes de “Execução de Tarefa”).

• Checklist: lista de itens ou verificações que fazem parte da etapa. O checklist funciona como subtarefas ou pontos de controle que o responsável pela etapa deve checar/concluir. Por exemplo, numa etapa “Inspeção do Produto”, os itens de checklist poderiam ser “Verificar qualidade”, “Conferir quantidade”, “Registrar lote”.

Regras: pelo menos um item de checklist deve ser adicionado para cada etapa. Ao cadastrar a etapa, você terá um campo para digitar um item do checklist e um botão para adicioná-lo à lista interna. Você pode adicionar vários itens sucessivamente. O sistema exige que haja pelo menos um – se tentar salvar uma etapa sem nenhum item no checklist, receberá erro (“Preencha o Checklist”). Cada item de checklist pode ter até 200 caracteres, por exemplo, o suficiente para uma frase breve. É possível editar ou remover itens durante o cadastro da etapa (antes de salvar, e após salvar você pode reabrir a etapa para editar seu checklist). Não há limite rígido de quantidade de itens, mas lembre-se que todos precisarão ser marcados como concluídos pelo executor quando chegar nesta etapa.

Impacto: os itens de checklist serão exibidos como uma lista de tarefas dentro da etapa quando o processo estiver em execução. O responsável pela etapa verá esses pontos e poderá marcá-los conforme executados. Isso ajuda a garantir que nada seja esquecido. Do ponto de vista de controle, enquanto algum item de checklist não estiver marcado, a etapa pode não ser considerada concluída (dependendo da política interna de trabalho, embora o sistema não bloqueie formalmente o avanço se a pessoa marcar a etapa como finalizada – os checklists servem mais como orientação e registro). Nos relatórios, não há um acompanhamento individual de cada item de checklist (eles são contexto da etapa), mas o histórico da instância registra todos como feitos quando a etapa é concluída. Em suma, use checklists para agregar valor de controle de qualidade/processo dentro de cada etapa.

• Etapa Obrigatória: indica se a etapa é mandatória no fluxo ou se poderia ser pulada/cancelada. É um campo booleano (Sim/Não).
  Regras: não obrigatório marcar – por padrão, as etapas tendem a ser tratadas como obrigatórias (e esse flag é mais informativo). Se marcar Sim, significa que em nenhuma circunstância a etapa deve ser omitida; se marcar Não, indica que em certas situações a etapa poderia ser ignorada. Vale notar: atualmente, o BomControle BPM não tem uma automação para “pular” etapas com base em condições (não há fluxo condicional configurável via interface). Portanto, todas as etapas definidas aqui serão apresentadas sequencialmente. O campo “Obrigatório” serve mais para documentação e potencial lógica futura (por exemplo, pode ser usado em integrações ou simplesmente para que um gestor saiba que pode encerrar um processo sem passar por etapas opcionais).

Impacto: quando marcado como Sim (obrigatória), espera-se que aquela etapa sempre ocorra. Quando marcado Não (opcional), um usuário com privilégio ou regra externa poderia, teoricamente, finalizar o processo sem realizar essa etapa. No uso padrão do sistema, não há botão “pular” etapa – então, na prática, todas as etapas serão executadas a menos que o processo seja cancelado. Porém, esse atributo pode ser utilizado em relatórios ou dashboards para destacar etapas críticas versus complementares. 

Exemplo: em um processo complexo, talvez algumas etapas finais sejam complementares (opcionais), então marcá-las como não obrigatórias pode indicar que se o processo terminar antes delas, não é um erro. Em resumo, para o usuário final executando o processo não muda o comportamento diretamente, mas para quem analisa o desenho do processo, fica documentado quais etapas são estritamente necessárias.

Depois de preencher os campos da Nova Etapa (Nome, Ordem, itens de Checklist, etc.), clique em Salvar (na modal) para confirmar a inclusão da etapa. A modal será fechada e a etapa aparecerá na tabela de etapas na tela principal, com colunas: Nome, Ordem, Checklist, Obrigatório, e ações.

Na lista de Etapas:
- Verifique se todas as etapas desejadas estão listadas na ordem correta.
- Você pode editar uma etapa clicando no ícone de lápis na linha dela (isso reabre a modal com os dados preenchidos, permitindo alterar nome, checklist, etc. – lembre de salvar novamente).
- Pode excluir uma etapa clicando na lixeira. Se excluir, todas as etapas com ordem maior serão “puxadas” para cima? Na verdade, não há renumeração automática: ao excluir, fique atento para possíveis lacunas na numeração de ordem. É recomendável editar as outras para ajustar os números se necessário, embora, repetindo, lacunas na sequência numérica não impedem o funcionamento.
- A paginação nessa tabela funciona se você tiver muitas etapas (mas na maioria dos processos o número de etapas é relativamente pequeno, então todas ficam visíveis em uma página).

Requisito mínimo: pelo menos uma etapa deve ser adicionada para prosseguir. Caso contrário, ao clicar Próximo, o sistema alertará “Nenhuma etapa foi adicionada”. Assim, mesmo que seu processo seja simples e praticamente resolvido no formulário inicial, cadastre ao menos uma etapa (pode ser algo como “Procedimento” ou “Tarefa Única”) para representar a execução.

Uma vez satisfeitas as etapas, clique em Próximo para avançar à etapa Aprovação. Se o processo não requer etapa de aprovação, ainda assim você deve passar por essa próxima tela (poderá desativar a aprovação lá).

3.4. Etapa 4 – Aprovação

Nesta etapa, configura-se se o processo precisa de aprovação inicial e, em caso positivo, quem tem autoridade para aprovar e em qual prazo. A etapa de aprovação, se habilitada, acontece logo após o formulário ser submetido e antes das etapas de execução definidas anteriormente começarem. Ou seja, o processo ficará aguardando uma decisão de aprovação para só então seguir para as etapas operacionais. Isso é útil em processos de solicitação, onde um gestor deve aprovar a solicitação antes da execução (por exemplo: pedidos de compra, requisições de férias, descontos comerciais, etc.).

Imagem das Etapas para cadastro de um Processo BPM  - Aprovação

A tela de Aprovação contém basicamente um interruptor “Necessita aprovação?” e, se ligado, campos adicionais: Tempo máximo para aprovação, opção Superior direto aprova e a lista de Papéis Organizacionais que podem aprovar. Vamos detalhar:

• Necessita aprovação?: alternador Sim/Não que determina se este processo terá uma etapa de aprovação.
  Regras: padrão geralmente “Não”. Se Não, significa que ao iniciar o processo ele não exigirá nenhuma aprovação formal – ele irá direto para as etapas de execução (etapa seguinte no fluxo será a 5 – Acesso, pois Aprovação fica sem efeito). Se marcar Sim, então habilita os demais campos de configuração de aprovação. Essa decisão deve ser coerente com a natureza do processo. Se for um processo de autorização, validação ou qualquer situação que demande aval de alguém, marque Sim. Se for um processo meramente informativo ou operacional que não precisa de ok de nenhum superior, deixe Não.
  Impacto: marcar “Sim” insere automaticamente uma etapa de aprovação no fluxo do processo, entre o Formulário e as etapas de execução definidas. Isso significa que, quando o usuário iniciar uma instância, ao enviar o formulário ela não irá direto para as etapas normais; primeiro ficará pendente aguardando aprovação. Somente após alguém aprovar, é que as etapas de execução (definidas em 3.3) serão liberadas. Se “Não”, o fluxo ignora qualquer necessidade de aprovação e começa as tarefas imediatamente.

• Tempo máximo para aprovação: caso o processo necessite aprovação, você pode definir aqui um prazo limite para que a decisão de aprovação seja tomada. Consiste em um valor numérico e uma unidade de tempo (similar ao campo Tempo de execução). Por exemplo: “2 Dias” ou “8 Horas”.

Regras: este campo é opcional mesmo quando aprovação é Sim – você pode deixar em branco ou zero se não houver um SLA específico para aprovar. Se quiser estabelecer um tempo de resposta esperado, informe um número (até 3 dígitos, ou seja, pode ir de 1 a 999, adequando a unidade) e selecione a unidade (Minutos, Horas, Dias, etc.). Não existe impedimento de avançar sem preencher este campo (nesse caso, considera-se que não há prazo máximo formal).

Impacto: o prazo de aprovação serve como indicador de SLA. O sistema, ao longo do tempo de vida da instância, pode usar esse valor para destacar aprovações pendentes há muito tempo. Por exemplo, pode haver relatórios de “aprovações atrasadas” comparando a data de solicitação com o prazo esperado. Em algumas configurações avançadas ou integradas, esse tempo pode ser utilizado para enviar lembretes/escalonamentos (ex.: se passar do prazo, notificar um superior ou auto-aprovar/negar automaticamente). Porém, na configuração padrão do BomControle BPM, não há ação automática ao expirar o prazo – ele é mais um acordo de nível de serviço. Assim, definir esse campo ajuda no gerenciamento, mas o sistema não cancela nem aprova sozinho pelo estouro do prazo (a não ser que exista um fluxo de trabalho específico programado no Fluxo de Trabalho BPM para isso). Portanto, use para controle e visibilidade.

• Responsável do departamento do solicitante aprova esse processo: alternador Sim/Não que indica se o superior hierárquico direto do solicitante (quem iniciou o processo) deve ser um aprovador. Em termos práticos, marcar Sim ativa a regra de que o chefe daquele solicitante (gerente do departamento dele, por exemplo) terá autoridade de aprovação sobre a solicitação.

Regras: este campo só fica disponível se “Necessita aprovação” for Sim. Se marcado Sim, significa que independentemente dos papéis selecionados abaixo, o sistema irá considerar também o responsável pelo departamento do usuário que abriu o processo como um aprovador válido. Se marcado Não, a aprovação ficará restrita aos papéis definidos manualmente (próximo item). Nota: a definição de “responsável do departamento” vem do cadastro organizacional do BomControle – normalmente cada departamento/centro de custo tem um usuário marcado como responsável/gestor. É esse usuário que será envolvido. Caso o solicitante não tenha um superior definido (ex.: ele mesmo é o gerente ou não há ninguém atribuído), então essa opção não surtirá efeito prático (não havendo superior, ninguém adicional é incluído).

Impacto: habilitar o superior direto significa inserir uma camada hierárquica de aprovação. Exemplo: João submeteu o processo, ele pertence ao Departamento de Vendas cujo responsável é Maria (Gerente de Vendas). Com essa opção ativa, Maria receberá a tarefa de aprovação e deverá aprovar para o processo andar. Essa configuração torna o processo dinâmico, pois não precisa especificar nominalmente quem aprova – pega-se a hierarquia real da empresa. Em muitos casos, isso basta e você nem precisará listar papéis abaixo (apesar de poder). 

Se ambos forem usados (superior direto Sim e papéis aprovadores selecionados), então qualquer um dos designados poderá aprovar. Ou seja, o responsável hierárquico será incluído na lista de possíveis aprovadores juntamente com os papéis configurados. Não significa que precisam todos aprovar; geralmente é aprovação única por instância, então quem primeiro aprovar conclui a etapa (por isso deve-se pensar: se marcar superior direto e também escolher um papel, possivelmente várias pessoas verão a solicitação e a primeira que decidir resolverá). 

Essa redundância pode ser útil: por exemplo, superior direto aprova e papel “Diretoria” aprova – se o chefe imediato não aprovar dentro do prazo, talvez alguém da Diretoria possa intervir. Enfim, isso depende de política interna, mas o sistema por padrão trata todos listados (chefe direto + papéis) como um conjunto de autorizadores possíveis, bastando um para efetivar a aprovação.

• Papel organizacional que pode aprovar este processo: aqui você pode listar um ou mais Papéis Organizacionais cujos membros terão permissão para aprovar a solicitação. Funciona de forma semelhante à seleção de Papéis Executantes (campo 5), mas especificamente para aprovação. A interface apresenta um campo de seleção de Papel Organizacional e um botão Adicionar (+), e abaixo uma tabela “Papel organizacional – Departamento” listando os papéis adicionados.

Regras: válido somente se “Necessita aprovação” = Sim. Você pode adicionar nenhum, um ou vários papéis. Se nenhum papel for adicionado e o superior direto também não estiver ativo, o sistema não permitirá avançar – pois se precisa de aprovação, deve haver ao menos alguém apto a aprovar. Assim, é obrigatório definir pelo menos um aprovador, seja via superior direto ou via papel. O sistema verifica isso ao clicar em Próximo (se necessitaAprovacao e nenhum superior e lista vazia, exibirá erro “Nenhum papel organizacional que necessita aprovação foi adicionado”). Portanto, preencha pelo menos uma das duas opções (superior ou papel). Ao adicionar papéis, selecione na lista suspensa o papel desejado (a lista traz todos os papéis organizacionais cadastrados no sistema, você pode usar a busca pelo nome do papel). Após selecionar, clique em Adicionar (+). 

O papel aparecerá na tabela abaixo com seu nome e departamento. Evite duplicar – se tentar adicionar de novo o mesmo papel, o sistema avisará e não incluirá duplicata. Pode incluir diversos papéis de diferentes departamentos, se a aprovação for colegiada ou se vários níveis puderem aprovar (em termos do sistema, reforçando, qualquer um daqueles poderá realizar a aprovação, não sequencial). Para remover um papel da lista, clique no ícone de lixeira na sua linha.

Impacto: os papéis adicionados aqui representam grupos de usuários autorizados a aprovar. Quando uma instância do processo estiver aguardando aprovação, todos os usuários que pertençam a pelo menos um desses papéis (e estiverem ativos) receberão a tarefa de aprovar. Basta uma aprovação para cumprir a etapa – quando um usuário do grupo aprova, a tarefa some para os demais e o processo segue adiante. 

Portanto, essa lista geralmente serve para designar, por exemplo, “Diretor de Operações” ou “Comitê X”. Caso superior direto e papéis sejam combinados, todos esses entram no pool de aprovadores possíveis. Isso aumenta flexibilidade – por exemplo, “Superior direto aprova” cobre a maioria dos casos, mas se o solicitante for o próprio chefe ou não tiver, talvez você adicionou um papel “Diretor Geral” para cobrir esse cenário. Em termos de módulo BPM, a ativação da aprovação insere uma etapa no fluxo (entre formulário e etapas operacionais) cujo responsável será definido por esses critérios.

Não há reflexo direto no módulo Financeiro/Vendas/Estoque, exceto pelo fato de que esse processo precisa ser aprovado antes de qualquer ação ligada a esses módulos se concretizar. Exemplo: se o processo fosse “Solicitação de Despesa” (que impacta Financeiro), ter a aprovação significa que nenhuma despesa será lançada até ser aprovada – mas note, o próprio lançamento contábil não é automático, a aprovação apenas dá aval para que alguém prossiga e eventualmente registre no Financeiro manualmente (a menos que houvesse automação para isso).

Após configurar a aprovação conforme necessário, clique em Próximo. Se aprovação não for necessária (você deixou “Necessita aprovação” em Não), essa tela não exige nenhum outro preenchimento – basta seguir em frente (as demais opções ficam ocultas ou desabilitadas). Se for necessária e você configurou, o sistema verificará se a condição de aprovador foi satisfeita (conforme explicado, pelo menos um superior ou papel presente).

3.5. Etapa 5 – Acesso

Nesta penúltima etapa, define-se quem pode iniciar uma nova instância deste processo. Em outras palavras, quais usuários do sistema terão permissão para acessar o formulário inicial e criar uma solicitação desse processo BPM. Essa configuração é fundamental para controlar a visibilidade do processo: alguns processos podem ser restritos a certos departamentos ou funções (por exemplo, somente o RH pode iniciar um processo de Admissão de Funcionário), enquanto outros podem ser liberados para todos os colaboradores (ex.: um processo de Pedido de Férias, que qualquer funcionário pode iniciar).

A tela de Acesso apresenta três opções gerais (toggles) que facilitam a configuração ampla, e também permite especificar papéis e usuários individuais:

Imagem das Etapas para cadastro de um Processo BPM  - Acesso

• Todos os usuários do sistema podem acessar este processo: alternador Sim/Não. Se marcado Sim, significa que não haverá restrição – qualquer usuário logado no BomControle poderá iniciar este processo (desde que tenha acesso ao módulo BPM). Se marcado Não, então o acesso será limitado conforme as configurações específicas abaixo (papéis, usuários, etc.).

Regras: esse toggle é independente das outras duas opções exceto por um detalhe: ao marcar Sim, o sistema automaticamente marca também “Todos os responsáveis de departamentos” como Sim (porque se todos os usuários podem, logicamente todos os responsáveis também podem) e desabilita os campos de seleção de papéis e usuários (pois não faz sentido definir exceções – todos já têm acesso). Ao colocar Não, os demais controles são liberados para configuração granular.

Impacto: é a maneira mais ampla de distribuição. Se “Todos os usuários” = Sim, este processo aparecerá para toda a base de usuários (internos) no menu/início BPM. Isso é útil para processos gerais, como solicitações que qualquer um pode fazer. No contexto inter-módulos, isso não dá acesso a módulos em si, apenas permite que usuários de qualquer setor usem o processo. Deve-se ter cuidado ao abrir para todos: certifique-se de que o processo é realmente aplicável a todos, pois caso contrário será ruído na interface de quem não precisa. Exemplo: um processo “Reembolso de Despesas” provavelmente é para todos os colaboradores – então marque Sim. Já um processo “Controle de Estoque” talvez seja apenas para o pessoal do Almoxarifado – nesse caso deixe Não e restrinja a usuários/papéis específicos.

• Todos os convidados podem acessar este processo: alternador Sim/No. Convidados referem-se a usuários externos convidados para o sistema (por exemplo, usuários de portal do cliente, fornecedores com acesso limitado ou outros stakeholders de fora da organização principal). Se marcado Sim, quaisquer usuários com status de convidado (usuários externos) poderão iniciar este processo. Se Não, convidados não terão acesso – somente usuários internos (a menos que especificados nominalmente abaixo, mas geralmente convidados não entram em papéis internos).

Regras: essa opção funciona de forma parecida com “todos usuários”, mas dirigida a externos. Ela é avaliada separadamente: você pode ter “todos usuários internos = Não” mas “todos convidados = Sim” se quisesse um processo disponível apenas para parceiros externos, por exemplo. Normalmente, se “todos usuários” está Sim, convidados também poderiam ser considerados incluso (já que todos é todos, internos e externos). No entanto, por segurança e clareza, o sistema separa – então se deseja realmente todo e qualquer usuário, marque as duas opções. Caso contrário, especifique.

Impacto: quando ativado, pessoas externas com login no portal (convidados) verão esse processo e poderão iniciá-lo, o que pode ser útil para processos colaborativos (ex: um cliente abrindo um chamado, um fornecedor submetendo uma requisição). É uma forma de expor o processo para fora da organização. Deve-se usar com cautela: garanta que o processo não dá acesso indevido a informações internas quando acessado por convidados. Essa configuração não afeta módulos Financeiro/Vendas/Estoque diretamente, mas possibilita interação externa via BPM – por exemplo, um cliente iniciando um processo de devolução, etc., sem precisar de acesso ao módulo de vendas diretamente.

• Todos os responsáveis de departamentos podem acessar este processo: alternador Sim/Não. Se marcado Sim, todos os usuários que são marcados como responsável (chefe/gerente) de algum departamento no cadastro organizacional poderão iniciar o processo. Se Não, ser responsável não concede acesso especial – prevalecem as outras configurações.

Regras: essa opção é útil quando o processo é algo que apenas gestores podem iniciar. Só fica desabilitada se “Todos os usuários” estiver Sim (porque aí já inclui todos, então o sistema trava essa opção em Sim automaticamente). Se “Todos os usuários” está Não, você pode então optar por liberar para todos gerentes marcando aqui Sim. Isso não inclui subordinados automaticamente, somente aqueles usuários definidos como responsáveis de pelo menos um departamento.

Impacto: com essa opção ativa, a cobertura de acesso se amplia a todos os níveis gerenciais, independente do departamento. Exemplo: suponha um processo “Avaliação de Desempenho – Iniciar Ciclo”, que você quer que apenas gestores iniciem – marque “Todos os responsáveis de departamentos: Sim” e deixe “Todos os usuários: Não”. Assim, cada chefe de departamento verá o processo e pode iniciar para sua equipe, enquanto funcionários comuns não verão. Na prática do BPM, essa configuração verifica a flag de gestor dos usuários. Em termos de outros módulos: departamentos e responsáveis são conceito organizacional interno; essa permissão não se cruza com permissões de módulos Financeiro/Vendas, mas naturalmente muitos responsáveis têm cargos altos que têm acesso a módulos, porém isso é coincidência hierárquica.

Além dessas configurações gerais, a tela permite especificar manualmente Papéis Organizacionais e Usuários individuais que poderão acessar (iniciar) o processo, para casos mais granulados:

• Papel Organizacional (que pode iniciar): um campo de seleção de papel, acompanhado de botão Adicionar. Você pode listar aqui quais papéis estarão autorizados a iniciar o processo.

Regras: disponível somente se “Todos os usuários” estiver Não (caso contrário, não precisa listar papéis, já que todos podem). Se você adiciona um papel, automaticamente todos os usuários associados àquele papel ganham acesso ao processo. Pode adicionar quantos papéis quiser. Exemplo: adicionar “Vendas – Vendedor” e “Vendas – Gerente” significa que qualquer usuário que ocupe esses papéis (neste caso do departamento Vendas) poderá iniciar o processo. Não há necessidade de adicionar também os responsáveis se eles já estão nesses papéis – o acesso deles já está incluso via papel. Você pode adicionar papéis de diferentes departamentos conforme necessidade. Remova com o ícone de lixeira se incluir por engano.

Impacto: essa é a forma mais comum de restringir acesso a um processo a uma área/função. Ao utilizar papéis, você reflete a estrutura organizacional: apenas quem tem aquele cargo consegue ver o processo. Por exemplo, se for um processo de Lançamento de Nota Fiscal, você pode limitar aos papéis do Financeiro. Com isso, mesmo que “Todos os usuários” esteja desligado, você garante que o pessoal correto tem acesso. Essa configuração não interfere diretamente em outros módulos, mas assegura que somente pessoas treinadas (geralmente definidas pelos papéis) usem o processo, evitando solicitações indevidas vindas de outros setores.

• Usuários (específicos que podem iniciar): abaixo dos papéis, há um painel Usuários com um componente de seleção múltipla. Ele permite selecionar usuários individualmente para dar acesso, independentemente de seus papéis ou departamentos. A interface tipicamente oferece um campo de busca por nome do usuário; você encontra o usuário e o adiciona a uma lista.

Regras: também só habilitado se “Todos os usuários” = Não. Use este recurso para exceções ou casos muito específicos. Por exemplo, se apenas uma pessoa (digamos o diretor) de um determinado setor pode iniciar, e esse diretor não está marcado como responsável ou o papel dele não deve ter todos daquele papel com acesso – então você pode adicioná-lo nominalmente. Ao começar a digitar o nome, o sistema traz sugestões; selecione o usuário desejado e confirme (no componente, geralmente movendo para uma caixa de selecionados). Você pode adicionar vários usuários. Estes usuários não precisam compartilhar nenhum critério; podem ser de áreas distintas. Assim, mesmo que não estejam contemplados nos papéis liberados acima, se estão aqui eles terão acesso. Para remover um usuário, há opção de excluir na listinha do componente.

Impacto: serve para afinar as permissões. Todo usuário listado terá o processo disponível. Isso não dá a nenhum outro colega dele acesso, somente ele. É útil quando o acesso não segue exatamente a hierarquia ou cargos – por exemplo, um processo experimental liberado só para um usuário teste, ou um processo usado por um único funcionário responsável. Em termos práticos, isso raramente é usado em larga escala porque é trabalhoso manter muitos nomes individuais (preferível usar papéis), mas é ótimo para exceções. Não afeta outros módulos diretamente; é puramente controle de acesso no BPM.

Vale notar que combinações dessas configurações são possíveis. O sistema considera que ter acesso ao processo significa atender pelo menos uma das condições definidas. Ou seja, a lógica é do tipo: “Usuário pode iniciar se (Todos os usuários = true) OU (é convidado E convidados podem = true) OU (é responsável E responsaveis podem = true) OU (está em um dos papéis listados) OU (está na lista de usuários específicos)”. 

Isso significa que você pode, por exemplo, restringir a quase todos usuários exceto alguns removendo-os – mas cuidado: não há opção de exclusão de um usuário (apenas inclusão). Portanto, se você precisa que “todos possam, menos X”, o sistema não tem um filtro “NOT” direto – a solução seria abrir para todos e depois bloquear manualmente o usuário indesejado (via bloqueio do login dele ou controle de permissão no menu, o que foge do escopo aqui). Normalmente, porém, define-se de forma positiva quem pode.

Depois de configurar o acesso conforme desejado, clique em Próximo. Não há validação estrita aqui – é possível prosseguir mesmo sem selecionar ninguém especificamente, contanto que “Todos os usuários” esteja Sim ou algum critério seja marcado. 

Atenção: se, por equívoco, você deixar todas as opções em Não e não listar nenhum papel ou usuário, nenhum usuário poderá iniciar o processo! O sistema não alerta nesse caso. Portanto, certifique-se de que pelo menos uma condição foi fornecida para acesso. (Por exemplo, se deseja realmente restringir a ninguém – isso não faria sentido, a menos que o processo seja iniciado apenas via recorrência. Mas mesmo nesses cenários, recomenda-se deixar ao menos administradores com acesso.)

3.6. Etapa 6 – Recorrência

Esta etapa final é opcional e se aplica apenas se o processo puder/dev erá ser executado automaticamente em intervalos regulares. Recorrência significa que o sistema irá iniciar instâncias do processo automaticamente seguindo uma agenda definida, sem intervenção de um usuário. Esse recurso é útil para processos periódicos, como relatórios mensais, rotinas semanais de manutenção, renovações automáticas, etc. Se não se aplica (ou você prefere que todos os inícios sejam manuais), deixe a recorrência desativada.

Na tela de Recorrência, você encontrará inicialmente a opção “Processo permite recorrência?” seguida por um botão Nova Recorrência e uma tabela de agendamentos caso algum seja configurado.

Imagem das Etapas para cadastro de um Processo BPM  - Recorrência

• Processo permite recorrência?: alternador Sim/Não que ativa ou desativa a funcionalidade de agendamento.
  Regras: por padrão, está Não (ou seja, sem recorrência). Se você não deseja agendar o processo, mantenha em Não e simplesmente conclua o cadastro – o processo será iniciado somente por usuários, nunca pelo sistema automaticamente. 

Se marcar Sim, o botão Nova Recorrência torna-se clicável, permitindo adicionar um agendamento. Você pode alternar essa opção mesmo após ter criado agendamentos: por exemplo, se desmarcar (trocando para Não) e havia recorrências ativas, essas recorrências ficarão inativas (não rodarão enquanto estiver desabilitado). 

O sistema não apaga os agendamentos existentes ao desabilitar; apenas os ignora até que seja habilitado novamente. (Em todo caso, recomenda-se remover recorrências se não for mais usar, para evitar confusão.)

Impacto: habilitar recorrência faz o sistema monitorar datas e horas para disparar novas instâncias do processo conforme programado. Isso significa que processos podem ser iniciados “sozinhos” no futuro. Fique atento: se o processo tiver campos obrigatórios sem valor padrão e sem possibilidade de serem preenchidos automaticamente, a instância pode ficar travada aguardando esses campos – atualmente o sistema não permite fornecer dados para campos obrigatórios nas instâncias recorrentes, então a prática é não usar recorrência para processos que exigem entrada manual.

 Alternativamente, se recorrência e campos obrigatórios coexistem, você precisará editar cada instância iniciada automaticamente e preenchê-los, o que não é ideal. O sistema emite um aviso se você marcou campos obrigatórios após já ter recorrências: “Necessário editar as recorrências ativas” – indicando para revisar se faz sentido.

• Nova Recorrência: botão que abre uma janela para configurar um agendamento. Você pode criar múltiplas recorrências diferentes para o mesmo processo (por exemplo, uma que rode todo dia 10 e outra todo dia 20, ou uma semanal às segundas e outra às sextas – dependendo de necessidades). Ao clicar, surge a modal Agendar Recorrência do Processo, com campos típicos:

• Padrão de Repetição: escolha dentre as opções – comum ter: Diariamente, Semanalmente, Mensalmente, Anualmente ou até customizado (como a cada X dias). Se escolher Semanalmente, possivelmente aparece seleção dos dias da semana; se Mensalmente, dia do mês; etc.

• Horário: defina a hora do dia em que deve rodar (formato de hora).

• Data de Início: a partir de que dia essa recorrência começa a valer.

• Término: pode haver opções de término – nunca termina (recorrência infinita) ou data final ou após N ocorrências. Geralmente, no BomControle, configura-se uma Data de término se quiser limitar, ou deixa em branco para indefinido (o sistema então continua até ser cancelado manualmente).

Regras: pelo menos um agendamento deve ser criado se recorrência estiver habilitada e você deseja realmente uso automático – caso contrário, habilitar sem criar nenhum não faz efeito (permitido, mas inútil). Ao criar, verifique que os campos estão consistentes (ex.: se selecionar mensal dia 31, cuidado com meses que não têm 31; a configuração permite, mas logicamente nesses meses vai pular para próximo válido ou não rodar em meses menores, dependendo da implementação). É aconselhável definir um horário em que o sistema esteja normalmente ocioso se for um processo pesado, ou durante horário de expediente se requer ação humana logo depois.

Impacto: cada recorrência ativa fará com que, nos horários agendados, o sistema crie automaticamente uma nova instância do processo. Essa instância se comporta como se um usuário a tivesse iniciado naquele momento, com exceção de que não haverá preenchimento manual do formulário. Ou seja, os campos do formulário podem ficar vazios ou com valores padrão se existirem (o sistema não tem, atualmente, uma forma de pré-definir valores para campos do formulário nas execuções automáticas – ele simplesmente cria a instância e deixa os campos em branco, exigindo intervenção se forem obrigatórios). 

Essa instância seguirá então para aprovação (se houver) ou diretamente para as etapas. Você pode acompanhar instâncias criadas automaticamente no painel BPM – elas normalmente indicarão quem iniciou como sendo o sistema ou um usuário genérico (às vezes mostram como iniciadas pelo próprio responsável do agendamento ou um usuário “Master”). 

Importante: planeje processos recorrentes de modo que não fiquem travados esperando entrada humana logo no início. Por exemplo, um processo recorrente mensal de “Lembrete de Backup” pode não precisar de nenhum campo – apenas dispara etapas para alguém; isso é ideal. Já um processo “Manutenção de Equipamento” pode ter campo “Observações” que não precisa ser preenchido para iniciar – sem problemas; o técnico completará depois durante a execução.

Em termos de outros módulos, recorrências tornam o processo proativo: por exemplo, um processo BPM de Conferência de Estoque agendado mensalmente poderia gerar automaticamente uma tarefa para equipe de estoque verificar itens – isso impacta indiretamente o módulo de Estoque ao garantir rotina, mas não há integração sistêmica a menos que nas etapas alguém lance dados. Recorrências podem ajudar a não esquecer processos periódicos ligados a financeiro (fechamentos mensais), vendas (renovação de contratos) ou estoque (inventários cíclicos), mas não executam transações nesses módulos automaticamente – elas apenas criam a solicitação BPM para que um usuário realize as ações necessárias nos respectivos módulos.

• Lista de Recorrências Ativas: após cadastrar uma ou mais recorrências, elas aparecerão em uma tabela nesta tela, com colunas como: Repetição (descrição do padrão, ex.: “Mensal – Dia 1”), Término (data final ou “Sem término”) e ações.

• Você pode Cancelar temporariamente uma recorrência clicando no ícone de ban (um círculo com barra, representando cancelar). Quando clica, a recorrência fica marcada como cancelada (pode ser indicada na tabela com cor diferente ou texto “Cancelado”). O botão de cancelamento se torna como um toggle – ou seja, se clicar novamente (quando marcado cancelado, possivelmente o ícone fica vermelho), você “Desfaz cancelamento”, reativando a programação. Isso é útil para pausar um agendamento sem excluí-lo.

• Pode Editar uma recorrência existente clicando no ícone de lápis. A modal de agendamento reabrirá com os valores atuais, permitindo alterar padrão, horário, término, etc. Ao salvar, a programação é atualizada. (Obs: editar não afeta instâncias já criadas anteriormente, apenas as futuras execuções).

• Não há um botão direto de excluir recorrência na interface padrão; geralmente, “cancelar” cumpre esse papel (você cancela para não rodar mais). Se realmente quiser remover da lista, pode ser necessário editar e colocar uma data de término no passado para sumir automaticamente depois de passar, ou cancelá-la indefinidamente. Em todo caso, Cancelado = não será executado, o que na prática equivale a excluir do ponto de vista funcional.

Concluída a configuração de recorrência (ou decidindo não usar), você pode finalizar o cadastro. Clique em Salvar na barra de ações. O sistema então grava todas as informações do processo e retorna à listagem. Uma mensagem de sucesso confirma a criação. A partir desse momento, o processo está disponível conforme as regras de acesso definidas e pronto para uso.

4. Impacto do processo no módulo BPM e nos demais módulos

Um processo BPM configurado como acima impacta o sistema principalmente no âmbito do BPM:

- Ele passa a constar na lista de processos disponíveis para início para os usuários autorizados (conforme etapa de Acesso). Os usuários verão o nome e ícone do processo e poderão iniciar instâncias fornecendo os dados do formulário.

- Ao ser iniciado (manual ou recorrente), gera tarefas e pendências de acordo com as etapas e aprovações definidas. Essas tarefas aparecerão no painel de Atividades dos usuários envolvidos (por exemplo, um aprovador verá uma tarefa pendente de aprovação, um executor verá tarefas de etapa atribuídas a seu papel). Assim, o processo começa a rodar operacionalmente dentro do módulo BPM, envolvendo possivelmente vários departamentos conforme configurado.

- Acompanhamento e Histórico: gestores podem monitorar o andamento das instâncias desse processo através das telas de monitoramento do BPM (verificando quantas estão em aprovação, em qual etapa, atrasos conforme prazos definidos, etc.). Os campos configurados para mostrar no grid facilitarão identificar, por exemplo, pelo “Assunto” ou “Valor” sem abrir cada instância.

- Relatórios: os dados coletados no formulário podem ser extraídos em relatórios customizados do BPM. Os prazos (tempo de execução, tempo de aprovação) servem de base para métricas de performance – se instâncias estão demorando além do estimado, etc.

No que diz respeito a outros módulos (Financeiro, Vendas, Estoque): o processo BPM, por si só, não altera registros nesses módulos automaticamente. Ele funciona paralelamente como um fluxo de trabalho. Entretanto, há integrações indiretas e potenciais impactos:

- Os campos do tipo Entidade que referenciam dados de outros módulos criam uma associação. Por exemplo, se no formulário foi selecionado um Cliente ou um Pedido de Venda, a instância do processo guarda essa referência. Isso pode permitir que, na tela do Cliente ou do Pedido dentro do módulo Vendas, haja uma forma de visualizar processos relacionados (caso o BomControle apresente esse recurso em seu UI – muitas vezes existe um painel de “Processos vinculados” nas telas principais de entidade). Mesmo que não haja essa visualização direta, a equipe pode consultar manualmente qual processo está ligado a qual registro. Então, o impacto aqui é principalmente de trânsito de informação: o processo carrega consigo o contexto do módulo.

- Com base nos resultados do processo, usuários podem tomar ações nos outros módulos. Exemplo: você tem um processo “Aprovação de Crédito de Cliente” no BPM, onde após aprovação, um usuário do Financeiro manualmente altera o status do cliente para “Aprovado para crédito” no cadastro (módulo Vendas/CRM). O BPM nesse caso atuou como controlador antes de uma ação no módulo de origem. Assim, o impacto é procedimental: garante-se que nada seja feito no outro módulo sem passar pelo devido processo. Muitos processos BPM atuam assim, interligando departamentos antes que registros sejam efetivados em módulos transacionais. 

Outro exemplo: um processo de “Requisição de Compra” pode, ao final, pedir que o setor de compras emita um Pedido de Compra no módulo de Compras/Estoque do BomControle. O processo BPM coordena as aprovações e coleta dados, mas a emissão real da ordem de compra será feita no módulo de Estoque/Compras manualmente pelo responsável, usando as informações do processo. Logo, o processo impactou indiretamente o módulo Estoque ao orquestrar a criação de um pedido.

- Financeiro: processos envolvendo aprovação de despesas, reembolsos, adiantamentos etc., após aprovados pelo BPM, resultam em lançamentos financeiros reais (que um usuário do Financeiro realizará no módulo Financeiro). O BPM pode exigir que se preencha no formulário dados como centro de custo, valor, fornecedor – todos referentes ao Financeiro – e então, com o processo aprovado, o Financeiro utiliza essas informações confiáveis para lançar a despesa no sistema financeiro. O benefício é que nada entra no Financeiro sem antes passar pelo BPM de aprovação.

- Vendas: um processo BPM pode gerir, por exemplo, aprovações de desconto, aprovação de cadastro de novo cliente ou configuração de proposta. Após concluído, a equipe de Vendas ou o sistema (se houver automação) pode efetivar as mudanças no módulo de Vendas. 

Exemplo concreto: Processo de Aprovação de Desconto Comercial – o vendedor inicia pelo BPM pedindo X% de desconto em um orçamento (campo referenciando o Orçamento do módulo Vendas e o percentual desejado). O gestor aprova via BPM. Então, o vendedor aplica o desconto aprovado no orçamento dentro do módulo de Vendas. O BPM aqui funcionou como registro e controle da autorização. Esse registro pode ser posteriormente auditado – pelo processo você prova que o desconto foi autorizado.

- Estoque: processos BPM de inventário, conferência, requisição interna de materiais, etc., vão envolver o módulo de Estoque. Por exemplo, Processo de Inventário Mensal via BPM pode listar itens a contar (via checklist ou anexo), o responsável executa e anexa os resultados, e então no módulo de Estoque ele lança os ajustes se houver divergência. Ou Processo de Solicitação de Transferência de Estoque: alguém preenche no BPM o que precisa transferir; aprovação acontece; após isso, o almoxarifado registra a transferência real no módulo de Estoque. Assim, o BPM garante que só ocorram movimentações autorizadas.

- Nenhum impacto automático: é importante enfatizar que, a menos que haja integrações customizadas (scripts, APIs) configuradas, o BPM não cria, altera ou deleta registros nos módulos de Financeiro, Vendas ou Estoque por conta própria. Ele registra a intenção e aprovação de ações. A concretização da ação nesses módulos é feita manualmente pelos usuários responsáveis, usando como base os dados e decisões do processo BPM. Isso significa que a eficácia do BPM depende do cumprimento do procedimento pelos usuários – o sistema não vai, por exemplo, gerar um lançamento financeiro só porque um processo foi aprovado, a não ser que se desenvolva uma automação específica para isso. O BomControle oferece essa separação para garantir controle: o BPM cuida do como/quem/quando aprovar, e os módulos transacionais cuidam do registro contábil ou operacional real.

5. Exemplo de utilização do processo BPM

Para ilustrar, vamos considerar um Exemplo Prático: Processo de Aprovação de Compra de Equipamento.

• Cenário: A empresa tem um procedimento em que qualquer solicitação de compra de um equipamento (computador, máquina, etc.) precisa ser aprovada pelo gerente do solicitante e pelo departamento financeiro, e depois acompanhada até a entrega.

• Configuração no BomControle:

• Dados Básicos: Nome do processo: “Solicitação de Compra de Equipamento”. Tempo de execução estimado: 10 Dias. Ícone: um símbolo de carrinho ou caixa. Fluxo de Trabalho: selecionamos “Padrão BPM” (ou poderia ser categorizado como “Compras”). Papéis Executantes: adicionamos Departamento TI – Papel Almoxarife (que vai receber e entregar o equipamento) e Departamento Financeiro – Papel Contas a Pagar (que realizará o pagamento).

• Formulário: Campos adicionados:

  • Nome do Solicitante (Texto, mas poderia ser inferido do login – vamos supor deixamos para preenchimento caso peça para outro, marcamos Mostrar no Grid),

  • Departamento Solicitante (Entidade = Departamento, para registro – ou poderíamos pegar automaticamente, mas aqui listamos para transparência),

  • Equipamento Solicitado (Texto, obrigatório, descrição do item),

  • Justificativa (Texto Longo, obrigatório, razão da compra),

  • Valor Estimado (Número ou Decimal, obrigatório, valor aproximado, Mostrar no Grid),

  • Data Necessária (Data, não obrigatória, quando precisa do item). Não usamos campos entidade de Estoque pois o item pode ser algo a adquirir externamente, mas poderíamos se fosse padronizado. Agrupamos alguns campos em “Dados do Solicitante” (Nome, Dept) e outros em “Detalhes do Pedido” (equipamento, justificativa, valor, data).

• Etapas: Definimos etapas:

• “Aprovação Gerencial” – Ordem 1, checklist: “Analisar necessidade”, “Aprovar ou Rejeitar”; Obrigatória: Sim.

• “Aprovação Financeira” – Ordem 2, checklist: “Verificar orçamento disponível”, “Aprovar verba”; Obrigatória: Sim.

• “Compra do Equipamento” – Ordem 3, checklist: “Gerar pedido de compra”, “Receber nota fiscal”; Obrigatória: Sim.

• “Entrega e Conclusão” – Ordem 4, checklist: “Receber equipamento”, “Entregar ao solicitante”, “Coletar assinatura de recebimento”; Obrigatória: Sim. (Essas etapas cobrem do começo ao fim do processo. Notamos que as duas primeiras são aprovações de diferentes áreas; as duas últimas são execução.)

• Aprovação: Marcamos “Necessita aprovação: Sim”. “Responsável do depto do solicitante aprova: Sim” (isso cuida da Aprovação Gerencial – ou seja, o gerente do solicitante será o aprovador inicial). Tempo máximo para aprovação: 2 Dias (esperamos que o gerente decida em até 2 dias). Depois, para a aprovação financeira definimos explicitamente um papel: adicionamos o papel “Financeiro – Gerente Financeiro” na lista de aprovadores. 

Assim, quando a etapa de aprovação acontecer, quem poderá aprovar? Como configurado: o Gerente do solicitante (via superior direto) e qualquer Gerente Financeiro (via papel). Na prática, porém, queremos aprovação em dois níveis sequenciais, não paralelos – mas o BPM padrão trata todos listados como um conjunto paralelo. Para contornar isso, utilizamos duas etapas sequenciais (como definimos em Etapas 1 e 2). Então, como se comporta? Aqui precisamos entender: habilitamos a funcionalidade de aprovação do sistema que, porém, suporta apenas uma etapa de aprovação antes das demais. Como temos duas aprovações em série (gerente + financeiro), uma forma de implementar é:

• Usar a etapa de Aprovação do sistema apenas para o primeiro nível (gerente do depto). Então configuramos em Aprovação: Superior direto = Sim, e não adicionamos o financeiro aqui. Assim, o sistema nativamente vai exigir aprovação do gerente e depois seguir.

• Para o segundo nível (Financeiro), nós modelamos isso não via tela de Aprovação, mas sim como uma etapa normal do processo (Etapa “Aprovação Financeira” que definimos de Ordem 2). E atribuiremos essa etapa ao papel Gerente Financeiro na hora de especificar responsáveis pelas etapas (faremos isso pós-cadastro, pois na definição de etapas no cadastro inicial não escolhemos responsáveis – repare, poderíamos ter opção de dizer qual papel executa cada etapa, possivelmente essa atribuição ocorre posteriormente ou assume algum padrão. No BomControle BPM, geralmente as tarefas de etapas são assumidas por papéis executantes ou aprovadores; como configuramos Gerente Financeiro como aprovador na lista, poderíamos ter colocado ele aqui – mas para fins didáticos mantemos).

• Resultado: o sistema primeiro passa pela aprovação do superior (usando a mecânica interna da etapa de Aprovação configurada). Uma vez aprovada, entra na etapa 1 “Aprovação Gerencial” – mas notamos que essa etapa 1 que criamos poderia ser redundante se já usamos a mecânica interna. Poderíamos ter pulado criar etapa para aprovação gerencial e deixado só a interna. Vamos ajustar: suprimimos a etapa “Aprovação Gerencial” da lista de etapas, pois a aprovação do chefe será resolvida na funcionalidade de Aprovação do sistema. Então a primeira etapa operacional passa a ser “Aprovação Financeira” (que renumeramos para Ordem 1 agora, já que Gerencial foi tirada das etapas customizadas).

• Portanto, a configuração final seria: Aprovação do sistema lida com chefe imediato; após aprovada, inicia-se etapa 1 “Aprovação Financeira” (obrigatória) atribuída ao papel Gerente Financeiro; depois etapa 2 “Compra do Equipamento” (provavelmente atribuída ao comprador ou almoxarife); etapa 3 “Entrega e Conclusão” (atribuída ao almoxarife ou solicitante para confirmar recebimento).
  Em suma, adaptamos para ter as duas aprovações em série: uma usando o mecanismo nativo e outra como etapa normal.

• Acesso: decidimos que qualquer colaborador pode solicitar uma compra, então marcamos “Todos os usuários: Sim”. (Se quiséssemos restringir, poderíamos dizer que só gestores podem iniciar, mas neste exemplo deixa aberto – qualquer funcionário solicita para si, e será aprovado depois pelos superiores). Convidados não se aplica (um convidado externo não pediria compra interna), então não importa. Responsáveis também fica irrelevante já que todos podem. Não adicionamos papéis ou usuários específicos já que todos já têm.

• Recorrência: esse processo não é recorrente, é iniciado sob demanda, então deixamos “Permite recorrência: Não” (nenhum agendamento).

• Execução do Processo: Com essa configuração, quando um usuário (ex.: João, Analista do departamento Produção) quiser comprar um equipamento, ele vai no BPM e inicia “Solicitação de Compra de Equipamento”. Ele preenche o formulário informando o item (por ex. “Impressora 3D”), justificativa, valor estimado, etc., e envia.

• Imediatamente, o processo entra na fase Aprovação: o sistema identifica que o superior de João (digamos, Maria, Gerente de Produção) precisa aprovar. Gera-se uma tarefa de aprovação para Maria, com prazo de 2 dias visível. Maria recebe notificação e no painel BPM dela aparece essa solicitação pendente. Ela abre, vê os detalhes (campos preenchidos por João) e pode Aprovar ou Rejeitar. Se ela rejeitar, o processo é encerrado ali (instância finalizada como reprovada – João seria notificado e nenhuma etapa seguinte ocorreria). Se ela aprovar (o que vamos supor), o processo avança.

• Ao aprovar, o BPM registra a data/hora e quem aprovou (para histórico). Agora o processo entra na Etapa 1: Aprovação Financeira. Automaticamente, é criada uma tarefa para o Gerente Financeiro (digamos, Carlos) porque definimos essa etapa possivelmente com responsável desse papel. Carlos vê a tarefa “Aprovação Financeira da Solicitação X” com checklist “Verificar orçamento disponível, Aprovar verba”. 

Ele revisa a solicitação, verifica orçamento, etc. e então ele também tem opção de Aprovar ou Reprovar essa etapa. (Nesse caso, como é uma etapa manual, talvez ele atualiza um campo, mas essencialmente ele marca a etapa como concluída quando decide aprovar – possivelmente no sistema ele clica em “Concluir Etapa” ou similar, já que a aprovação aqui é implícita pela natureza da etapa; ou se quisesse recusar, poderia abortar o processo ou marcar não aprovado e interromper – BPM não tem um botão “reprovar etapa” padrão, mas ele poderia cancelar o processo ou devolvê-lo, dependendo de funcionalidades avançadas). Vamos assumir que ele aprova dando continuidade – talvez a empresa convém que se Financeiro discordar, ele comunique e cancele o processo.

• Com a aprovação financeira feita (Carlos concluiu a etapa), o processo passa para Etapa 2: Compra do Equipamento. Aqui, supomos que no cadastro de etapas definimos quem executa: provavelmente o Departamento de Compras/Almoxarifado. Lembra que adicionamos o papel “Almoxarife TI” nos Papéis Executantes? Essa etapa estaria atribuída a esse papel. Então, um usuário responsável por compras (por exemplo, Ana, do Almoxarifado de TI) recebe a tarefa “Compra do Equipamento para solicitação X”. No checklist ela tem “Gerar pedido de compra” e “Receber nota fiscal”. Ela então: realiza o procedimento fora do sistema BPM (efetua a compra real – possivelmente gerando um pedido de compra no módulo de Estoque/Compras do BomControle ou em outro sistema, e quando o fornecedor entrega, registra a nota fiscal). Ela pode anexar a NF ou indicar no processo que foi feita. Após completar as atividades, ela marca os itens do checklist como feitos e conclui a etapa.

• O processo avança para Etapa 3: Entrega e Conclusão. Provavelmente também atribuída ao Almoxarife TI (ou pode envolver o solicitante). Supondo que o almoxarife precisa entregar o item ao João. Ana agora faz a entrega, colhe assinatura do João fisicamente, e marca no processo as tarefas do checklist como feitas. Ao concluir essa etapa, o processo é finalizado com sucesso. João recebe notificação de conclusão.

• Durante esse fluxo, todas as informações ficaram registradas: quem aprovou e quando, quem executou a compra, etc. Se João tentar iniciar outra solicitação similar, terá que passar pelo mesmo processo – garantindo governança.

• Impactos observados:

  • Financeiro: Carlos (Gerente Financeiro) só aprovou via BPM, mas a compra efetiva impacta o orçamento. Provavelmente, ao aprovar, ele internamente reservou verba. Quando a nota fiscal chegou, o Financeiro (talvez via módulo Financeiro do BomControle) vai lançar um contas a pagar daquilo. O processo BPM em si não lançou o contas a pagar, mas garantiu que Carlos aprovasse antes de qualquer compromisso.

• Compras/Estoque: Ana usou possivelmente o módulo de Compras para gerar um pedido ou ao menos decrementou estoque etc. O BPM não criou nenhum registro de compra no sistema de Estoque – Ana o fez manualmente após a aprovação financeira. Entretanto, se formos ver o pedido de compra gerado, poderíamos vincular no campo de formulário se tivéssemos um campo “Número do Pedido” ou “ID do Pedido de Compra” (poderia ser um campo Entidade vinculado a Pedido de Compra). Poderíamos, por exemplo, ter adicionado no formulário ou preenchido depois. Esse seria um refinamento possível: após gerar o pedido, Ana edita o processo ou em uma etapa insere o número de pedido. Assim, no futuro, ao olhar o processo, está referenciado o Pedido X do módulo Estoque, fechando o ciclo.

• Vantagens do BPM aqui: sem esse processo, João poderia ter tentado comprar algo sem autorização, ou o pedido poderia demorar sem acompanhamento. Com BPM, tudo ficou transparente: cada passo registrado, notificações automatizadas (gerente e financeiro foram notificados pelo sistema), prazos foram respeitados (poderíamos ver no relatório se Maria ou Carlos demoraram mais que o prazo para aprovar). Papéis garantiram que somente pessoas adequadas interagissem (um usuário comum não conseguiria pular aprovações, nem iniciar sem permissão se tivesse restrito, etc.).

Este exemplo mostra como um Processo de Negócio BPM bem configurado não atua isoladamente, mas sim interage com pessoas e informações possivelmente de outros módulos, servindo de cola do fluxo. Todos os módulos envolvidos (Compras/Estoque e Financeiro) beneficiaram-se porque nenhuma ação foi feita sem registro ou autorização: o Financeiro só teve que pagar após aprovação formal, o setor de Compras só agiu após duplo aval, e a requisição de João foi atendida no prazo e documentada.

Conclusão

Ao implementar seus processos no BomControle, siga essa lógica: identifique os pontos de decisão (use a etapa de Aprovação ou etapas manuais conforme necessário), identifique quem executa (use Papéis Executantes e atribua às etapas), e controle quem pode iniciar (Acesso). 

Assim, você garantirá que o módulo BPM complemente os módulos de negócio da sua empresa, adicionando controle de fluxo, registros de auditoria e colaboração interdepartamental, sem perder a integração com as atividades-fim de cada área. Cada campo e configuração do cadastro de processo, conforme detalhamos, contribui para esse objetivo, então utilize este manual como referência ao configurar novos processos ou ajustar existentes, assegurando que todos entendam as regras de preenchimento e os impactos decorrentes. Boa configuração e bons processos!