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.

Muito prazer, o CLIENTE! (Visão Outside in e Inside out)

Começamos com uma pergunta direta: QUEM É O CLIENTE?
Parece ser uma pergunta um tanto obvia, mas saber exatamente quem é (ou quem são) os seus clientes é fundamental para atender as suas necessidades.

Poderíamos afirmar que:

“Na perspectiva de BPM, cliente é somente aquele que se beneficia da geração de valor e está externo à organização.” (BPM CBOK 3.0, pag.47)

Mas, de uma forma geral, todos nós somos clientes, pessoas comuns que levantam pela manhã para trabalhar, que fazem compras no mercado, utilizam os serviços da rede bancária, que pagam contas, cidadãos que dependem do transporte público para chegar ao seu destino, ou seja, consumidores!

Todos nós, como cidadãos, por exemplo, somos clientes que dependem dos serviços públicos como o acesso à água e a luz, saneamento, limpeza pública e segurança.

Clientes que muitas vezes não têm as expectativas atendidas!

Ao mesmo tempo, quantas vezes, como cidadãos, somos questionados pelo prestador de serviços para saber o que achamos do serviço prestado?

Organizações estão empenhadas em oferecer o melhor valor agregado aos seus produtos e serviços, só que nesta tentativa, trabalham muito mais focados em otimizar e reduzir custos dos seus processos internos e esquecem de avaliar as expectativas dos consumidores destes produtos e serviços.
Assim, saber quem são seus clientes é o caminho para entender suas necessidades, expectativas e o que eles valorizam, e poder produzir e entregar aquilo que seus clientes esperam.

COMO ERA ANTES

Durante décadas organizações determinaram o que seus clientes necessitavam e definiam como seus produtos e serviços seriam disponibilizados. Até então, o cliente era pouco exigente. O foco era: aumento da eficiência na produção.

Esse cenário, de foco na otimização do processo em detrimento às expectativas do cliente, se percebe concretamente nesta célebre frase de Henry Ford, sobre a fabricação do modelo Ford T:

“O carro é disponível em qualquer cor, contanto que seja preto.”

O objetivo de Henry Ford era tornar o carro acessível a todos, aumentando a procura mas ao mesmo tempo reduzindo custos.

Conforme as empresas foram crescendo, foram surgindo novas oportunidades. As empresas foram criando novos planos de expansão e com isto os clientes começaram a impor o que queriam e como queriam. Sendo assim, as estruturas organizacionais e modelos de negócios começaram a tomar novas formas, mas persistia a visão de “dentro para fora”, ou seja, a busca pela eficiência na entrega de valor ao cliente.

OLHAR DE DENTRO PARA FORA OU DE FORA PARA DENTRO?

“Olhar de dentro para fora”: visão conhecida também por Inside out ou ainda por Foco NO Cliente.

É a visão sob o ponto de vista da organização. Se preocupa com o “de dentro”, com foco em seus produtos e serviços. É a organização que determina o que agrega valor para seus clientes e cria a cadeia de valor idealizado por Michel Porter.

Este modelo fazia sentido em sua época, onde a interação com o cliente não era algo comum, pois este ficava em segundo plano. A preocupação das organizações era em fazer as coisas certas. O foco era a eficiência, o controle de custos e a redução de erros.

Atualmente, as organizações estão focadas muito mais na eficácia, ao grau em que os resultados de uma organização correspondem às necessidades dos seus clientes.
Hoje a exigência está muito maior, principalmente no que se refere não apenas a qualidade ou preço dos produtos, mas principalmente ao atendimento real às suas necessidades.

“Olhar de fora para dentro”: visão conhecida também por Outside in ou ainda por Foco DO Cliente.

É a visão sob o ponto de vista do cliente, se preocupando com o que vem de fora, onde o foco é sempre o cliente. É o cliente que determina através de suas experiências aquilo que é importante para a empresa, o que gera valor para concepção dos seus produtos e serviços. A visão do cliente consiste em conhecer a organização pelo lado de fora, tem a ver com o valor percebido, se o cliente está ou não satisfeito.

