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.

Métodos para levantamento de informações na Modelagem e Análise de Processos – Parte 2

No primeiro artigo da série (veja aqui) falamos sobre os métodos Pesquisa, Entrevista e Observação Direta. Neste segundo e último artigo da série abordaremos o restante dos métodos utilizados para coleta de informações para o trabalho de modelagem.

WORKSHOP ESTRUTURADO

Workshop estruturado é um método utilizado para a coleta informações através de reuniões com os representantes dos papéis envolvidos no processo, reunindo diferentes pontos de vista, visando o detalhamento e a modelagem do processo de modo interativo.

photo credit: juhansonin via photopin (cc)

Agendamento do workshop

A escolha correta dos envolvidos é crucial para uma reunião produtiva, mas afinal como escolher as pessoas certas para a reunião?

  • Especialistas: Ninguém melhor para explicar um determinado processo do que as pessoas que trabalham nele. São os executores do processo, usuários do sistema ou membros de equipes operacionais com profundo conhecimento sobre certas funções ou operações de negócio. Quando em grande número são representados por usuários-chaves que se fazem presente no workshop. Representados normalmente pelos papéis de Representantes Funcionais ou Gestores Funcionais.
  • Liderança: Outro papel de importância na reunião é o do Dono do Processo, este é o responsável pelo processo ponta a ponta. Defende as prioridades e assegura que o processo atenda às expectativas de desempenho esperado pelo cliente. Não podemos esquecer também do Patrocinador, representado usualmente pela liderança executiva, gestores, diretor ou gerente da área responsável pelo processo. Apesar de não se envolver de forma integral, participa geralmente de reuniões estratégicas que determinam o caminho que o processo irá trilhar. Estes papéis possuem uma visão macro do processo.
  • Facilitador: Normalmente representado pelo Analista de Processos ou Designer de Processos. É o responsável pela condução adequada da reunião e por garantir que todos os participantes sejam ouvidos. Para isto deve ter a habilidade para lidar com pessoas, resolver conflitos e manter o foco no objetivo do workshop.

A divisão apresentada acima contendo especialistas, liderança e facilitador compreende uma abordagem mais estruturada e pode variar de empresa para empresa, levando em conta a sua maturidade em BPM. O mesmo vale para as convenções de nomenclaturas para os papéis descritos.

Outras questões que devem ser levadas em conta para escolha dos envolvidos:

  • O participante do workshop deve ter a competência e o conhecimento necessário para descrever suas atividades e se posicionar quanto suas divergências.
  • Os envolvidos devem ter bom relacionamento, para isto o facilitador deve se informar sobre conflitos de interesses e embates políticos entre gestores e equipes.
  • Disponibilizar uma agenda viável para todos os participantes.

Vantagens

  • Redução do tempo de desenvolvimento do modelo devido ao entendimento comum criado entre os participantes.
  • Resolução de conflitos no momento do workshop.
  • Redução do número de intermediadores evitando futuros problemas de comunicação.
  • Redução do tempo do acompanhamento das partes envolvidas na evolução do modelo final.
  • Facilitador com habilidades de técnicas de modelagem.
  • Facilitador com apoio de Designer de Processos (trabalho em dupla) na modelagem do processo; principais impactos na redução do tempo de execução e validação do modelo com processo aprovado na mesma reunião.

Desvantagens

  • Desgastes em deslocamentos / viagens – Participantes muitas vezes encontram-se em locais físicos distintos.
  • Altos custos de viagens.
  • Conciliar agenda dos participantes.
  • Custo com hora/homem  – 100% do tempo de todos ao mesmo tempo em reunião.
  • Evitar paralisia por análise – Seleção do escopo e escolha do processo e profundidade da análise devem ser definidos com muita clareza.

CONFERÊNCIA VIA WEB photo credit: JulianBleecker via photopin (cc)

A Conferência via web ou Videoconferência como também é conhecida, é um método semelhante ao Workshop Estruturado. Utilizado quando os participantes estão em locais físicos distintos e sem a disponibilidade para viagens.

Vantagens

  • Redução de custos de deslocamentos e viagens.
  • Redução no tempo de deslocamentos entre unidades.
  • Utilizado para se buscar um consenso sobre um mesmo processo desenvolvido em diferentes unidades.

Desvantagens

  • Não funcionam muito bem com grupos grandes.
  • Dificuldade de conduzir a participação individual dos participantes.
  • Baixa qualidade de áudio e vídeo.

Atenção para a infraestrutura tecnológica requerida que dependerá da necessidade de cada projeto/empresa. Alguns pontos devem ser observados:

  • Disponibilidades de equipamentos/periféricos de áudio e vídeo.
  • Qualidade de velocidade de banda da internet para transmissão, disponibilização de vídeo e eventuais imagens, acompanhamento em tempo real do processo que está sendo modelado.
  • Softwares apropriados para conferência.

FAZER EM VEZ DE OBSERVAR

photo credit: ColorTime via flickr (cc)

Método conhecido também como “aprendizado do aprendiz”, muito utilizado em tarefas repetitivas. Consiste em aprender o que é feito e então executar o processo.

Ao ensinar as atividades, podem surgir informações de tarefas e passos que ocorrem de forma inconsciente, isto permite que o observador tenha um conhecimento mais detalhado das tarefas realizadas.

A execução do processo pelo observador pode ajudar a coletar alguns detalhes das atividades que de outra forma não seriam observados. Sempre que possível, é interessante ter um segundo membro da equipe observando o processo de aprendizagem para auxiliar na identificação de detalhes das atividades.

ANÁLISE DE VÍDEO photo credit:  Flickmor via flickr (cc)

Similar à observação direta  (veja mais sobre o método Observação Direta no artigo anterior), a análise de vídeo auxilia na identificação de evidências à distância e permite que o executor realize suas atividades de forma mais natural.

A presença de um equipamento de gravação permite uma adaptação mais rápida do que a de um observador ao seu lado.

