Definindo a equipe nos projetos de BPM

Uma das primeiras dúvidas que costumam ocorrer quando uma empresa começa sua iniciativa de BPM é quais pessoas e perfis deveriam ser envolvidos nos trabalhos. Outro fator complicador é o fato de que podem existir variações na equipe envolvida, dependendo de etapa em que o projeto BPM se encontra.

Vamos começar revisitando, brevemente, as principais etapas do ciclo de melhoria de processos:

  • Modelagem de processos: neste momento o objetivo é modelar o processo atual em execução, gerando o modelo AS IS. Não se entra no mérito do quanto eficiente e efetivo o processo está sendo, ou quais são seus problemas/oportunidades de melhoria. As pessoas envolvidas nesta etapa, assim, devem ter conhecimento de como o processo é de fato executado na organização, mas não necessariamente precisam conhecer todos os seus problemas e ter uma visão mais abrangente
  • Análise de Processos: esta etapa tem o objetivo de coletar informações sobre o desempenho do processo, ou seja, fazer um julgamento de valor do quão adequado e eficiente um processo está sendo. Desta forma as pessoas escolhidas para atuar nesta etapa, além de conhecerem o processo, devem ser capazes também de identificar os problemas que ocorrem no processo e ter uma visão mais abrangente
  • Redesenho de Processos: esta etapa tem o objetivo de definir melhorias num processo para torná-lo mais eficiente e alinhado com os objetivos da organização, gerando o modelo TO BE. As pessoas escolhidas para atuar nesta etapa devem ser representativas dos papéis do processo, sendo importante estarem motivadas com a iniciativa BPM e carentes da mudança, de forma a auxiliar de maneira proativa a definição da visão futura do processo
  • Automação de processos: nesta etapa, o processo TO BE definido na etapa de Melhoria de Processos (TO BE) sofrerá melhorias do ponto de vista tecnológico, de forma a deixá-lo mais rápido, eficiente e automatizado onde for possível

Agora que relembramos as etapas, vamos listar os papéis comumente envolvidos em cada uma delas, descrevendo as suas típicas responsabilidades.

MODELAGEM DE PROCESSOS

Analista de Processos: atua como facilitador, coletando, reunindo e organizando informações do processo, criando o modelo do processo no nível de informação mais adequado
Representante Funcional: contribui com informações sobre as atividades que realiza durante a execução do processo
Analista de Sistemas/Negócios: apoia com informações sobre os sistemas de informação utilizados no processo
Especialista no Assunto: contribui com visão especializada sobre algum aspecto do negócio do processo (ex: um médico de alguma especialidade; num processo de venda online, seria um colaborador com profundo conhecimento da venda com cartões de crédito)

ANÁLISE DE PROCESSOS

Dono do Processo: avalia e aprova o resultado da análise, garante que a investigação dos problemas não será utilizada para achar culpados, mas sim como um meio de melhorar o processo e a organização
Analista de Sistemas/Negócios: apoia na identificação de problemas e limitações dos sistemas atuais
Representante/Líder Funcional: indica os pontos fortes, problemas e oportunidades de melhoria na execução das suas atividades do processo
Especialistas no Assunto: apoia no detalhamento de aspectos de uma determinada função do negócio
Analista de processos: facilitador que conduz o levantamento e documentação do diagnóstico atual do processo

REDESENHO DE PROCESSOS

Liderança Executiva: assegura que o processo irá atender as necessidades da organização, dando suporte e concordando com as mudanças
Dono do Processo: ajuda a garantir que o novo desenho se adéqua aos objetivos requeridos da organização
Representante Funcional/Participantes/Partes Interessadas: qualquer um que participe ou tenha atividades que afetem o processo. Em empresas maiores, pode ser a uma pessoa que represente uma classe. São fundamentais e trabalham com o Dono do Processo, para garantir que seus interesses no desempenho do novo processo sejam atendidos
Cliente: quando possível, envolvê-lo nesta fase aumenta as chances de sucesso
Analista de processos: atua como facilitador e lidera a equipe no desenvolvimento do desenho futuro do processo

AUTOMAÇÃO DE PROCESSOS