O gerenciamento de processos consiste na experiência do cliente como ponto de partida para o desenho e implementação de processos. Os processos são desenhados em torno deste relacionamento do cliente com os produtos, serviços e pontos de contatos (momentos da verdade) que devem ser conhecidos pela organização para alcançar a real necessidade e satisfação de seus clientes.

Mas você pode estar se perguntando, como entender de fato as necessidades do cliente? Existe uma fórmula mágica para isto?

O que existe hoje são técnicas e métodos utilizados para “trazer o cliente” para análise e redesenho dos processos, através de coleta de informações como pesquisas de opinião, avaliação dos comentários e reclamações do SAC, comentários enviados por pessoas através de sites como o “Reclame aqui”, e até mesmo workshops e entrevistas envolvendo o cliente. Redesenho é um repensar sob a ótica do cliente, é uma nova visão do negócio. Isso é transformação (construir processos com foco do cliente).

Não se trata mais de apenas oferecer um produto para um cliente, mas de entender a sua real necessidade. O foco assim é a percepção de valor do cliente, o que ele acha que é importante. Esta experiência de consumo leva o cliente a participar da criação do processo ponta a ponta, e permite a organização identificar atividades, que pela visão de “dentro para fora” (inside out), não seriam identificadas.

Vejamos o exemplo da tão conhecida IBM. Empresa de 103 anos de vida, que já passou por altos e baixos em sua história e ainda está no topo das empresas de TI. Mas como explicar sua longevidade? Como ela pode estar viva e próspera em um setor caracterizado pela inovação e a mudança? Dois pontos nos chamam a atenção: a cultura e a mudança.


Thomas Watson
, fundador da IBM, criou sua empresa baseado em três crenças básicas. Achamos relevante destacar uma delas: “Prestar o melhor serviço ao Cliente”. Tinha por base a satisfação e desejo do cliente, ou seja, a crença é direcionada ao cliente e as suas necessidades.

O segundo ponto relevante e mais significativo foi à busca pela mudança, pela transformação.
Em 1991 foi apresentada como a “Nova IBM”, voltada para a visão do mercado atual e obcecada pela qualidade. Segundo a própria IBM, a mudança foi causada pelo aumento do nível de exigência dos seus clientes, o que gerou a necessidade de criar valor para seus clientes.

A IBM de hoje não se considera uma empresa de tecnologia, mas uma empresa que resolve business problems usando a tecnologia. Segundo a IBM, ela não vende “brocas”, vende ferramentas para produzir “buracos na parede”, a IBM é focada nos trabalhos que seus clientes precisam que sejam realizados.

Quem já assistiu o filme “Quero ser Grande” (Big, 1988) estrelado Tom Hanks, percebe uma ligação da história com a visão “outside in”.

No filme, Josh (Tom Hanks) se torna adulto da noite para o dia, e conhece o Sr. MacMillan, dono de uma empresa que fabrica brinquedos (naquela clássica cena do The Big Piano). Confira aqui a cena do filme.

O dono da empresa comenta com ele sua preocupação de que não estão obtendo boas vendas, e Josh acaba ganhando o emprego porque começa a expor para a empresa a visão do cliente (ele como criança em corpo de um adulto).

Com o foco do cliente, os produtos desenvolvidos pela empresa se tornam muito mais atraentes aos consumidores, e a empresa volta a gerar crescimento.

O foco hoje não pode ser mais o produto ou o lucro que este lhe proporciona, mas a experiência vivida pelo cliente ao consumi-lo. O cliente de hoje procura ser compreendido e ter suas expectativas atendidas. Para a organização fica a responsabilidade de conhecer seu cliente e entender porque ele procura pelo seu produto ou serviço. Conhecer o cliente e atender suas necessidades é um desafio, e deve ser encarado como uma grande oportunidade de crescimento para a empresa e para a geração de novas soluções inerentes ao mercado atual.

BPM como ferramenta para melhoria do nosso dia a dia

