Blog da iProcess - Compartilhando conhecimento em BPM e RPA

Estudo de Caso: Automatizar o processo (ou não)? Eis a questão!

Recentemente um de nossos leitores nos escreveu sobre seu entusiasmo em iniciar uma experiência prática em BPM. Ele compartilhou conosco um desenho de processo (que discutiremos neste artigo, com a permissão do leitor) cujo objetivo era ser automatizado com dois propósitos: servir como base para a monografia e também validar o BPMS como tecnologia para automatizar processos na empresa de varejo no qual atua na área de TI.

O argumento da escolha do Processo de Pré-venda para esta primeira experiência foi: que fosse pequeno (poucas atividades) para viabilizar a automação no curto tempo para a monografia, mas que ao ser desenvolvido seria usado como piloto para provar a tecnologia na empresa e, dando certo, o processo evoluiria para as etapas seguintes da venda. Portanto, havia uma expectativa de que a automatização dele pudesse demonstrar bons resultados para a organização, a ponto de convencê-los que valeria a pena investir na adoção da solução e a implementação do restante do processo (e eventualmente de expandir a iniciativa para todos os processos da organização).

Embora ter processos executados e controlados por um BPMS (ou um motor de workflow) possa ser parte do ciclo da gestão por processos, não significa que a empresa tenha adotado Business Process Management como filosofia de gestão. Mas, dependendo do contexto organizacional, muitas vezes a iniciativa nasce dentro da TI, em situações como esta.

A questão é: seria este um bom processo para demonstrar resultados iniciais que possam alavancar uma iniciativa maior BPM (e em uma monografia, apresentar resultados satisfatórios)?

É aqui que este artigo realmente começa :-)

A notação BPMN é excelente para representar atividades de um processo de negócio. Mas a especificação não esclarece exatamente o que é o escopo de um processo de negócio, e nem o nível de granularidade, ou mesmo um método de uso. Apenas dispõe os elementos e as regras de uso visando uma padronização no entendimento de um processo mapeado.

Analisamos juntos o processo e percebemos que este diagrama não é um processo de negócio. É apenas uma parte dele, praticamente o fluxo de ações de uma atividade.

Os benefícios típicos da automatização aparecem quando o processo de negócio :
– Envolve mais de uma área da empresa (melhoria da comunicação)
– Permite extrair indicadores que demonstrem o desempenho do processo (melhoria do controle)
– Deve ser controlado para que sua execução siga integralmente o fluxo modelado
-Possibilita  apresentar informações de tempo do processo que possam apoiar as decisões que levarão à sua evolução (quanto tempo o processo leva hoje e quais atividades devem sofrer alguma melhoria para que esse tempo possa ser reduzido).
[Veja mais sobre benefícios típicos da automação de processos no artigo de Paulo Capiotti, Benefícios da Automação de Processos]

Ao analisar o diagrama, desaconselhamos a sua automatização, pois a mesma não obterá nenhum benefício significativo. Justificamos isto apontando alguns argumentos que usamos quando estamos avaliando a viabilidade/ganho ao se automatizar um processo para um cliente:

I. Este processo tem apenas um usuário. No diagrama original há duas lanes, a do vendedor e a do cliente, mas o fato é que o único a interagir diretamente com a interface humana do BPMS, neste caso, será o vendedor. Se ajustarmos o diagrama para representar apenas as atividades que serão automatizadas (conforme abaixo) e colocando o cliente em uma outra pool (já que ele não irá interagir diretamente com o BPMS) isto se torna bastante visível:

II. Todos estes passos acontecem em um curto espaço de tempo. Pelas tarefas mapeadas, percebe-se que elas ocorrem com o cliente ali, na frente do vendedor. Neste caso, ao automatizar cada uma destas tarefas separadamente, poderá gerar um impacto negativo no aspecto da interface, porque para cada “passo” o usuário (vendedor) terá que: procurar a tarefa na lista de trabalho, clicar para abrir, realizar as ações necessárias na tela, finalizar a tarefa (para que o BPMS registre que aquela tarefa foi concluída e verifique qual a nova tarefa, criando um novo item na lista de trabalho), aguardar o refresh da lista de trabalho e então realizar novamente estes passos para cada uma das atividades do fluxo. Em termos de usabilidade, isso se torna desgastante para o usuário porque faz com que ele tenha que dar inúmeros cliques para fazer uma sequência de ações que possivelmente poderia ser condensada em uma única tela. Em outras palavras, esta sequência de ações poderia compor um Caso de Uso (artefato típido da análise de sistemas tradicional).