Dono do Processo: responsável pelos resultados do processo. Envolve-se na aprovação da proposição de melhorias e na apresentação da homologação, realizando a aprovação da solução automatizada
Gerente de Projetos: responsável por planejar e gerenciar as atividades do projeto de automação. Envolve-se na gestão da comunicação, tempo e custos do projeto em todas as etapas
Analista de Processos: apoia na revisão do processo, garantindo a integridade do negócio durante a avaliação das mudanças tecnológicas. Compartilha responsabilidade com o Analista de Sistemas na etapa de Proposição de Melhorias, envolve-se na validação do processo durante a homologação e implantação
Analista de Sistemas/Negócio: deve conhecer as funcionalidades disponíveis pela tecnologia a ser utilizada na automatização do processo. Compartilha responsabilidade com o Analista de Processos na etapa de Proposição de Melhorias. Responsável pelo detalhamento na implementação, apoia nas etapas de homologação e implantação
Arquiteto de Sistemas: profissional conhecedor da arquitetura de sistemas que suportará a automação de processos. Envolve-se na etapa de Implementação apoiando no projeto técnico com definições de infraestrutura de software
Desenvolvedor: profissionais que realizarão a implementação da automatização do processo, desenvolvendo os componentes de software conforme o detalhamento funcional do Analista de Sistemas/Negócio. Participam da etapa de implementação e de homologação através de correções e ajustes antes da implantação
Equipe de testes: profissionais responsáveis pela garantia da qualidade da solução. Verifica a aderência da solução à especificação funcional, sendo responsáveis pelo planejamento, elaboração e aplicação de roteiros de testes. Envolve-se nas etapas de implementação e homologação
Representante Funcional/Participantes do Processo: participam das etapas de Proposição de Melhorias para definir os requisitos e de Implementação para o detalhamento. Responsáveis pela homologação, validando a solução frente às expectativas e necessidades do negócio, através da verificação da aderência aos requisitos

OUTROS PAPÉIS IMPORTANTES NO GERENCIAMENTO POR PROCESSOS

Além disso, temos também papéis que costumam ser transversais, que dependendo do contexto e do papel podem se envolver em uma, algumas ou em todas as etapas:

Patrocinador e Dono do Processo: orientam sobre os objetivos da iniciativa e e asseguram que o resultado de cada uma das etapas estão adequados e alinhados aos objetivos da organização
Cliente: apoiando o levantamento e definições nas etapas
Designer de processos: atuando em conjunto com o Analista de Processos, focado na elaboração da representação gráfica dos processos
Arquiteto de Processos: responsável pela governança e manutenção do repositório de processos

Perceba que as definições acima refletem cenários comuns de ocorrer nas organizações, mas que não precisam ser seguidos à risca. Alguns exemplos em que é natural, e até esperado, existirem diferenças:

  • É muito frequente que algumas pessoas acumulem papéis/funções. Por exemplo:
    • O Dono do Processo também atua como Representante Funcional de alguma parte do processo
    • O Analista de Sistemas também é o responsável pelos testes
    • etc
  • Podemos ter projetos mais simples, em que não será necessária a participação de um ou mais papéis. Por exemplo, numa automação de processos com poucas integrações com sistemas externos, pode não ser necessária a participação de um Arquiteto de Sistemas
  • Se estamos falando de uma organização que está começando sua iniciativa de BPM, alguns papéis podem nem existir ainda, e precisarão ser definidos posteriormente, como costuma ser o caso do Dono do Processo

No final de contas, independente da quantidade de pessoas, nome dos papéis e quais papéis se deseja envolver formalmente na iniciativa, o importante é todas as pessoas chave estarem envolvidas, bem como todas as informações necessárias estarem disponíveis. Da nossa experiência, estes fatores aumentam consideravelmente as chances de um projeto de sucesso. :-)

 

Webinar: BPMN, BPMN, BPMS e RPA – O Guia Definitivo

Neste webinar, apresentado por nossa consultora Kelly Sganderla, falamos sobre os temas BPM, BPMN, BPMS e RPA – estas siglas que tem a companhado a jornada de quem atua em projetos de gestão de processos e transformação digital do negócio.

Confira aqui o video gravado e as respostas para as perguntas enviadas durante o evento!

Slides da apresentação estão disponíveis no slideshare:
https://www.slideshare.net/iProcessBPMeSOA/webinar-bpm-bpmn-bpms-e-rpa-o-guia-definitivo-93104242

Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: Você tocou em uma questão importantíssima que são os indicadores ponta a ponta. Eu sempre tenho muita dificuldade de definir indicadores que sejam realmente amplos e não representem exclusivamente o desempenho de áreas específicas. Você pode dar exemplos de indicadores ponta a ponta e dar dicas práticas de como defini-los, e como evitar os indicadores apenas departamentais?
Esta pergunta foi respondida no vídeo, mas vale a pena comparar, nos slides do link acima, as diferenças entre criar indicadores de desempenho das áreas (slide 7) e de desempenho do processo (slide 8).