Muito se fala sobre modelagem, análise e redesenho de processos para melhorar e otimizar os processos das organizações.

Aqui mesmo no blog já falamos muito destes temas. Em se tratando de organizações tradicionais, contudo, é natural que as iniciativas de BPM sejam voltadas para objetivos mais “ortodoxos”, como por exemplo:

  • Redução de custos (objetivo clássico);
  • Redução dos tempos de execução (também clássico);
  • Melhorar o acompanhamento e controle do processo (extremamente clássico);
  • Melhor atender as necessidades do cliente (este deveria ser o objetivo final de tudo, não é?).

Mas… é possível aplicar também a melhoria de processos para melhorar o meu dia a dia, e a minha interação com as pessoas e empresas que prestam serviços para mim? A resposta: É claro que sim!

Num país com tantas deficiências, onde necessidades básicas muitas vezes não são atendidas, as oportunidades de melhoria saltam aos nossos olhos como… pipocas em uma panela aberta.

Podemos afirmar que o grande benefício, e ao mesmo tempo uma grande fonte de frustração de quem começa a praticar BPM é que isso não muda somente a sua visão dos processos e da sua empresa… Muda também radicalmente a sua visão de mundo, para sempre.

Tenha a plena certeza: após ser pego pela “febre” do BPM, a pessoa vai ser pega adotando técnicas de análise e melhoria de processos em todos os lugares:

  • Na fila do supermercado: pensando que as regras de distribuição dos empacotadores entre os caixas não está clara e bem definida, e precisa ser seguidamente orientada por um supervisor. E que, na sua opinião, este supervisor deveria destinar seu tempo a objetivos mais nobres (como verificar porque um cliente está com cara de zangado discutindo com o caixa ao lado);
  • Na fila de um banco: pensando porque se forma uma fila de 10 pessoas e existe apenas UM caixa atendendo no horário do almoço (justo o momento em que o banco tem mais movimento?);
  • No restaurante: pensando porque a fila está liberada nos dois lados do buffet, mas os pratos não se repetem nos dois lados, e não existe como pegar um prato do outro lado sem ter que entrar na fila de novo;
  • Ao telefone num auto-atendimento: pensando porque eu preciso repetir todo o meu problema cada vez que sou repassado de uma área pra outra, e por que RAIOS sempre pedem pra repetirmos informações que já foram passadas no começo da ligação? Porque preciso ser repassado de uma área pra outra, aliás?

É por isto que ter o hábito de utilizar técnicas de análise e melhoria de processos pode algumas vezes ser frustrante para o praticante de BPM. Pois este praticante passa a ter uma outra visão sobre as coisas, e adquire a habilidade de enxergar processos defeituosos e oportunidades de melhoria a todo momento, muitas vezes com pouco ou nenhum acesso para viabilizar alguma mudança.

Talvez seja neste momento a pior parte, que é ter a coragem de apontar as oportunidades de melhoria, criticar e sugerir. E não somente para as empresas privadas que nos prestam serviços. Para os órgãos públicos também, afinal seu propósito é servir o cidadão, e deveriam ter preocupação fundamental em melhorar seu atendimento.

Nós, profissionais do processos (ou você que está estudando e querendo ser tornar um), muito discutimos o “foco no cliente” ou “foco do cliente” na teoria de BPM, e como sempre deveríamos considerar a visão do cliente para realizar a melhoria em um processo.

Mas se quisermos fazer a diferença não somente para a nossa empresa, mas para a sociedade e o nosso país, temos que dar um passo além: vestir a casaca do analista de processos, enquanto clientes e cidadãos, e ajudar a melhorar todos os processos que temos contato: sugerindo melhorias, criticando, apontando problemas e soluções. E quem sabe, com uma pequena melhoria aqui e outra acolá, isso não pode deixar o seu dia a dia (e o de outras pessoas também) um pouco melhor?

O que BPM tem a ver com requisitos de software? Tudo!