Outra vantagem é que os vídeos podem ser mais tarde assistidos pelo executor e este narrar suas atividades e ações executadas fora do campo da lente, isto auxilia na identificação de informações não vistas pelo observador.

SIMULAÇÃO DE ATIVIDADES

photo credit: Wonderlane via flickr (cc)

A simulação de atividades é utilizada para identificar possíveis falhas humanas e desvios na execução do processo. Uma forma de simulação seria, durante a entrevista ou workshop, a realização de uma análise apurada do comportamento de cada atividade do fluxo do processo. Esta análise consiste em avaliar o que dispara esta atividade (entradas), seu resultado (saídas) e regras estabelecidas para execução desta atividade.

 

Como falamos nos dois artigos, cada método tem suas vantagens, desvantagens e o esforço necessário para que possa ser realizado. Questões como tempo requerido, altos custos de viagens, conciliar agenda dos participantes, suporte à infraestrutura tecnológica e habilidades em técnicas de modelagem são apenas alguns pontos a serem observados antes de optar pelo método a ser utilizado no levantamento de informações.

Não há um método único que seja melhor, cada projeto de modelagem ou análise de processos deve considerar quais métodos de coleta de informações são mais apropriados e eficazes para o processo que está sendo estudado.


Conheça mais sobre estas e outras atividades relacionadas à modelagem de processos no curso de Modelagem de Processos de Negócio da iProcess Education.

Desmistificando tipos de tarefas em BPMN: Tarefas automáticas

No artigo anterior (Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual) iniciamos uma série de três artigos sobre os tipos de tarefas em BPMN. Para facilitar o entendimento, estamos discutindo os os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefas de execução de rotinas automáticas

Para representar situações em que rotinas que são executadas automaticamente no processo (em que seu acionamento é determinado pelo andamento do fluxo do processo, sem que haja uma pessoa para acioná-lo), BPMN sugere três tipos de tarefa: tarefa de serviço, tarefa de script e tarefa de regra de negócio:

Os tipos de tarefa automáticas: tarefa de serviço (service task), tarefa de script (script task) e tarefa de regra de negócio (business rule task)

De acordo com a especificação:

“Uma Service Task (tarefa de serviço) é uma tarefa que usa algum tipo de serviço, que pode ser um Web Service ou uma aplicação automatizada.” (pág 156)

“Uma Script Task (tarefa de script) é executada pelo motor de processos de negócio (business process engine). O modelador ou implementador define um script em uma linguagem que o motor de processos consegue interpretar. Quando a tarefa estiver pronta para iniciar, o motor de processos executará o script. Quando o script for concluído, a tarefa também será concluída.” (pag 162)

“Uma Business Rule Task (tarefa de regra de negócio) propicia um mecanismo para o processo para enviar informações a um Business Rules Engine (motor de regras de negócio) e obter o resultado do cálculo que o motor de regras pode prover. ” (pag 161)

 

Todas as três são utilizadas na modelagem quando temos um processo que está sendo automatizado (se o processo é executado manualmente, fora de um BPMS ou workflow, é necessário que haja uma atividade manual em que uma pessoa acione a execução de uma funcionalidade; portanto a tarefa em si é de uma pessoa).

 A diferença entre elas é que a tarefa de serviço (service task) aciona a operação de um sistema de informação externo com o qual o motor de processo se comunica (process engine) – que pode ser implementado através de tecnologias como webservices, RMI (Remote Method Invocation), EJB (Enterprise Java Beans), etc. Já a tarefa de script (script task) executa um trecho de código que a própria aplicação de motor de processos interpreta e executa (e cada fornecedor de produto pode definir sua linguagem de script própria). Por exemplo, a transformação de um tipo de dado em outro ou a realização de cálculos com os dados da instância do processo, são exemplos de tarefas de script.

A tarefa de regra de negócio (business rule task) comporta-se da mesma forma que a tarefa de serviço, porém possui o propósito específico de obter resultado da aplicação de uma determinada regra de negócio no processo (leia mais sobre regras de negócio e Business Rules Management no artigo Business Rules e a Dinâmica do Negócio).

Um exemplo de processo com tarefas automáticas de serviço, de tarefa e regra de negócio

No processo hipotético acima temos exemplos aplicados dos três tipos de tarefas automáticas.

  • A tarefa “Identificar prioridade do atendimento” é uma tarefa de regra de negócio, pois executa uma regra da organização (por exemplo: chamados de clientes com contas premium ou chamados que já tiveram uma visita técnica mas o problema não foi solucionado são tratadas como prioridade “emergência”, enquanto as demais são prioridade “normal”. Se a organização quiser mudar esta regra e incluir outros planos no atendimento de prioridade emergencial, pode modificar a regra de negócio sem impactar no processo).
  • Neste processo em que todos os chamados são originados com prioridade “normal”, a tarefa “Elevar prioridade do atendimento” é uma tarefa de script pois muda de “normal” para “emergência” uma informação do próprio processo, elevando a prioridade dos processos que passam por ela (sem precisar acessar outros sistemas).
  • A tarefa “Identificar técnico responsável” é uma tarefa de serviço pois acessa o sistema de localização da empresa identificando que técnico está mais próximo do endereço do cliente. Ela aciona um serviço deste sistema, e recebe como retorno a informação do técnico disponível.
  • A tarefa de serviço a seguir “Sinalizar sistema de chamados”, aciona um serviço do sistema usado pela empresa para enviar ao comunicador do técnico a nova chamada prioritária.
  • A tarefa de serviço “Agendar visita técnica” registra o chamado no sistema que libera a lista de clientes a serem visitados no dia pelos técnicos. Como é uma visita normal, ela é registrada de acordo com o agendamento realizado com o cliente na criação da ficha de atendimento.

Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Desmistificando tipos de tarefas em BPMN: Tarefa Abstrata, Tarefa de Usuário e Tarefa Manual

Em sua riqueza de elementos para a representação de processos de negócio, a notação BPMN traz uma classificação de tipos de tarefas.

Elas ajudam a identificar a forma como a tarefa deve ser executada:

Estes elementos e seus comportamentos esperados estão descritos na especificação BPMN (disponível em http://www.omg.org/spec/BPMN/Current). Apesar disto, a identificação de quando usar cada tipo de tarefa ainda é alvo de alguma ambiguidade.

Em uma série de três artigos, trataremos estes tipos de tarefas com mais detalhes para esclarecer as dúvidas comuns. Para facilitar o entendimento, trataremos os tipos de tarefa de acordo com seu propósito (essa divisão não é oficial):

Tarefa abstrata

A tarefa abstrata (abstract task) é a tarefa sem tipo específico.

Tarefa abstrata (abstract task)

Sobre ela, a especificação diz:

“Uma tarefa sem nenhum tipo de especificação é chamada tarefa abstrata (Abstract Task) (ela era referenciada como None Task em BPMN 1.2).” (pag. 154)

Ou seja, a tarefa abstrata (abstract task) pode ser utilizada em modelagens cujo tipo de tarefa ainda não está definido ou em casos onde a tipificação da tarefa simplesmente não se faz necessária. É o caso dos processos executados manualmente.

Um processo de negócio modelado com tarefas abstratas.

Tarefas de interação humana

Para representar tarefas cuja execução envolve a atuação de pessoas em um processo, BPMN sugere dois tipos de tarefa: a user task (tarefa de usuário) e a manual task (tarefa manual).

Tarefa manual (manual task) e Tarefa de usuário (user task)

O que a especificação diz sobre estes tipos de tarefa:

“Uma Tarefa de Usuário (User Task) é uma tarefa típica de “workflow” onde um ator humano desempenha a tarefa com a assistência de uma aplicação de software e é disponibilizada através de uma lista de de trabalho ou outra forma de gerenciamento semelhante. ” (pág 160)

“Uma Tarefa Manual (Manual Task) é uma tarefa que é esperada que seja executada sem o suporte de nenhuma aplicação de execução de processos de negócio ou outra aplicação. Um exemplo disso pode ser um técnico de telefonia instalando um telefone no endereço de um cliente.” (pág 161)

“10.3.4.1 Tarefas com o envolvimento humano
Em muitos fluxos de trabalho, o envolvimento humano é necessário para executar certas tarefas especificadas no modelo de fluxo de trabalho. BPMN especifica dois tipos de tarefas com o envolvimento humano, a Tarefa Manual (Manual Task) e a Tarefa de Usuário (User Task).
A tarefa de usuário é executada e gerenciada por um motor de execução de processos de negócio. Atributos relativos ao envolvimento humano, como as pessoas envolvidas e a renderização de interfaces de usuário (UI) podem ser especificados em grande detalhe.(…)
Uma tarefa manual é uma tarefa que não é gerenciada por qualquer mecanismo de processo de negócio. Ela pode ser considerada como uma tarefa não gerenciada, não gerenciada no sentido de que o motor de processos de negócio não acompanha o início e o fim de tal tarefa.
Um exemplo disso poderia ser uma instrução de papel como base para um técnico de telefonia instalar um telefone em um local do cliente.” (pág 165)

 

Ou seja, uma user task (tarefa de usuário) é a tarefa que é executada através de uma aplicação e gerenciada por uma lista de trabalho(1). Em outras palavras, é a tarefa realizada através de uma aplicação, como um BPMS (Business Process Management Suite), uma aplicação de workflow, uma ferramenta de gestão de cronograma ou qualquer outro sistema que apoie o controle do processo.

Já as tarefas manuais (manual task) são aquelas executadas no mundo físico, sem o controle por parte de uma aplicação.

Aqui há uma confusão comum na interpretação do “uso de uma aplicação”, inclusive replicada em literatura. Para entender claramente a diferença entre elas, é preciso compreender que o que define se uma tarefa é user ou manual task não é se usamos alguma ferramenta para executá-la, e sim se há um sistema controlando a sua execução.

Isto quer dizer que, se temos por exemplo um processo de venda de produtos que é todo executado manualmente, mas em uma determinada atividade uma planilha eletrônica é usada para calcular o valor a ser cobrado do cliente, e um e-mail é enviado ao cliente com o orçamento do produto, ainda assim (apesar de usar uma aplicação de planilha e o software de e-mail para o trabalho) esta será uma tarefa manual, pois não há controle nem gestão sobre quem faz, quando iniciou e quando concluiu a tarefa.

Mesmo utilizando ferramentas como planilha eletrônica e email, ainda assim a tarefa "Apresentar orçamento" neste processo é manual.

Numa modelagem de processo que não será automatizado, e que portanto são pessoas que lerão e interpretarão o modelo, não faz muito sentido essa diferenciação, já que as pessoas, ao lerem a documentação do processo, têm condições de interpretar o modelo mesmo que os tipos de tarefas não estejam esclarecidos.

Na modelagem para automatização, entretanto, isso é muito importante. A tarefa de usuário é aquela em que o processo deve aguardar que um usuário informe o resultado do trabalho, registrando que a mesma foi concluída para então dar seguimento ao fluxo do processo. Já sobre a tarefa manual o sistema não tem nenhum controle, então mesmo que ela seja incluída no modelo, ele “passará batido” por ela.

Por exemplo:
Considere novamente o processo de atendimento de chamado, no qual há uma atividade para um técnico de telefonia para realizar uma visita técnica ao cliente, e que este processo terá sua execução controlada por uma aplicação (por exemplo um BPMS).

Neste processo, podemos ter dois cenários:

Cenário 1: O Técnico acessa uma lista de tarefas, com todos os chamados a realizar, identifica o chamado que está executando e finaliza a tarefa. Com isso, o sistema identifica que a mesma foi concluída e segue o fluxo disponibilizando a próxima tarefa ao respectivo ator responsável. Neste caso, a tarefa está sendo controlada pelo sistema (seu início e fechamento), portanto é modelada como uma tarefa de usuário.

Cenário 2: O Técnico não acessa o sistema. Ele pode, por exemplo, receber ao início do dia uma lista impressa com todos os clientes a visitar. A cada visita, o cliente assina o papel confirmando que o atendimento foi realizado. Ao fim do dia, quando o técnico retorna para a empresa, ele entrega a lista ao Atendente, que então verifica se o atendimento foi realizado e registra no sistema o resultado do atendimento. Neste caso, a tarefa do técnico é modelada como uma tarefa manual, para que fique visível aos que olham o modelo em que momento o mesmo realiza seu trabalho (e que, do ponto de vista do processo de negócio, existe uma dependência da tarefa de "Verificar resultado do serviço" em relação à "Realizar visita técnica", mas o sistema não controla o início nem o fim do trabalho realizado.

Assim, concluímos que, na modelagem com a notação BPMN, o tipo de tarefa não é definido pelo uso de sistemas para realizá-la, e sim se há alguma aplicação sendo utilizada para controlá-la.

_______

(1) Processos podem ser controlados por aplicações de diferentes tipos. Isto já foi tema deste blog no artigo Gerenciando a execução de processos com (ou sem) um BPMS.

 


Aprenda a dominar a notação BPMN utilizando as melhores práticas com nossos instrutores, em um curso repleto de exercícios e um laboratório prático de modelagem de um processo de negócio de ponta a ponta!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br/ipe04

Modelagem de Processos de Negócio: Diferenças entre diagrama, mapa e modelo de processos

Quantas vezes você já se referiu ou ouviu pessoas se referirem a um mesmo desenho de processo como sendo um diagrama de processo ou mapa de processo ou ainda, como um modelo de processo?

Este é um assunto controverso, principalmente para pessoas que estão começando em projetos que envolvem iniciativas de processos de negócio ou iniciando o estudo de BPM.

Dúvida comum que é esclarecida em nosso curso de Modelagem de Processos de Negócio (iPE01). Constatamos que os termos diagrama, mapa e modelo de processos são utilizados, por muitas vezes, de forma errônea, como sinônimos, porém eles na verdade tem diferentes propósitos e aplicações.

Falaremos neste artigo sobre os três níveis de modelagem (diagrama, mapa e modelo), as diferenças em seus desenhos, no nível de detalhamento e utilidade de cada um.

Diagrama, mapa e modelo são três níveis de “representação” de processos.

Estes três níveis de representação de processos diferem-se em níveis de abstração, informação, utilidade, precisão, complexidade, padronização de elementos do fluxo, evolução e amadurecimento do desenho proposto.

diagrama, mapa e modelo de processos

Fazendo uma analogia com mapa geográfico, podemos dizer que o diagrama de processo demonstra a rota que é realizada em uma visão simplificada, com o trajeto percorrido, evidenciando os principais pontos de referência, o local de origem e destino. O mapa do processo apresenta a rota de forma mais detalhada, com elementos como nome de avenidas, ruas, principais pontos de referências, opções de rotas alternativas, trajeto e tempo estimado para cada rota. O modelo de processo apresenta a rota de forma mais completa e precisa, descrevendo a situação atual do trânsito, rota de transporte público, clima na região da rota, além de fotos das avenidas e ruas.

O Diagrama é uma representação inicial do processo. Ele demonstra o fluxo básico focando as principais atividades. Não trata exceções ou falhas no processo.

Utilizado para capturas rápidas no processo, por isto não é muito preciso.
Ajuda a obter entendimento rápido das principais atividades, representando ideias simples em um contexto alto nível.

Esta representação inicial do processo pode significar várias coisas. O diagrama pode representar um macroprocesso organizacional, por exemplo, como também se tratar de apenas um esboço (versão inicial do processo) de uma primeira avaliação.

diagrama de processo

Em um primeiro momento busca-se conhecer os processos identificando as atividades chave. Esta é uma das técnicas mais utilizadas para conhecer os processos organizacionais, conhecida como abordagem top-down, em uma visão de macroprocessos (visão interfuncional) até chegar aos processos operacionais.

Em uma primeira versão, o processo muitas vezes não recebe as informações necessárias para partir diretamente para um nível de mapa ou modelo. Fatores como a precisão e nível de detalhamento influenciam a forma como o processo é modelado. A precisão varia de acordo com a profundidade em que se avalia cada aspecto do processo e suas atividades, e aumenta de acordo com o número de pessoas entrevistadas das áreas que fazem parte dos processos.

O nível de detalhe define o quanto cada processo, sub-processo, atividades, tarefas, procedimentos, atributo ou aspecto é descrito.

O mapa é uma evolução do diagrama, acrescentado de atores, eventos, regras, resultados e um detalhamento do processo. Ampliada para uma visão mais detalhada, o mapa fornece informações de maior precisão do desenho do processo.

Neste nível as atividades do processo e seus objetivos estão mais claros. Foram identificadas as responsabilidades atribuídas ao longo do processo. Isto se deve aos métodos de levantamento de informações utilizadas pela equipe envolvida na iniciativa de BPM.

Através de pesquisas a equipe obteve um entendimento inicial, e segue para as entrevistas com os envolvidos no processo (donos de processos, clientes, fornecedores, pessoas que trabalham no processo, etc). Esta etapa é de grande importância para identificação das regras, validações, caminhos de exceções, papéis e detalhamento de atividades.

Existem diversos métodos para levantamento de informações, como workshops, conferências, observações diretas, etc. Abordaremos este assunto em um próximo post.

A escolha do nível de representação de processos dependerá do propósito da modelagem, em muitos casos, o diagrama ou mapa já são suficientes para representar o processo.

O modelo é a versão final da evolução do processo. Esta representação traz um alto grau de precisão e detalhamento do processo.

Uma grande vantagem é a capacidade de execução do processo através de simulações. Estas simulações geram informações que acercam o desempenho do processo, úteis para analisar/validar a execução do processo.

Este nível de execução requer uma descrição detalhada dos atributos do processo, descrevendo propriedades e características das entradas/saídas, procedimentos/passos, recursos, custos, alocação, simulação, parâmetros de duração, etc. Estes atributos podem ser classificados em categorias e sua documentação varia de acordo com o objetivo da modelagem realizada.

A partir do modelo é possível executar as próximas etapas do ciclo de gestão por processos, como a análise, redesenho, reengenharia, melhoria continua e medição do processo.

Você se interessou pelo assunto?

A área de conhecimento de modelagem de processos fornece o entendimento dos propósitos, benefícios, habilidades e técnicas e é muito utilizada pelas organizações para conhecer, documentar e melhorar processos.
Este tema é explorado com mais profundidade em nosso curso de Modelagem de Processos de Negócio, onde abordamos de forma mais abrangente o tema. http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

 

A diferença entre “desenhar” e “modelar” processos

Não basta saber usar um editor de textos para ser um bom escritor.
O mesmo se dá na relação entre uma ferramenta de modelagem e o designer de processos(1).

Pode parecer estranho começar um artigo com uma afirmativa como essa. Mas o fato é que muitas vezes já nos encontramos em conversas com pessoas envolvidas em iniciativas de processos com a expectativa que, se treinassem pessoas da empresa para usar alguma ferramenta para desenhar de processos (como o Bizagi, por exemplo), isso bastaria para que essas pessoas pudessem documentar os processos das suas áreas (e assim teriam modelados os processos da organização).

Mas criar um bom modelo de processo é como escrever um bom texto. Não basta apenas dominar o editor de textos e saber escrever as palavras, é preciso preocupar-se com a clareza do conteúdo – em como ele será interpretado por quem o lerá.

Designer de processos em ação.

O primeiro passo para uma boa escrita é conhecer e aplicar bem as regras gramaticais da linguagem usada. Uma vírgula fora do lugar pode mudar completamente o sentido de uma frase. Da mesma forma, um elemento BPMN aplicado sem a preocupação com as regras da sua especificação também pode levar a interpretações distintas dos leitores em relação à expectativa de quem fez a modelagem.

As definições da especificação BPMN funcionam como as regras gramaticais de um idioma. Se forem bem conhecidas por quem as usa podem ser relativamente fáceis de aplicar, já que são bastante claras. Elas definem como são os símbolos, como podem se conectar e o que significam.

Conhecer as regras de uso de um idioma ou de uma notação são apenas o primeiro passo para comunicar-se bem com quem lerá o produto do trabalho. As dúvidas mais frequentes geralmente estão relacionadas a como aplicá-las ao conteúdo que queremos transmitir.

Em uma história bem contada, a sequência de fatos, determinada pelo enredo, é fundamental para o seu entendimento. Em algumas situações, fatos podem ser contados em paralelo, em outros casos eles têm uma sequência que se for quebrada pode dificultar a compreensão ou mesmo gerar interpretações equivocadas.

Na modelagem de processos, a lógica do processo é o enredo. Ela se define tendo um evento que sinaliza o início da estrutura de precedência entre as atividades e regras de roteamento do fluxo, que podem apresentar cenários com sequências de atividades paralelas ou alternativas, até atingir o seu fim. É ela que determina como os elementos da notação devem ser usados para criar o diagrama do fluxo do processo. Toda a modelagem deve ter em vista garantir a integridade da lógica do processo.

Assim como a boa escrita, isto é fruto de uma habilidade desenvolvida com a prática. Esta habilidade se constrói:

  • desenhando processos,
  • tendo a sensibilidade de lê-lo sob a perspectiva do leitor,
  • validando – não apenas gramaticalmente mas também a lógica representada junto com as outras pessoas envolvidas
  • e discutindo a modelagem proposta com outros analistas, avaliando até mesmo outras alternativas de transmitir mais claramente a ideia do processo.

Esse trabalho envolve alguns cuidados que o designer de processos deve observar em suas modelagens se quiser apresentar resultados claros, objetivos e precisos na representação de processos:

  • Criar modelos limpos. Diagramas de processos devem primar pela interpretação fácil com olhar simples. Isto se obtém evitando-se desenhar linhas sobre linhas, cruzar linhas sobre as outras ou traçar conexões entre elementos muito distantes. Isso pode ser resolvido com o uso de elementos de links (mas use com parcimônia!) e alguma reorganização (avalie se as lanes onde os elementos que devem se conectar não podem ser aproximadas). Usar nomes breves e objetivos para eventos, gateways e atividades também ajudam a manter o diagrama limpo.
  • Aplicar boas práticas. Existem diversas práticas, que foram sendo agregadas por profissionais com experiência na modelagem de processos e que são recomendadas no uso da notação. Confiar nessas práticas pode facilitar o trabalho e ajudar na elaboração de diagramas eficazes na comunicação.
  • Usar a notação de forma padronizada. Padronizar a forma como usa a notação dá harmonia ao conteúdo representado, gerando conforto a quem lê e confiança de que o processo está bem modelado.
  • Modelar no grau de detalhamento apropriado. De acordo com o propósito da modelagem do processo, o diagrama requer uma representação em maior ou menor nível de detalhe. Algumas situações requerem um processo desenhado numa perspectiva superficial, suficiente para dar entendimento ao negócio, enquanto outras requerem detalhamento no nível de atividade da operação, ou mais além, em que todas as exceções do processo sejam previstas e tratadas. Compreender o grau de detalhamento esperado – e mantê-lo no decorrer de todo o fluxo modelado -, é um cuidado fundamental.

Encontre uma pessoa com habilidades de compreensão gramatical e boa escrita e você terá nela um excelente profissional para modelar seus processos. Desenvolva estas habilidades e você será esta pessoa.

_____
(1) De acordo com BPM CBOK v3 em português, “Designer de Processos” é o papel realizado por um membro da equipe de modelagem de processos cujo trabalho é desenhar novos processos e transformar processos de negócio. Tipicamente possui habilidades analíticas, criativas e de descrição visual e lógica dos passos de processos e na forma de organização do trabalho. Não é uma função, mas um papel, que pode ser realizado por um profissional específico ou mesmo pelo analista de processos ou de negócios.

Projetos de Modelagem de Processos – Parte 1: Objetivos e Motivadores

A modelagem de processos está sendo muito utilizada pelas organizações para conhecer, documentar e melhorar os seus processos. Porém, as necessidades que levam uma organização a iniciar a modelagem de processos acabam direcionando a tipos de projetos de modelagem com focos diferentes.
Trataremos, neste primeiro artigo da série, dos principais objetivos e motivadores relacionados aos mais comuns tipos de projetos de modelagem de processos.

 

Modelagem para Conhecer o Processo:

Objetivo
  • modelar o processo de modo que a forma como ele é realizado passe a ser de conhecimento dos participantes que executam o processo e da organização como um todo
Motivadores
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Documentação ou Treinamento:

Objetivos
  • documentar o processo para que dúvidas operacionais possam ser diluídas através da consulta ao processo
  • fornecer uma documentação completa para que os seus executores saibam como realizar suas atividades, evitando erros ou demoras devido a dúvidas
  • fornecer uma documentação que facilite o treinamento de novos colaboradores:
    • minimizando o efeito de perdas de colaboradores
    • auxiliando a organização que passe por um processo de expansão
Motivadores
  • processos em que os executores não tem experiência em executá-lo porque:
    • os papéis tem alta rotatividade ou
    • o processo não é executado com frequência por determinados papéis
  • formalizar e institucionalizar o modelo do processo
  • processo em que ninguém da instituição conhece de ponta a ponta
  • entender o funcionamento do processo para identificar a causa de problemas e falhas
Modelagem para Implantação de Auditoria:

Objetivo
  • descrever os processos que serão objetos de auditoria para que exista uma referência comum sobre o que deve ou não ser feito no processo
Motivadores
  • padronização e documentação de processos que precisam ser auditados devido a exigências internas ou externas da organização
Mapeamento de Processos de Toda a Organização:

Objetivo
  • criar um repositório de processo com todos os processos da organização modelados e documentados
Motivadores
  • criar um ponto de partida para as iniciativas de gestão por processos
  • permitir que novas demandas de melhoria de processos possam ser atendidas rapidamente
Modelagem para Padronização dos Processos:

Objetivo
  • garantir que toda a organização executa o mesmo processo
Motivadores
  • demandada por processos executados em mais de um local. Ex.: Processo utilizado em várias unidades geográficas como no varejo ou no sistema financeiro.
  • processos que possuem diferente desempenhos de acordo com o local onde são executados ou das pessoas que os executam
  • aquisição de outras empresas → Necessidade de unificar a operação
  • abertura de novas unidades → Necessidade de replicar o modelo de gestão
Modelagem para o Redesenho de Processos:

Objetivos
  • a modelagem é focada no entendimento da situação atual do processo (AS IS)
  • objetivo não é a documentação do processo e sim o entendimento de
    • quais são suas atividades
    • quais os seus pontos fracos
    • quais os seus pontos fortes
    • quais suas oportunidades de melhoria
  • criar base para executar todo o ciclo BPM de melhorias: Mapeamento, Redesenho, Automação, Implantação e Melhoria Contínua.
Motivadores
  • redução de custos ou perdas do processo
  • processos críticos que, se não forem bem executados, podem gerar um grande impacto na organização
  • processos com metas cronológicas bem delimitadas
  • processos que possuem muitas perguntas a serem respondidas. Ex: Como é feito o processo? Porque acontecem tantos erros? Porque o processo é tão lento? Como posso melhorá-lo? Como meço os indicadores deste Processo?
  • processos com SLA bem definidos
  • melhorar o atendimento ao cliente final
  • expansão organizacional
  • processos inter-organizacionais (B2B)
  • empresa precisa se certificar ou aderir a uma legislação
Modelagem para Automação de Processos:

Objetivo
  • conhecer o processo o suficiente para propor uma versão automatizada que busque aumentar a sua eficiência operacional
Motivadores
  • ocorre quando a organização está satisfeita com o seu processo, mas acredita que ele poderia ser melhorado com o uso da tecnologia
  • organização entende que não precisa necessariamente discutir o processo a nível de negócio, e sim entregar com mais eficiência o processo da forma como atua hoje

Leia também o artigo Parte 2 – Características e Desafios, que trata da profundidade da modelagem, características, desafios e riscos relacionados a cada tipo de projeto de modelagem.

BPMN: Uma atividade para mais de um participante do processo

Há uma questão recorrente na modelagem de processos relacionada à distribuição de atividades nas lanes de processo: como representar um trabalho sendo realizado por mais de uma pessoa?

Por exemplo:
Digamos que em um processo há uma reunião realizada entre o Diretor de Planejamento e o Diretor Financeiro, que recebem uma proposta de um analista e realizam uma reunião para avaliar sobre o investimento. A seguir, eles atuam na priorização das ações relacionadas ao investimento, e a partir desta priorização são realizadas outras ações.

Para essa situação em que há dois participantes envolvidos na realização de uma mesma tarefa, já vimos diagramas que tentam representar isso de algumas formas peculiares:

"Tentei demonstrar que as atividades são realizadas pelos dois usuários posicionando-as sobre o limite entre as duas lanes."

A abordagem acima é inadequada sob o ponto de vista de uso da notação BPMN e poderá gerar interpretações diferentes. Para a notação, uma atividade só pode estar associada a uma raia (lane), e mesmo que a ferramenta de criação do diagrama não aponte o problema na validação do processo, o fato é que internamente as atividades estão vinculadas a apenas uma lane. Isto está estabelecido na própria especificação da notação. Se a ferramenta utilizada dispõe de geração de relatório que lista quais tarefas estão relacionadas a quais lanes, essas tarefas só estarão associadas a um único participante.
Tem um outro problema ao se praticar o mapeamento desta forma: e se os investimentos tivessem que envolver também o Diretor de Tecnologia – como colocar as tarefas compartilhando pessoas de três raias?

Outra tentativa comum é a refletida no exemplo abaixo:

"Coloquei as tarefas em paralelo porque eles fazem a reunião ao mesmo tempo."

No diagrama acima, as regras de validação lógica do uso da notação também não apontariam problema, mas o processo ainda não estaria corretamente representado.

A interpretação que se deve ter no uso do gateway paralelo não é de que as atividades paralelizadas serão realizadas ao mesmo tempo, e sim que elas podem ser feitas em paralelo porque não há restrição de dependência entre elas. Assim, apesar de serem iguais no exemplo acima, cada tarefa tem sua execução própria, levando ao entendimento que cada um fará as atividades quando tiver disponibilidade. Por exemplo: digamos que o Diretor de Investimentos faça “Avaliar investimento” pela manhã e já siga para a próxima tarefa, enquanto o Diretor Financeiro só consiga iniciar a tarefa “Avaliar investimento” à tarde. O processo mapeado acima permite essa interpretação.

Se a ideia é de que os dois realizem juntos a tarefa “Avaliar investimento” e “Priorizar etapas do investimento”, recomendamos uma forma de mapear isto um pouco diferente:

Uma raia com um papel em grupo que abstrai os participantes e garante que as tarefas sejam realizadas em conjunto pelos envolvidos.

Nesta abordagem, criamos uma raia para um papel que abstrai um grupo (o  ”Comitê de Avaliação de Investimentos”), e atribuímos as atividades a ela. Na descrição da raia, ficam estabelecidas as regras usadas para definir quem são os participantes do comitê – que neste caso será formado pelos Diretores de Investimentos e Financeiro. Esta abordagem ainda possibilita que outros diretores possam se juntar ao comitê sem impactar no diagrama do processo, bastando apenas ajustar a descrição dos participantes do grupo.

Definindo o Escopo de Modelagem de um Processo de negócio

Uma definição essencial no início de um projeto de modelagem é o escopo do processo que será modelado. A definição clara dos limites em que será trabalhado o processo é um fator chave para a realização de qualquer projeto de modelagem.

Tomando como exemplo um processo de venda de uma fábrica de móveis: num primeiro momento, poderíamos imaginar que o escopo de um processo desta natureza  inicia com a chegada do cliente na loja e termina com o pagamento:

Contudo, extrapolando um pouco as atividades que se seguem ao pagamento, poderíamos questionar se não deveriam também estar contempladas as etapas de:

  • Entrega dos móveis;
  • Montagem, quando necessário;
  • Acompanhamento dos pagamentos parcelados; ou
  • Acompanhamento da garantia.

Onde efetivamente deveria começar e finalizar este processo?
Não existe uma resposta certa para esta pergunta, pois o escopo de um projeto de modelagem depende de diversos fatores, estando entre eles:

1. Os Resultados esperados do projeto: A motivação inicial pela realização do projeto é um fator primordial na definição do seu escopo. No exemplo acima, a modelagem pode ter sido demandada pela equipe comercial que tem como meta abrir mais 50 lojas nos próximos 12 meses e que precisa, portanto, unificar o processo de atendimento. Ou por uma necessidade desta mesma equipe em unificar o atendimento das suas lojas, tendo em vista que algumas unidades possuem um desempenho espetacular e em outras deixam muito a desejar. Nestes casos, a primeira versão do processo atende as expectativas.
Porém, digamos que a motivação seja garantir a melhor experiência de atendimento ao cliente. Neste caso, a empresa pode estar preocupada com o fato que o atendimento fora da loja, nas etapas de transporte e montagem, são os momentos em que ela menos tem condições de garantir a sua qualidade, criando assim uma necessidade de maior gestão e controle.

2. A Equipe envolvida no projeto: A modelagem de processos é uma atividade de natureza interfuncional que necessita para o seu sucesso da cooperação de todas as áreas envolvidas no processo. Desta forma, a amplitude do escopo da modelagem deve ser norteada também pelas áreas que estão engajadas no projeto de modelagem. A ampliação do escopo exigirá a sensibilização das novas áreas de negócio que serão afetadas.

3. As Expectativas de Prazo e Custos do Projeto: As variáveis clássicas de custo, prazo e escopo estão interligadas desde a concepção do projeto, e a mudança em uma delas tende a gerar reflexos nas demais. Desta forma, a reflexão sobre o escopo do processo deve levar em conta as expectativas de prazos e custos previstos para o projeto, de modo a garantir que a alteração não impactará a sua viabilidade.

Respeitando estes quesitos, podemos avaliar se determinadas partes do processo, devido às suas características, não poderiam ser modeladas separadamente. São exemplos destas situações as etapas de um processo que:

  • Aparentam ser mais independentes em relação a outras. Etapas com estas características costumam tem um bom nível de desacoplamento do restante. Por exemplo, uma etapa final de pesquisa de satisfação do cliente tende a ser a menos acoplada ao processo do que a etapa de pagamento, e poderia ser analisada separadamente.
  • Se repetem em outros processos. Por exemplo, o serviço de transportes pode ser necessário tanto num processo de venda como num processo de manutenção ou devolução do móvel adquirido.
  • São claramente de apoio, sem visibilidade para o cliente final.
  • Não podem retroagir a um ponto anterior do mesmo processo. Por exemplo, no nosso processo de vendas, não é razoável pensarmos que no momento em que o cliente está recebendo o montador do seu móvel ele possa voltar para a etapa de cadastro realizada antes da compra. Isso demonstra que a etapa de montagem e a etapa de cadastro possuem uma certa independência que permite que elas sejam analisadas separadamente.

Neste momento, algumas perguntas chaves muito comuns no início de um projeto de modelagem também podem ser fundamentais para definirmos o escopo mínimo e máximo de um processo, tais como:

  • Quem é o cliente do processo? Ele será atendido com o escopo que está sendo proposto?
  • Quem são os seus fornecedores? No escopo proposto eles interagirão com o processo?
  • Quais são as entradas e saídas do processo? As entradas previstas serão utilizadas no escopo proposto? Este escopo entregará as saídas esperadas?
  • Quais são os indicadores principais? No escopo proposto estes indicadores poderão ser medidos?

Finalmente, é importante que o escopo previsto para o projeto contemple alguns cuidados de modo a evitar que o mesmo não se limite a um escopo tão pequeno que não seja contributivo ou tão grande que se torne inviável. Desta forma, sugerimos sempre uma dose de atenção para que:

  • O processo não se limite a uma só área ou departamento, ou seja, preserve suas características interfuncionais. Processos departamentais tendem a não apresentar todos os benefícios da gestão por processos como aqueles transversais à organização.
  • Se evitem projetos que exigem 6, 10 ou 12 meses de trabalho. Projetos desta amplitude tende a já ter o seu resultado desatualizado ao seu final, além de gerar desmotivação devido a demora na entrega dos seus resultados.
  • No caso do processo ser muito extenso, seja verificada a possibilidade de que o seu escopo seja dividido em dois ou mais projetos, de modo a garantir entregas frequentes.
  • Se lembre que, quanto maior o escopo, mais complexa a sua gestão.
  • Se esteja, contudo, sempre atento para evitar que uma divisão excessiva que sacrifique a visão ponta a ponta do processo.

Finalizando, não podemos deixar de ressaltar que, tão importante quanto à definição do escopo é que estes limites fiquem sempre muito claros para os stakeholders e para as áreas de negócio. A falta de clareza sobre o escopo a ser trabalhado tende a gerar desmotivação e retrabalho nas reuniões de levantamento do processo.

Se você quiser saber um pouco mais sobre este assunto, conheça o nosso curso de modelagem de processo, http://www.iprocesseducation.com.br/ipe01.html, oferecido pela iProcess Education.

Respondendo dúvidas em BPMN: Desenhar processo na vertical ou horizontal?

A definição sobre a orientação vertical ou horizontal para diagramas na notação BPMN, sempre foi, desde sua criação, um dos aspectos mais questionados pelos analistas e modeladores de processos.

Um de nossos leitores recentemente enviou a seguinte questão:

“Sei que a boa prática é desenhar o processo da esquerda para a direita, correto?
Porém estou me deparando com alguns processos longos que vão dar muito trabalho fazer nesta ordem e acredito que ficará mais fácil visualizar de cima para baixo.
O que vocês acham sobre isso? Há alguma regra? O que vocês orientam?”

Embora não seja obrigatório em BPMN, swimlanes (pools e lanes) são muito utilizadas pois possibilitam a estruturação visual do fluxo, de forma a apoiar a interpretação do mesmo. Através delas, é possível identificar facilmente quem é responsável por executar cada tarefa, quem são os atores do processo e que participantes externos colaboram com o processo.

Em nosso blog, já falamos sobre pools e lanes em postagens como:

A especificação da notação (http://www.omg.org/spec/BPMN/2.0/PDF/) define o uso de swimlanes como não obrigatório, e que estes elementos podem ser usados para organizar o processo visualmente tanto na horizontal quanto na vertical.

Muitas vezes, o analista que realiza a modelagem de processo já utilizou alguma outra notação ou metodologia com elementos semelhantes às pools e lanes de BPMN, como eEPC e fluxogramas. Nestas duas notações, o processo é comumente representado na vertical. Assim, é mais natural para estes profissionais elaborar o processo nesta visão.

Entretanto, a maior parte dos exemplos que encontramos na bibliografia e na web sobre BPMN utiliza a representação na horizontal. Isto se dá porque na cultura ocidental temos o reflexo da leitura da esquerda para a direita. É uma percepção ligada à compreensão da sequência de ações. Assim, a distribuição do processo em uma estrutura de pool e lanes horizontal permite uma melhor distribuição das tarefas nesta visão

Um exemplo bastante simples de processo modelado com swimlanes na horizontal. À medida que se agreguem novas atividades ao processo, há a uma tendência de aumento do diagrama para a esquerda. Em um diagrama com colaboração, outras pools podem ser adicionadas, geralmente abaixo e acima da pool que contém o processo.

O mesmo processo do exemplo acima, representado com swimlanes verticais. A leitura do fluxo navega para a esquerda mas em alguns momentos precisa ir na "contra-mão" da leitura normal. A tendência de aumento é para baixo, mas novas lanes podem ser agregadas aumentando sua largura. Em um diagrama com colaboração, outras pools podem ser agregadas, geralmente nas laterais da pool que contém o processo.

Existe ainda uma abordagem de fluxo limpo do processo, em que pools e lanes não são utilizadas. Essa abordagem é mais usual quando o processo é modelado com visão de orquestração, por exemplo, em que suas atividades são na verdade uma sequência de processos, ou sub-processos. Neste nível de visão sobre o processo de negócio, é mais relevante identificar os processos e como estão relacionados do que quem são os envolvidos nestas tarefas, já que os atores já estarão claros nos diagramas dos respectivos processos.

Apesar da flexibilidade oferecida pela especificação oficial da notação, em geral recomenda-se a documentação do processo com pool e lanes na horizontal, seja pelo aspecto do conforto natural da leitura do fluxo ou mesmo por restrições de ferramentas (alguns produtos amplamente utilizados no mercado para representar diagramas de processos não permitem desenhar pools e lanes verticais, apenas horizontais).

Se o diagrama do processo tende a se tornar grande, a resposta não está na definição vertical ou horizontal do diagrama, mas na capacidade de abstrair tarefas em conjuntos através de subprocessos. Com isso, o modelo talvez acabará ganhando um ou dois níveis a mais, mas ao mesmo tempo temos com isso um diagrama com visão mais objetiva sobre o processo de negócio (veja mais sobre esta abordagem neste artigo, em orquestração de processos).

Independente da escolha, nossa principal recomendação é que esta definição deve fazer parte do guia de estilos de modelagem da organização, ou seja: vertical ou horizontal – o importante é manter um padrão a ser adotado em todos os diagramas de processos  de negócio documentados para a empresa.

 


Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br