Pergunta: Pode-se dizer então que a BPMN complementa o BPM?
Eu diria que BPMN está a serviço de BPM. Ela é uma notação para apoiar a prática de BPM em diversas etapas do ciclo de melhoria de processos. Não é a única, mas é uma das mais fáceis e completas, e por isso vem se tornando um padrão de fato no mercado.
Como comentou um outro participante em resposta a esta pergunta, durante o evento: “BPMN é uma notação, assim como a EPC. É uma linguagem lógica para você modelar um processo.”

Pergunta: Quais ferramentas são mais utilizadas para se desenvolver os diagramas do BPMN?
Existem diversas ferramentas no mercado, algumas com mais, outras com menos recursos. Confira nosso artigo 7 Ferramentas Gratuitas para Criar Diagramas de Processos com BPMN para conhecer algumas das ferramentas gratuítas que já testamos, mas tenha em mente que o objetivo da maioria delas é a simples criação de diagramas.

Há quem defenda que, no mapeamento de Processos, não seja realizado o chamado AS IS, declarando ter outros métodos que são mais rápidos e efetivos. Eu entendo muito necessário o AS IS. Como vocês entendem sobre isso?
Esta pergunta também foi comentada durante o evento. A modelagem AS IS é bastante importante em projetos de redesenho. Mas a simples modelagem do AS IS, por mera formalização, sem que haja um propósito maior para o seu uso, é realmente uma prática que tem caído em desuso, já que o processo tem vida e continua a evoluir, independente do desenho no papel.

Pergunta: Na análise do AS-IS alguns clientes costumam alterar o processo, dificultando a entrega do TO-BE. Como você trata essa situação? (Acredito que você já passou por isso).
Outro comentário na mesma linha: tb tenho muita dificuldade, mas nao tem muito como fugir disso, pois quando estamos desenhando o AS-IS, colocando no papel é que o cliente (no meu caso interno, pois nao sou consultor) lembra de atividades e tarefas que precisam fazer parte do processo e não tem como desconsiderar.
De fato, o negócio das organizações é dinâmico e em muitos casos não pode parar só por que há um mapeamento de processos em andamento. Mudanças legais ou emergenciais por exemplo, precisam ser priorizadas e muitas vezes passa na frente do projeto. É importante avaliar e discutir com o cliente, entretanto, se a mudança é simples e fácil de aplicar, ou se pode impactar o processo mais adiante. No segundo caso, é importante argumentar com ele que a mudança não é tão simples, e que para a segurança do negócio pode ser interessante uma análise para avaliar os impactos mais à frente e planejar melhor como implantá-la.

Pergunta: Qual a infraestrutura mínima necessária para uma organização gerenciar seus negócios usando a metodologia BPM com todos os recursos apresentados? Exemplo, uma pequena empresa em fase de estruturação com recursos limitados, consegue efetivamente desenvolver o método?
É um desafio grande, mas pode ser factível. Normalmente as organizações só percebem a importância de adotar o gerenciamento de e por processos quando já estão com processos muito complexos, robustos, com problemas demais, que precisam ser organizados, padronizados e gerenciados. Em uma organização pequena, os problemas dos processos geralmente são resolvidos mais facilmente e na hora em que acontecem, já que tem menos pessoas (e menos camadas hierárquicas) envolvidas. Para que ela perceba valor em adotar a disciplina de gerenciamento de processos, precisa que os líderes da empresa compreendam os ganhos que terão no decorrer do crescimento da empresa (com processos organizados e gerenciados o crescimento acontece de forma mais estruturada) e desde o princípio tratem o tema com relevância e prioridade entre as demais atividades do negócio.

Pergunta: a tarefa feito pelo robô na automação pode ser comutada entre um usuário e o robô, dependendo da necessidade?
Sim! E o robô pode eventualmente falhar na sua execução (digamos que o site que ele precisava acessar não estava no ar e a tarefa ficou pela metade). Então é possível que partes do trabalho sejam feitas pelo robô e outras por uma pessoa, ou eventualmente a tarefa seja realizada por um ou por outro, devido a alguma regra da organização. É por isso que chamamos os robôs em RPA de “trabalhadores automáticos”.