Muitas organizações estão buscando adotar BPM (Gestão por Processos de Negócio) como disciplina gerencial. Isto quer dizer que a empresa começa a se organizar e ter seus negócios gerenciados com base em processos de negócio bem estabelecidos, que definem o quê a organização realiza para transformar matéria prima (ou informações) em produtos e serviços.

Conhecer os processos leva a uma série de benefícios para a gestão da organização, mas de forma especial:

  • Possibilita ter uma visão mais clara de como os clientes participam do negócio da empresa
  • Possibilita que a empresa se organize ajustando seus processos para atender os objetivos do planejamento estratégico
  • Possibilita olhar para o quê e como as áreas da empresa interagem para entregar produtos e serviços, de ponta a ponta (do recebimento de materiais/informações, passando por todas as etapas de transformação e agregação de valor até que o produto/serviço seja entregue).

Com isso, torna possível também à organização identificar situações onde pode gerar grande inovação, destacando-se no seu mercado por um produto de muito mais qualidade, ou muito menor custo – tendo como meta atender à expectativa dos clientes.

Então o processo de negócio bem definido nos ajuda a entender o quê a organização faz, não apenas dentro das áreas, mas também como o processo passa de uma área para a outra.

E o que isto tem a ver com requisitos de software?

Sabendo o quê é preciso fazer (e eliminando aquilo que é feito sem necessidade), a organização pode definir melhor como faz. E o como passa pelos recursos utilizados, inclusive, de software. Como uma pessoa realiza uma determinada atividade de um processo? Usando o sistema X. E o que é necessário para ela interagir com os sistemas nesta etapa do processo? Isso é que determina, da forma mais assertiva, os reais requisitos de software que o sistema precisa ter para que as pessoas façam o que precisa ser feito e como deve ser feito!

As integrações entre sistemas, as interfaces e casos de uso para a interação do usuário com o sistema, quais informações o usuário precisa obter, gerar, editar para poder concluir aquela atividade – tudo isso pode ser identificado e definido com maior clareza se temos a visão do processo.

Pense só: com a visão de processo, é possível identificar claramente que informações um participante de processo precisa gerar, para que os participantes das próximas etapas (que estejam por exemplo em outras áreas) possam fazer a sua parte. E com isso, conseguimos definir de forma assertiva tudo o que (e nada mais que) o usuário precisa fornecer em termos de dados no sistema para que o trabalho continue sendo realizado nas áreas seguintes com o menor risco de falta de informações e de erros possível.

Nós da iProcess (junto com muitos profissionais de processos que atuam na frente de tecnologia) acreditamos que o processo de negócio deve guiar a identificação dos requisitos de software. Esta abordagem se reflete na qualidade e aderência do software às necessidades do negócio quando a solução é implantada.

Veja resultados efetivos dessa abordagem nos cases implementados da iProcess.


5W2H: Ferramenta para a elaboração de Planos de Ação

timetoplan“Qualquer medição de desempenho deve começar com a identificação de o quê vai ser medido, o porquê de ser medido e qual valor será usado para comparação”.

Esta é uma recomendação do BPM CBOK v3.0 que culmina com a proposição de um instrumento para levantamento de medições, em forma de tabela (página 192), a serem realizadas nos processos, onde deverão ser considerados:

  • os objetivos da medição
  • os itens a medir
  • os parâmetros de comparação
  • os locais ou pontos onde as medições serão realizadas
  • o que deve ser medido
  • como serão realizadas as medições e
  • os responsáveis pelas mesmas.

É interessante perceber que BPM utiliza conceitos, termos e terminologia já consagradas e de uso tão popularizado como o 5W2H, oriundo da Gestão da Qualidade. Afinal, processos têm tudo a ver com qualidade, eficiência e desempenho. Nenhuma novidade de fato, pois BPM também assimila outros conceitos da administração, de disciplinas como a Reengenharia e Qualidade Total.

Muitas pessoas da área de processos, porém, possuem formação na área de tecnologia e tais conceitos podem não ser muito familiares. Por isso resolvemos chamar a atenção para essa ferramenta, os conceitos envolvidos e sua utilização.