III. Além disso, se este processo já é executado manualmente, possivelmente há alguma flexibilização na ordem em que estas tarefas ocorrem (por exemplo, em algum caso o vendedor poderia verificar o cadastro do cliente antes de incluir os itens de compra). É importante considerar isso, pois ao automatizar o fluxo no BPMS, ele sempre será executado como foi modelado. Isso implica que nada pode ser feito antes nem depois do previsto – tudo tem que seguir a ordem das tarefas no diagrama. O que é tradicionalmente um benefício da automatização de processos (garantia da integridade da execução), neste caso poderia ser um aspecto negativo, pois não é o engessamento das etapas que queremos (e toda vez que algo precisar ser levemente diferente os usuários dirão que não é possível porque “o sistema não permite”).

Então percebemos que o processo escolhido é, na verdade, apenas uma atividade de um processo de negócio muito maior.

Fica fácil nesta análise perceber que o sucesso de projetos pilotos para a adoção de um sistema de gestão de processos não depende apenas da qualidade do produto, mas também da escolha de um processo com tarefas que possam efetivamente demonstrar bons resultados.

Ao leitor, sugerimos ampliar um pouco mais a abrangência do processo – o que não significa necessariamente que será mais trabalho. Para um piloto como este, recomendamos mapear, em um nivel macro, todo o processo (não apenas esta etapa da pré-venda), e como primeiro esforço de automação identificar pontos de controle que poderiam ser automatizados (seis ou sete tarefas onde o processo muda de status ou há alguma alteração na rota do fluxo).

Alguns desses pontos de controle podem até ser obtidos de sistemas que já existem hoje na empresa, o que demonstraria ainda mais benefícios na automatização do processo. Por exemplo, no sistema que controla os pedidos, fazer com que o processo siga adiante quando a entrega for despachada. Poderia ser agregado ao processo uma tarefa de serviço para buscar essa informação no sistema.

Com um piloto assim, os indicadores podem demonstrar informações muito mais significativas para a organização do que conhecer, por exemplo, quantos minutos está levando a pré-venda. Será possível identificar onde ocorrem os gargalos, que estapas são críticas e estão atrasando o processo, possivelmente até instigar a empresa em investir na análise,  melhoria e medições mais abrangentes, e quiçá em adotar por completo uma filosofia de gestão por processos.