Pergunta: Você conhece ou recomenda outras ferramentas de RPA? Elas geralmente são free ou pagas?
Atualmente a iProcess trabalha com três ferramentas que estão entre as TOP internacionais e também uma importante ferramenta brasileira.
Conheça estas soluções – saiba mais em www.iprocess.com.br/rpa/

Pergunta: O RPA não faz o que o BPMS faz? Um exclui o outro? Ou ainda ambos podem trabalhar integrado?
Não! As ferramentas podem ser complementares. O BPMS tem como propósito orquestrar processos de negócio, comunicando e envolvendo diferentes participantes para que um processo completo possa ser executado.
Já o RPA serve para processamento de tarefas repetitivas, podendo substituir, em alguns casos, o trabalho de uma pessoa humana em um processo de negócio.
Confira no video como pode acontecer a interação entre BPMS e RPA.

Pergunta: Se a atividade é de usuário, mas está sendo executada por um robô, o símbolo BPMN utilizado continua o mesmo??
Sim, o símbolo BPMN usado é o mesmo, porque a interface é a mesma de um usuário. Assim, mesmo que o robô venha a ser desativado, uma pessoa poderá realizar o trabalho no seu lugar. A substituição é apenas de um trabalhador humano por um trabalhador automático.

Pergunta: Qual a diferenca de Indicador de Controle e Indicador de Performance?
Complementarmente, outro comentário nesta linha: Indicadores deveriam ser abordado em uma outra video aula, ma empresa onde trabalho existe uma grande dificuldade de entender a definição dos indicadores.
Este tema tem sido bastante apontado nos nossos cursos. Vamos planejar uma série direcionada para indicadores! Aguardem, em breve teremos notícias sobre isto :)
Enquanto isso, confira este artigo: Medidas, Métricas e Indicadores na Gestão por Processos

Pergunta: Você poderia detalhar um modelo de monitoramento de RPA?
O que precisamos monitorar nos processos automatizados com RPA/robotizados?
O monitoramento de RPA envolve outros componentes de gerenciamento, como uma sala de controle do desempenho, alocação e agendamento de robôs. Mas isto é um tema mais amplo, em breve voltaremos a aprofundar este tema!

 

Seja o profissional que vai liderar a Transformação Digital nos negócios da sua empresa

A equipe da iProcess orgulhosamente apresenta o curso de
TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,
um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Participe desta experiência que alia a teoria à prática, com dezenas vídeo aulas, artigos e cases alinhados com demonstrações de ferramentas e exercícios práticos de modelagem e automação em soluções de diferentes fornecedores, formando conhecimento através de uma vivência que facilitará o desenvolvimento da transformação digital na sua organização.

  • Conheça os conceitos da transformação digital, as tecnologias que viabilizam esta transformação e os benefícios da sua aplicação.
  • Entenda como as plataformas de processos podem se integrar aos sistemas de informação da organização.
  • Aprenda como fazer esta transformação, estudando e aplicando técnicas e ferramentas de redesenho tecnológico, que multiplicam a eficiência dos processos com o uso da tecnologia.
  • Compreenda os principais problemas e desafios e prepare-se para a jornada da transformação digital, analisando como as áreas de negócio podem liderar este movimento.
  • Saiba como aplicar uma metodologia ágil de transformação que traga ganhos rápidos, crescentes e constantes.

Conheça mais, inscreva-se e participe!

Quero me inscrever agora

Como realizar projetos de BAM?

No artigo BAM – Uma visão Geral, que publicamos recentemente aqui no blog da iProcess, passamos uma visão geral do BAM (Business Activity Monitoring), onde demonstramos as características, arquitetura comum e principais cenários de uso deste tipo de ferramenta.

Talvez agora o assunto seja do seu interesse, e você acha que a sua empresa pode se beneficiar da utilização desta ferramenta.

Mas neste caso, por onde começar?

A realização de um projeto de implantação de BAM pode ser caracterizada, usualmente, pela execução das seguintes grandes etapas:

1. Definição da ferramenta de BAM a utilizar: conforme citamos no artigo anterior, existem ferramentas de BAM que fazem parte de suítes de BPMS, e outras que são produtos independentes. Dependendo do tipo de ferramenta de BAM escolhida, a integração com sistemas externos poderá ter maior ou menor flexibilidade. No caso de uma ferramenta de BAM que faz parte de uma suíte BPMS, é necessário avaliar se é possível integrar a mesma com outros sistemas, pois em alguns casos só é possível a exibição de dados relacionados apenas aos processos sendo automatizados na própria suite.