5W2H é uma ferramenta para elaboração de planos de ação que, por sua simplicidade, objetividade e orientação à ação, tem sido muito utilizada em Gestão de Projetos, Análise de Negócios, Elaboração de Planos de Negócio, Planejamento Estratégico e outras disciplinas de gestão. De origem atribuída a diferentes autores, que vai desde os trabalhos de Alan G. Robinson, Rudyard Kipling, Marco Fábio Quintiliano até Aristóteles, essa ferramenta baseia-se na elaboração de um questionário formado por sete perguntas:

5W2H

As sete perguntas essenciais

Note que a sigla 5W2H origina-se nas letras iniciais das perguntas que devemos realizar.
O conceito por trás do termo significa que uma ação é influenciada por sete circunstâncias e que, ao elaborar um plano de ação, devemos responder, de modo formal, às seguintes questões:

  • O que deve ser feito? (a ação, em si);
  • Por que esta ação deve ser realizada? (o objetivo);
  • Quem deve realizar a ação? (os responsáveis);
  • Onde a ação deve ser executada? (a localização);
  • Quando a ação deve ser realizada? (tempo ou condição);
  • Como deve ser realizada a ação? (modo, meios, método, etc);
  • Quanto será o custo da ação a realizar? (custo, duração, intensidade, profundidade, nível de detalhamento, etc).

Aproveitando o clima da Copa do Mundo no Brasil, vamos exemplificar elaborando um plano de ação para organizar um evento de confraternização mensal para os funcionários de uma empresa, com o tema do campeonato mundial, em uma hipotética final entre Brasil e Argentina. (clique para ampliar)

Final Brasil x Argentina

Final Brasil x Argentina

Está claro que a ordem dos eventos pode ser alterada de acordo o tipo de evento, de organização, de contratação e etc. Colocamos as ações do plano em ordem cronológica (coluna Data) considerando uma possível dependência entre atividades. Mas essa é apenas uma abordagem.

É possível verificar, também, que as colunas “Custo” e “Local” não são tão úteis nesse caso, por ser um plano simples e por haver pouca variação nessas variáveis. Devemos considerar todas as sete circunstâncias descritas para elaborar o plano de ação, mas em casos em que uma destas circunstâncias seja fixa (como uma mesma data de realização, por exemplo) podemos deixar de representá-la em uma coluna de nossa tabela.

Da mesma forma, pode haver situações em que sejam necessárias ou desejáveis informações adicionais em nossa tabela. Além das circunstâncias normais, previstas na ferramenta 5W2H, podemos adicionar informações não necessariamente ligada às circunstâncias, mas que qualificam a própria ação ou seus resultados.

No exemplo abaixo, baseado na tabela  para levantamento de medições do BPM CBOK citada no início do artigo, percebe-se uma correspondência dos nomes dos atributos de medição com as questões do 5W2H:

Tabela para levantamento de medições

Levantamento de medições com 5W2H

No exemplo, as perguntas “O quê”, “Por quê”, “Onde”, “Como” e “Quem” são respondidas pelos atributos “Item a medir” + ” O que medir”, “Objetivo da medição”, “Onde medir”,  “Como será medido” e “Responsável pela medição”, respectivamente.

Note que foram suprimidas as questões “Quando” – visto que a medição deverá ser executada automaticamente pelo processo ou sistema – e “Quanto”, pois não se aplicam a este caso. Também foram adicionados dois atributos de medição que não corresponde a nenhuma das 7 questões da ferramenta: “parâmetro de comparação” e “polaridade do indicador”.

Se você ainda não utiliza 5W2H em suas tarefas diárias, comece a pensar quais os planos de ação você poderia formalizar com esta ferramenta e coloque em prática na primeira oportunidade. Você perceberá que se trata de um excelente modo de formalização do planejamento, detalhamento da ação, comunicação de prazos e responsabilidades. E lembre-se de compartilhar nos comentários as suas experiências e dicas.