11 respostas

  1. Bom dia, gostei muito da matéria, acredito que as dúvidas foram retiradas.

    Eu já executei um curso na Iprocess há um tempo atrás com ferrmenta BizAagi. Porém hoje estou trabalhando com Aris.
    Por favor, me corrija se estou errado, mas da maneira que a minha organização pede que o mapeamento seja feito, ou seja, de ir detalhando o passo a passo da atividade dentro de cada caixinha do fluxo por FAD prejudica os leitores, já que a atividade fica enorme.
    Vocês da Iprocess acreditam que o BizAgi, poderia não detalhar tais atividades e deixando o leitor/operador menos engessado em suas atividades ??

    1. Olá Gabriel, em nome da equipe da iProcess, obrigada por seu comentário!
      Antes de tudo, gostaria de esclarecer que BizAgi, Aris, Oryx, Visio, Oracle BPM Composer ou qualquer ferramenta de modelagem – independente de qual se escolha, não será a ferramenta que definirá o nível de detalhe utilizado nos diagramas. O fato é que não existe uma metodologia para o uso da notação na representação de processos, e BPMN nos deixa tão livres a ponto de permitir criar diagramas em diferentes níveis de detalhe. Por isso, cada organização deve definir a sua metodologia.

      O importante é estruturar bem as camadas de detalhamento. A organização pode ter níveis de diagramas diferentes – aliás, DEVE ter níveis de diagramas diferentes. A estrutura de processos da organização deve ter um nível mais alto, com mínimo detalhe mas suficiente para visualizar como os grandes processos da empresa estão ligados, e níveis de detalhamento que vão até o nível mais detalhado. O nível detalhado, que define os procedimentos realizados em uma atividade (unidade de trabalho) pode ser documentada de formas diferentes. Algumas empresas adotam uma ficha na qual são descritos os conjuntos de procedimentos que devem ser feitos para que aquela atividade seja concluída. Outras empresas utilizam mais um nível de diagrama BPMN em que cada procedimento é representado por uma tarefa no fluxo.

      É realmente uma questão de organização do conhecimento sobre os processos.
      Um abraço!

  2. Kelly, muito bem colocado este ponto da necessidade de se criar um piloto que “mude” ou “melhore” alguma atividade da empresa. Me fez lembrar do meu primeiro emprego como Analista de Processo, onde tive a oportunidade de mapear e implantar um piloto que controlava a parte de aprovação / prestação de contas de pequenos gastos (aquelas prestações simples de contas por viagem de negócios, refeições, etc.).
    Foi interessante, pois mudou a cara desta tarefa que era feito com relatórios anexados em um e-mail com um monte de “OK” em respostas envolvendo TODAS as pessoas responsáveis.
    Neste caso, resumidamente e bem simples, seria criamos um sistema / telas que a pessoa indicava os gastos e os valores e com isso disparava um Workflow, indo para a “caixa de entrada” dos gestores a solicitação de aprovação. Com isso feito, o processo ficou bem mais limpo e rápido…

    Alguns meses depois com o piloto amplamente utilizado e elogiado pela sua eficácia, surgiu a necessidade de criar os lançamentos contábeis no ERP da empresa… Logo, quando o processo fosse aprovado e finalizado, era disponibilizado um arquivo de carga que o sistema ERP lia e criava o lançamento para integração necessária.

    Acho que este é um bom exemplo de como um Workflow pode facilitar a vida e “crescer” junto da necessidade de negócio da empresa. Como vc falou, se o processo automatizado não trouxer NENHUM benefício, a rejeição por outra ideia (por melhor que ela seja) será bem maior e dificultada…

    1. Oi Matheus, excelente contribuição. A ideia é esta mesmo, o processo piloto precisa oferecer algo e demonstrar benefícios para que a iniciativa de automatizar processos se amplie dentro da organização.
      Muito obrigada!

  3. Qual é o melhor nível de mapeamento e modelagem, na sua ótica, para se praticar a análise para automação? Nível de tarefas? Acredito que o nível “atividades” seja pouco rico em detalhes, do contrário do “tarefas”.

    Muito obrigado!

  4. Parabéns pelo trabalho e dedicação de de vocês da iProcess… Minha organização não trabalha com mapeamento de processos, meu chefe me enviou uma mensagem solicitando pesquisar a respeito para encontrar um bom sofwarte/aplicativo para esse fim. Não sou especialista ou fiz qualquer curso a respeito meu conhecimento se restringe a pesquisas na internet… minha dúvida é se a organização precisaria apenas de apenas um sistema de registro passo a passo dos processos da empresa (qual melhor software pra isso?) ou se ela precisa de um BPMN, ou talvez os dois… como assim?

    Parte dos processos servirão apenas como registro de padrões a serem seguidos (atividade meio) e outros que envolve clientes para os quais seria interessante ter registros estatísticos que fundamentem o processo decisório… outros que fundamentem a atividade financeira.

    Em fim, não sei se ficou clara minhas indagações, mas gostaria de obter uma resposta ou orientação a respeito… finalizo mais uma vez agradecendo o ótimo conteúdo que vocês fornecem.

    Obrigado!

    1. Olá Ilton,
      Em nome de todo o time da iProcess, agradeço sua visita – ficamos felizes que o conhecimento que buscamos compartilhar através do nosso blog pode estar abrindo essa nova porta em sua organização.
      Simplesmente adquirir um software de bpm não irá fazer BPM acontecer em sua organização. É preciso ter em mente que ferramenta é apenas uma parte da capacidade de gestão de processos da organização. Para a iniciativa de processos dar certo, é preciso também desenvolver uma cultura de processos, capacitar pessoas para praticar a gestão dos processos na empresa, definir métodos para identificar, analisar e melhorar os processos para então compreender que necessidades eles podem ter de sistemas. O software em si é apenas uma parte do investimento.
      Gostaria de te indicar dois vídeos gravados de alguns webinares que apresentamos uns tempos atrás, sobre os desafios de implantar BPM nas organizações e algumas sugestões sobre como realizar o primeiro projeto. Também indico um terceiro webinar, no qual falamos mais especificamente sobre como procurar uma ferramenta de BPM para cada empresa.
      Espero que esses vídeos ajudem na sua busca!
      Primeiros Passos em BPM: Da venda interna ao primeiro processo
      Primeiros Passos em BPM: Os desafios do primeiro projeto
      Etapas e desafios da seleção de uma plataforma de BPM

Deixe um comentário para Gabriel Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MAIS VISTOS

Como transformar as ideias de mudança para um processo TO BE em ações efetivas, controladas... (continuar lendo)
Veja agora as ações que foram realizadas através das doações de todos os participantes deste... (continuar lendo)
Participe deste evento exclusive e gratuIto e se prepare para as transformações que IA irá... (continuar lendo)

Inscreva-se na nossa Newsletter

seers cmp badge