Ressaltamos que a escolha do BAM não deveria ser uma escolha de um projeto, ou seja, a empresa não vai adotar uma nova ferramenta de BAM a cada processo implantado. Deve ser uma decisão corporativa e que permanecerá a longo prazo, então a escolha do BAM deve ser cuidadosa, tendo atenção a questões como aderência às necessidades de processos de toda organização (e não apenas de uma área) e que possua interface de comunicação com o BPMS utilizado para gerenciar a execução de processos automatizados.

2. Definição dos indicadores e gráficos de monitoramento necessários: é necessário discutir funcionalmente com os usuários de negócio quais são os indicadores e dashboards de monitoramento desejados, regras de segurança e acesso as informações (ex: num dashboard que será disponibilizado para todas as unidades, pode se definir que os usuários só poderão visualizar informações relativas à sua própria unidade), bem como alertas e ações sobre os alertas (se for o caso). Usualmente, esta é uma ação que está alinhada com a própria fase de modelagem, análise e melhoria de processos, onde estão sendo discutidos os processos e seus indicadores de desempenho. Assim, deste trabalho normalmente são extraídos requisitos de BAM, que permitirão  aos usuários realizar o acompanhamento dos novos processos. É importante ressaltar, no entanto, que um projeto de BAM pode ser uma ação mais “isolada” e até independente de outras iniciativas de BPM.

3. Análise técnica da origem dos dados: definidos quais são os indicadores e dashboards desejados, é necessário verificar como estes dados podem ser obtidos para serem enviados para a ferramenta de BAM. Via de regra, além dos dados de execução dos processos provenientes do BPMS, podem ser necessários dados de diferentes sistemas de informação existentes na organização (ex: ERP, sistemas legados). Assim, é necessário envolver as equipes técnicas responsáveis por estes sistemas para avaliar como estes dados devem ser obtidos, bem como a forma de integração sugerida. É importante, para isto, conhecer as possibilidades de integração que a ferramenta de BAM oferece, pois cada uma pode disponibilizar diferentes formas de integração (ex: Web Services, Filas, etc).

4. Desenvolvimento dos dashboards: após a análise técnica da origem dos dados, é necessário realizar a construção técnica dos dashboards e alertas de monitoramento (caso existam). Esta é uma etapa que irá envolver os desenvolvedores e arquitetos que conhecem a ferramenta de BAM, bem como as equipes técnicas responsáveis pelos sistemas de origem das informações. Nesta etapa a origem dos dados pode, caso necessário, ser “simulada” através de input manual de informações diretamente na ferramenta do BAM (se a ferramenta permitir).

5. Homologação dos dashboards: finalmente, nesta etapa serão testados os dashboards pelos usuários finais, já com a integração com os sistemas de origem funcionando, para verificar que estão exibindo as informações corretamente. São também testados os alertas de monitoramento e ações de contingência definidas (se for o caso), bem como as regras de segurança e acesso às informações.

Pela nossa experiência, a fase que costuma ser mais trabalhosa é a “Análise técnica da origem dos dados”. Isto porque, com o crescimento da organização e aquisição de diversos sistemas, muitas vezes existe replicação de dados em fontes diferentes, e não há uma visão de qual é a origem mais apropriada para determinadas informações. Além disso, a falta de uma governança de TI e padrões de integração também pode dificultar a escolha da melhor forma de integração com a ferramenta de BAM.

Podemos notar então que, no que se refere as macro etapas necessárias, um projeto de implementação de BAM não difere muito de projetos convencionais de implementação de TI. Porém, olhando no detalhe, é possível perceber que um projeto BAM tem diversas características e desafios próprios, que exigem uma equipe com conhecimentos específicos, sem falar na mudança cultural que a adoção da ferramenta pode trazer para a organização.

Abaixo, listamos alguns cuidados básicos que devem ser tomados durante a realização de um projeto de BAM:

  • Limitar o número de gráficos num dashboard: tente limitar o número máximo de gráficos num mesmo relatório,  para um desempenho mais otimizado e melhor ocupação da área disponível. Um número máximo de 4 a 6 gráficos por dashboard é geralmente recomendado.
  • Usar filtros: utilize quando possível filtros, de forma que o usuário possa restringir a quantidade de dados sendo exibida e assim minimizar os recursos de processamento necessários.
  • Avaliar a necessidade de histórico de dados: evite armazenar dados antigos na ferramenta de BAM, para fins de histórico. Caso realmente necessário, considere a criação de um repositório específico para este fim. Mas lembre-se que uma ferramenta de BAM tem o foco no presente (informação em tempo real) e não para ser uma referência para avaliações históricas.
  • Utilizar o recurso de drill-down: o termo drill-down (em português “detalhar”) refere-se à ação de clicar em alguma seção de um gráfico para obter o detalhamento de informações referente àquela seção. Podemos pensar, por exemplo, num gráfico de pizza que mostra a quantidade de solicitações em aberto por região do país. Ao clicar numa fatia, o usuário é direcionado para uma lista de solicitações especificamente daquela região. Assim, procure construir os seus dashboards de maneira a mostrar inicialmente apenas as informações mais abrangentes e relevantes, para que os usuários possam ter um rápido entendimento da situação atual. E então disponibilize a navegação drill-down para níveis com maior detalhamento, que poderão ser consultados se o usuário achar necessário.
  • Avaliar o ambiente de exibição dos dashboards: deve ser avaliado de que forma os dashboards serão acessados. Serão acessados através de desktops e notebooks? Ou através de telas maiores? Frequentemente os dashboards são previstos para serem exibidos em telões/televisores, posicionados em lugares estratégicos no ambiente de trabalho, de maneira que possam ser vistos a uma certa distancia pelos usuários. Então, se for este o caso, será necessário limitar a quantidade de gráficos e  informações sendo exibidas, prestando atenção a detalhes como resolução da tela, disposição dos gráficos, tamanho e cores das fontes utilizadas.

Como vimos, os projetos de BAM tem suas próprias características e desafios, que devem ser levados em consideração durante o planejamento. Levando estes fatores em consideração, não temos dúvida que uma ferramenta de BAM pode se tornar uma ferramenta de inestimável valor para o acompanhamento do seu negócio!

Você se interessou pelo assunto? Falamos mais de BAM no nosso treinamento “Modelagem de Processos para Automação” e oferecemos um treinamento específico da ferramenta “Oracle BAM“. Ambos os cursos são oferecidos pela iProcess Education.

Desmistificando o uso de eventos em BPMN

A boa modelagem de processos de negócio em BPMN é resultado do domínio da notação, fruto de estudo e compreensão dos elementos. Esse aprendizado se faz de diversas formas, principalmente através da aplicação prática e também com exemplos (bons e ruins). Coletamos algumas dúvidas comuns de iniciantes na notação BPMN, participantes dos nossos cursos e leitores do blog da iProcess, sobre a aplicação dos eventos, cujas respostas compartilhamos aqui.

1) É típico das ferramentas de modelagem de processos representarem elementos BPMN por cores, estas cores muitas vezes variam de ferramenta para ferramenta. Oficialmente que cor possui cada evento (Início, intermediário e fim)?

Ferramentas de modelagem como Bizagi, por exemplo, costumam diferenciar os elementos BPMN por cores

Os elementos BPMN não são representados por cores, mesmo que muitas vezes ferramentas de modelagem representem estes e outros elementos com cores, a especificação não define uma cor para o elemento, pelo contrário, representa na forma preto e branco.

Na grande maioria, estas ferramentas de modelagem possuem em suas configurações a opção para apresentar o desenho do processo em preto e branco.

O objeto evento é representado graficamente, na sua especificação, por um círculo. Eventos que marcam o início do processo são representados por uma borda de linha simples, já eventos intermediários são representados por duas linhas circulares concêntricas e eventos de fim são representados por uma linha simples com uma borda mais espessa.

A notação deixa o uso de cores livre e  podem ser usados tanto para identificar visualmente os tipos de elementos quanto com outros propósitos, como por exemplo: sinalizar com uma cor os elementos que estão mudando de uma versão para outra em uma revisão do processo, ou destacar eventos críticos para o processo.

2) O uso do evento de início e evento de fim são obrigatórios?

Obrigatoriedade do evento de início e evento de fim

Não são obrigatórios, porém seu uso é altamente recomendado por se tratar de uma boa prática, pois com estes elementos definimos e identificamos visualmente o ponto inicial e final do processo.

Regra: se um evento de início é definido, obrigatoriamente, um evento de fim também deve ser (e vice-versa).

3) Se o evento de início e evento de fim não são obrigatórios, como como identificamos o início e fim do processo quando estes eventos não estão definidos?

Neste exemplo, a tarefa "Escolher produtos" é o primeiro elemento do fluxo, portanto o processo inicia-se por ele. O fluxo segue até a tarefa "Realizar entrega da mercadoria", que por não apresentar um fluxo definido após sua ocorrência, é considerada o ponto final do processo.

Quando o processo segue um fluxo definido pelo fluxo de sequência (sequence flow), identificamos o início (ponto de partida) e fim do processo (ponto final) pelo primeiro e último elemento do fluxo.

4) Caso seja necessário, posso voltar ao início do processo ligando o fluxo de sequência ao evento de Início?

Emprego indevido da notação BPMN! A saída do gateway está retornando ao evento de início.

De forma alguma! A especificação deixa claro que o evento de início não pode ter nenhum fluxo de sequência apontando para ele. Além disto, o evento de início só pode ser executado/inicializado uma única vez para cada instância de processo.

No exemplo, o fluxo retornou de forma correta a tarefa "Solicitar Férias".

Se realmente for necessário que o processo volte ao seu início, o fluxo de sequência deverá ser ligado ao elemento que vem logo após o evento de início.

5) É obrigatório o uso de rótulo (nomenclatura) nos eventos? Como devo utilizar?

Exemplo de rótulo nos eventos do processo, seu uso é altamente indicado para compreensão correta do processo.

Não é obrigatório, porém o uso é considerado uma boa prática pois impacta diretamente na clareza e compreensão do processo. O rótulo deve apontar o motivo daquele processo ocorrer (evento de início), motivo para dar andamento (evento intermediário) ou motivo de chegar ao fim (evento de fim).

6) Um processo que conter mais de um evento de início é considerado sintaticamente incorreto (emprego indevido da notação)?

Pela especificação não! Porém a própria especificação deixa claro que a compreensão do processo pode ser prejudicada se houver vários eventos de início e que o modelador deve estar ciente que os leitores do processo podem ter dificuldades na interpretação do diagrama, por isto recomenda-se usar este recurso com moderação.

A boa prática nos indica o uso de tipos de eventos que abstraem a ocorrência de mais de um evento em um único objeto. É o caso do Evento Múltiplo e o Evento Paralelo.

Processo utilizando evento de início múltiplo.

No exemplo acima, o processo pode iniciar com uma ligação do 0800 ou por envio de SMS ou ainda por um e-mail. Basta que um destes gatilhos seja disparado para que o processo inicie. Importante destacar que o gatilho acionado cancela os demais.

Diferente do evento de início múltiplo, o evento de início paralelo requer que todos os tipos de eventos, abstraídos no objeto, sejam realizados para que o processo inicie.

Processo utilizando evento de início paralelo.

Para que o processo acima inicie, contendo o evento de início paralelo, deverá ser aprovado o investimento e confirmado o orçamento pelo financeiro. Necessariamente todas as condições devem ocorrer para que o processo inicie. Este é mais um motivo para abstrair diversos eventos em um único objeto (possibilidade de aplicar condições para o processo iniciar).

Existe ainda uma terceira forma de modelarmos o cenário de múltiplos eventos de início. É utilizando o Gateway de Início Baseado em Evento Exclusivo, outra indicação de boa prática para substituirmos pelos diversos eventos iniciais.

Processo utilizando gateway de início baseado em evento exclusivo.

O gateway de início baseado em evento exclusivo depende do resultado dos eventos imediatamente posteriores a ele. O primeiro evento que for disparado cancela os demais.

7 ) Vários eventos de fim (sempre que necessário) é considerado uma boa prática de modelagem?

Eventos de fim para cada estado em que o processo pode encerrar.

Sem dúvida, sim! Utilizar eventos de fim dá maior visibilidade e clareza das situações em que o processo pode terminar.

Em alguns casos, deixam de ser apenas boas práticas e se tornam vitais para o perfeito funcionamento do fluxo. É o caso do exemplo abaixo, em que as saídas do subprocesso de aprovação de compras são replicadas no processo de compras para informar o caminho que o fluxo deverá seguir.

O gateway que vem logo a seguir do subprocesso de aprovação de compras replica exatamente as mesmas saídas apresentadas dentro do subprocesso.

Você se interessou pelo assunto?

Este tema é explorado com mais profundidade em nosso curso “Dominando o Mapeamento de Processos utilizando BPMN2.0 Prático e Avançado” oferecido pela iProcess Education, onde abordamos de forma mais abrangente o tema.

 

 

Webinares iProcess 2014 – Primeiros Passos em BPM: da Venda Interna ao Primeiro Processo

Esta é a gravação do terceiro webinar da série lançada este ano pela iProcess, através do qual compartilhamos nosso expertise e experiência em gestão por processos.
Aos que participaram da transmissão ao vivo, um muito obrigado em nome do time da iProcess!

Aos que não puderam participar, esta é a oportunidade para conferir a gravação de nosso webinar de Primeiros Passos para a adoção de BPM na minha organização: da venda interna à escolha do primeiro processo, apresentado pelo Eduardo Britto em 25/09/2014.

 

A apresentação também está disponível no slideshare:
http://pt.slideshare.net/iProcessBPMeSOA/webinar-3-primeiros-passos-para-a-adoo-de-bpm-na-minha-organizao-da-venda-interna-escolha-do-primeiro-processo


Nesta quinta-feira, 02/10 Às 10h, Eduardo Britto continua a discutir sobre os primeiros passos para adoção de BPM, desta vez falando sobre os desafios do primeiro projeto. Registre-se agora e participe!
https://attendee.gotowebinar.com/register/5376585832758612225


Confira abaixo as respostas para perguntas enviadas por nossos participantes durante o evento:

Pergunta: “Em relação aos tipos de projetos, na sua opinião quanto é prejudicial automatizar após modelar?”
Resposta: Esta pergunta foi respondida durante a apresentação. Ao longo dos nossos 14 anos, percebemos que automatizar após a modelagem é uma prática que pode ser eficiente, porém também possui riscos. A modelagem para conhecimento do processo tende a apresentar a situação atual do mesmo, mas não se preocupa em resolver seus problemas. Assim, partir desta modelagem (AS IS) para a automação implica no risco de automatizar os problemas, o que além de fazer com que eles continuem existindo, pode também potencializá-lo (imagine um gargalo que acontecia algumas vezes por semana passar a ser executado muitas vezes mais devido à agilidade ganha na automação do processo?). Assim, o redesenho do processo, analisando os problemas evidenciados na modelagem AS IS e transformando-o em um processo mais eficiente tende a ser uma prática mais adequada antes da automação.

Pergunta: “Quais são as alternativas de fortalecimento e disseminação do trabalho do escritório de processo quando o apoio da alta direção não é efetivo?”
Resposta: As mudanças organizacionais requeridas com a adoção da prática de BPM costumam ser bastante impactantes na rotina da organização, de forma que o apoio da alta gestão se torna fator chave para reforçar a importância dos movimentos que serão realizados. Se a alta gestão não está alinhada com o escritório de processos, está na hora de conquistá-la – e a realização de um bom primeiro projeto de melhoria de processo com uma boa medição do antes e depois pode trazer aos gestores os números que eles precisam para compreender a relevância da atividade deste grupo de profissionais.

Pergunta: “Ao longo da apresentação, é bastante citada como projeto. Projeto tem começo, meio e fim. BPM para sua adoção e execução plena, não deveria ser encarada como uma disciplina?? (sendo esta disciplina envolvendo projetos)”
Resposta: Sim, o alinhamento é exatamente este. BPM é a disciplina, mas sua implementação na organização em geral acontece através da execução de projetos. Os projetos em BPM podem ter diferentes escopos, sendo alguns focados na implantação da governança, enquanto outros são específicos para a execução de etapas do ciclo de vida do processo (modelagem, transformação, implantação, etc), até a estabilização do processo quando ele passa a ser controlado pela gestão do dia-a-dia dos processos.

Pergunta: “Como se faz a junção dos esforços da Metodologia Lean, através dos Kaizens, e da Disciplina de BPM, através da transformação de processos?”
Resposta: Lean e Kaizens são excelentes ferramentas que o grupo de profissionais de processos podem adotar durante a atividade de análise para a identificação das oportunidades de melhoria dos processos, bem como no monitoramento da execução do processo.

Pergunta: “Se a empresa tiver que optar entre o apoio da direção ou apoio dos colaboradores envolvidos, qual é a melhor opção?”
Resposta: Esta pergunta foi respondida durante a apresentação. Implementar BPM sem o apoio da direção envolve mudança, que precisa de patrocínio, para sensibilizar as pessoas envolvidas. Mas o apoio das pessoas envolvidas também é importante para o sucesso da implementação.

Pergunta: “Transformação e Otimização faz parte do Ciclo BPM?”
Resposta: Sim, o treinamento Transformação e Otimização de processos é o segundo módulo do programa Ciclo BPM realizado pela iProcess Education. Para mais informações sobre este programa, visite o site: www.iprocesseducation.com.br/ipe00.