Convite para webinar: Automação de Processos pela Área de Negócio: Oportunidades e Desafios

Sobre este webinar:

A necessidade de se reinventar exige das organizações melhorias constantes em seus processos em prazos cada vez menores. Nesse contexto, a recorrente de falta de recursos da TI e a complexidade cada vez maior dos sistemas de informações levam as organizações a buscar alternativas simples e leves de desenvolvimento que possam ser conduzidas pela própria área de negócio.

A automação de processos através de BPMS oferece esta alternativa, mas será que esta promessa realmente pode ser cumprida? Até onde uma área de negócio consegue conduzir com um projeto de automação e em que momento ela volta a necessitar da TI? Que funcionalidades uma ferramenta de automação deve oferecer para atender a estes requisitos? Quais as características ideais de um processo a ser automatizado pela área de negócio?

Participe deste webinar, apresentado ao vivo em colaboração da iProcess e Lecom BPM, e conheça a resposta a estas e outras perguntas relevantes a quem deseja buscar soluções de automação com pouca dependência da TI.

Como funciona?

É simples: inscreva-se no webinar através do link do evento e você receberá um e-mail de confirmação:
Finalizado! Em breve publicaremos o vídeo e a apresentação do evento.

Na data e horário do evento, acesse o link indicado no e-mail usando um computador com fones e aguarde a seção começar.
Durante a apresentação, você poderá interagir com o instrutor enviando perguntas via chat, que serão respondidas ao final do seminário.

Webinares anteriores:

Confira as postagens do blog com os vídeos de nossos webinares anteriores!

Achou interessante?
Compartilhe este convite com seus colegas por Email, Linkedin, Twitter, Facebook e outras redes sociais!

Vale a Pena Mapear Todos os Processos da Organização?

Um dos temas mais polêmicos quando falamos em projetos de modelagem de processos são os projetos cujo objetivo é mapear todos os processos da organização. Projetos desta natureza exigem um envolvimento global de toda a organização, pois dada a natureza dos processos de negócio, toda as áreas e papéis existentes terão que contribuir para o sucesso deste trabalho.

As empresas possuem dentro da sua operação algumas centenas de processos de negócio relevantes. O esforço para mapear tantos processos é enorme, exigindo via de regra algumas milhares de horas de trabalho.

Este esforço não se deve tanto à complexidade técnica do trabalho que tem a ser realizado, mas sim ao volume de processos que devem ser tratados. Como consequência, o projeto acaba envolvendo um número elevado de analistas de processos, muitas vezes até um número maior do que a empresa possui nos seus quadros, fazendo assim da terceirização um meio para viabilizar o trabalho.

Apesar deste número elevado de horas, este tipo de trabalho traz como resultado uma descrição em alto nível destes processos de negócio. Isso porque, se estes consultores precisassem detalhar a nível de procedimento em cada um dos processos, o esforço cresceria exponencialmente, tornando o projeto impraticável. Desta forma, o resultado de tamanho esforço é uma documentação ampla e organizada que mostra a estrutura e hierarquia de cada processo, mas sem entrar em detalhes sobre como são executados os procedimentos de suas atividades.

Com tantas pessoas envolvidas e tanto trabalho a cumprir, projetos desta natureza acabam sendo projetos caros. Não só pelas milhares de horas dos analistas de processos, mas também (e principalmente) pelo tempo demandado das áreas de negócio e por toda mobilização que acaba se fazendo necessária.

Tal mobilização acaba gerando enorme expectativa dentro da empresa: todos esperam que, ao final deste trabalho, a empresa terá um repositório com todos os seus processos e suas respectivas atividades. E é justamente na viabilidade em atender estas expectativas que está o maior desafio.

Processos de negócio são elementos vivos dentro das organizações: diariamente, surgem novas necessidades ou requisitos que exigem a sua adaptação. Quando os processos são modelados ou redesenhados de forma gradativa e planejada, a implantação de uma política de governança que garanta a atualização desta base torna-se natural. Os envolvidos nestes processos possivelmente participaram de toda uma estratégia de mobilização e discussão sobre os processos, sendo assim mais fácil obter o seu comprometimento. Contudo, quando todos os processos da organização são mapeados em poucos meses numa estratégia de documentação em série, a manutenção desta governança e a criação deste comprometimento torna-se muito mais difícil.

Desta forma, a pergunta que fica é: “Como fazer para garantir que, ao final do projeto, toda e qualquer MUDANÇA em QUALQUER PROCESSO será corretamente identificada, analisada e documentada no repositório de processos?

A viabilidade da organização em oferecer esta garantia acaba se tornando o ponto mais crítico de sucesso, uma vez que:

  1. Se a empresa não conseguir manter a base de processos atualizada, em pouco tempo existirão inúmeros processos desatualizados;
  2. Se houverem processos desatualizados, as áreas de negócio começarão a perceber que o repositório de processos não serve como base de consulta;
  3. Se o repositório não servir como repositório de consultas, ele deixará de ser utilizado.
  4. Se ele deixar de ser utilizado, toda a iniciativa cairá em descrédito.

É claro que projetos desta natureza podem trazer inúmeros benefícios, e que as empresas terminando estes projetos se conhecem muito melhor do que quando começaram. Contudo, é importante que as organizações tenham em mente que existe um limite de detalhamento que é passível de manutenção, e que elas não devem investir na criação de uma documentação que elas não conseguirão manter.

 


Conheça mais sobre o Ciclo de Vida de Processos e Projetos de BPM e desenvolva seus conhecimentos nas atividades de mapeamento, análise e redesenho de processos com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

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.

Caso de Sucesso – Aumento da produtividade e efetividade nos negócios do SICREDI com a adoção de SOA e BPM

Marcio Lermen, gerente de tecnologia do Sicredi

Durante o Oracle Open World 2012 em São Paulo, Marcio Lermen, gerente de tecnologia do Sicredi, apresentou como caso de sucesso a adoção da suíte de SOA e BPM da Oracle para a automação dos processos da organização e o uso do Oracle Exalogic como plataforma de hardware e software para dar alta performance a esta suíte.

De acordo com Marcio, a escolha destas tecnologias foi feita dado o desafio que o Sicredi tinha quanto a decisões e processos manuais em um cenário de negócio complexo, em que os processos estão distribuídos entre as cooperativas do sistema. A adoção destas tecnologias viabilizou o redesenho e automação dos processos, apresentando excelentes ganhos no controle da execução dos processos.

Dentre os benefícios obtidos com esta adoção, foi mencionado o ganho de tempo na execução de um processo. Em alguns casos, a automação de um processo (que antes era ad-hoc e feito via envio de e-mails e trocas de telefonemas) fez com que o ciclo de vida do mesmo, que costumava levar vários dias, pudesse ser realizado no mesmo dia. Além disto, foi mencionado o ganho de desempenho com o uso do Oracle Exalogic, que chegou na ordem de 4 a 6 vezes. Segundo Márcio, para conseguir esta performance foi preciso que todos os serviços envolvidos estivessem dentro do Exalogic.

Como pontos importantes apresentados por ele, foram citados os seguintes fatores:

  • o mapeamento e desenho do processo as-is e to-be antes da automação do mesmo;
  • a definição dos pontos onde serão gerados indicadores (que serão enviados ao BAM na execução) durante a definição do processo;
  • a quebra do processo principal em subprocessos menores, inclusive para facilitar o controle de versão e o desenvolvimento;
  • governança SOA, contendo uma arquitetura bem definida, além da necessidade de uma garantia de que a mesma será utilizada dentro dos projetos.

Foram mostrados alguns exemplos de processos criados utilizando Oracle BPM, sendo que muitos deles foram mapeados e criados em parceria com a iProcess.

É um orgulho para nós poder fazer parte de cases de sucesso em BPM do sicredi.

Estimando a duração de processos

Durante a análise de um processo, um dos trabalhos comumente realizados é a estimativa da duração do processo e suas atividades.

Apesar de ser um atributo importante para o entendimento de um processo, o tempo é uma informação  frequentemente avaliada de modo bastante displicente. A estimativa de tempo do processo acaba por ser realizada com base na percepção das pessoas em função do trabalho realizado, em geral na forma de “chute”. O resultado é uma avaliação que não condiz com a realidade – ou porquê foi superestimado, levando a crer que o processo possui um desempenho superior ao seu real potencial, ou subestimado, levando ao entendimento de que o processo não é eficiente pois está sempre atrasado.

Assim, uma avaliação de tempo realizada sem um estudo apropriado tende a impactar em diversas decisões equivocadas de melhoria, já que é um critério essencial para a avaliação do desempenho do processo.

Para se estimar o tempo envolvido na realização de um processo, é necessário compreender os conceitos de: duração, execução e trabalho.

Esquema de espera, execução, trabalho e duração da atividadeO trabalho, ou esforço,  é o tempo que o participante da atividade leva, efetivamente, na realização do trabalho a ser executado. Em uma tarefa, é possível que o trabalho seja realizado em partes antes da mesma ser considerada como concluída.  Por exemplo, o preenchimento de um formulário, a pesquisa de dados adicionais e a complementação do mesmo. Portanto, o tempo de trabalho é a soma do tempo dispendido em ações necessárias para que a tarefa seja concluída.

A execução é o tempo dispendido deste o início do trabalho até o mesmo ser concluído, inclusive o tempo entre as partes do trabalho. Por exemplo, do momento em que a pessoa iniciou o preenchimento do formulário, até o momento em que o mesmo foi completamente preenchido.

A duração é o tempo calculado desde o momento em que a tarefa esteve disponível para o participante responsável pela atividade. Por exemplo, desde o momento que o formulário foi deixado na caixa de entrada do participante,  mais o tempo de espera que levou para que a pessoa tomasse o formulário em mãos para iniciar o trabalho, até o seu completo  preenchimento.

Analisar a execução de um processo requer conhecer o tempo de trabalho, execução e duração de cada atividade envolvida.

Ao se calcular a duração de um processo, entretanto, não basta somar as durações das atividades envolvidas. Em um processo executado manualmente (ou seja, sem o controle por um BPMS), a duração é afetada também pelo handoff, que é a espera dispendida no transporte das informações do processo entre os participantes das atividades.

Esquema de espera, execução, trabalho e duração de processo manual

Um exemplo clássico do tempo de espera em transporte é, por exemplo, o tempo levado para que um formulário preenchido em uma atividade seja disponibilizado para o participante da próxima atividade.

Assim, a duração do processo é a soma da duração das atividades mais a soma das esperas entre atividades.

Estimar corretamente os tempos de um processo pode levar a várias ações de melhoria, como:

  • Definir níveis de serviço (SLA) realistas;
  • Definir indicadores que apoiem na identificação de gargalos em atividades, baseados no tempo de espera que uma atividade leva para ser iniciada;
  • Melhorar a distribuição de recursos para realizar as atividades de acordo com o volume de trabalho;
  • Melhorar as ferramentas utilizadas pelos participantes das atividades a fim de agregar velocidade à realização do trabalho;
  • Avaliar melhoria de desempenho simplificando-se ou removendo-se tempos de transporte (handoffs), ou mesmo buscando métodos de transporte mais eficazes.

A automatização de processos é uma alternativa para a busca de desempenho e solução para o transporte das informações entre as atividades. Em geral, há dois benefícios comumente identificados na automatização relacionados ao tempo de execução do processo:

  1. Eliminação do tempo de handoff, já que o motor do processo disponibiliza as informações ao próximo participante imediatamente após a conclusão da atividade anterior;
  2. Eliminação do tempo de espera em atividades executadas pelo sistema (como serviços de busca ou gravação de informações, por exemplo), já que a execução das mesmas é realizada imediatamente  quando a atividade é disponibilizada.

Esquema de espera, execução, trabalho e duração de processo automatizado

Seja executado por controles manuais ou automatizado com um BPMS, compreender a análise dos tempos na avaliação da duração de atividades e processos é uma ferramenta de gestão fundamental rumo à melhoria do desempenho dos processos da organização.


Leia mais sobre o cálculo da duração de processos no artigo complementar Estimando a duração de processos II – processos não lineares.

Qual o melhor BPMS do Mercado?

Frequentemente, clientes e prospects perguntam aos consultores da iProcess qual é a melhor ferramenta de BPMS existente hoje no mercado. Infelizmente não existe uma resposta única para esta questão e a dificuldade em respondê-la advém de inúmeros fatores.

Nesse post procuramos elencar alguns dos motivos pelas quais a escolha de uma plataforma de BPM é uma escolha tão difícil.

  1. Por ser uma escolha corporativa: soluções de BPMS não são soluções departamentais: assim como os processos, que possuem uma natureza transversal na organização, uma solução de BPMS tende a ser utilizada por toda a organização.
  2. Pela necessidade de atender diferentes necessidades: sendo uma escolha corporativa, a escolha da solução de BPMS deve atender a um conjunto amplo de demandas: caso contrário, corre-se o risco de se deixar alguma necessidade organizacional à descoberta. Isso exige que um amplo levantamento de expectativas deve ser realizado antes da sua seleção, de modo a evitar uma quebra de expectativa após a escolha da solução.
  3. Pelo enorme conjunto de funcionalidades disponíveis: Existem hoje mapeados na iProcess mais de 600 requisitos que podem ser avaliados na escolha de uma ferramenta de BPMS. Obviamente nenhuma ferramenta atende a estes 600 requisitos, e tão pouco é comum as empresas terem demandas tão complexas a ponto de necessitar todos estes requisitos sejam atendidos como obrigatórios. Desta forma, o casamento entre o que a empresa precisa e o que a plataforma disponibiliza é um fator crítico de sucesso na escolha da plataforma.
  4. Pelo número de alternativas que existem hoje no mercado: Existem hoje centenas de ferramentas de BPMS disponíveis no mercado. Só no Brasil são fabricadas dezenas, sem contar tantas outras que possuem escritórios de representação instalados no país.
  5. Pelo enfoque dado pelo fabricante ao conceber o seu produto: Via de regra os produtos de BPMS possuem categorias de funcionalidades que se destacam dos demais devido a forma como surgiu o produto. Produtos de BPMS se originaram de diferentes segmentos tecnológicos, tais como a gestão de conteúdo, a colaboração, a integração entre sistemas, a edição de formulários, …
  6. Pela enorme variação de valores financeiros envolvidos: Existem atualmente produtos para todos os bolsos e gostos: desde aqueles que são totalmente gratuítos (mas que possuem contratos de suporte e manutenção) até aqueles cujo o licenciamento pode chegar à centena de milhares de dólares. A forma de licenciamento também tem o impacto direto na sua precificação, sendo os tipos mais comuns as licenças por usuário ou processador.
  7. Pelas plataformas tecnológicas existentes na organização: As plataformas tecnológicas disponíveis dentro da organização podem facilitar ou inviabilizar a escolha de uma plataforma de BPM. Questões como, por exemplo, o sistema operacional utilizado nos computadores clientes e servidores (Windows, Linux, Unix, …); o banco de dados da organização (Oracle, DB2, Postgress, SQL Server, …); o servidor de aplicação disponível (IIS, Apache, WebLogic, Websphere, …); a linguagem de desenvolvimento utilizada (Java, .NET, PHP, …) podem ser fundamentais na análise de aderência de uma ferramenta de BPMS à plataforma atual.

A escolha certa de uma plataforma de BPM passa por uma análise detalhada de cada um destes fatores. É importante ter em mente que a escolha inadequada de uma solução de BPMS pode inviabilizar a execução de alguns processos de negócio da sua organização e, em última análise, até mesmo as suas iniciativas de gestão por processos.

[Atualizado] Leia também: ferramentas BPMS livres ou de baixo custo são sempre mais baratas do que as ferramentas pagas?

Até lá.

Até onde vão os benefícios da automatização de processos “zero-code”?

Quando buscamos soluções de BPMS (Business Process Management System), um dos argumentos mais sedutores lançados pelas equipes de vendas dos produtos é o de “zero-code”, ou “código zero”. Zero-code é a promessa de que o produto permite que um usuário de negócio possa modelar seu processo e disponibilizá-lo para execução automatizada sem a necessidade de desenvolver código de programação.

Esta proposta vem de encontro a uma percepção geral do negócio em relação à TI. Num cenário em que as organizações possuem inúmeros sistemas, nas mais diferentes plataformas e tecnologias, e em que o suporte tecnológico encontra dificuldades em atender com agilidade as necessidades do negócio para acompanhar às mudanças estratégicas do mercado, as empresas já não querem mais TI. Querem resultados.

Assim, a expectativa de poder modelar seus processos e executá-los sem requerer o envolvimento de analistas de sistemas e desenvolvedores soa extremamente atraente.

Mas o que significa de fato “zero code” e até onde um processo pode ser implementado com esta visão?

Parte desta impressão é alimentada pela adoção de uma “linguagem” de modelagem de processos em comum: a notação BPMN (Business Process Model and Notation). BPMN permite que a documentação de um processo em nível de negócio possa ser complementado para adquirir profundidade técnica à medida que é preparado para a implementação. Assim, o processo de negócio modelado pela área de negócio pode ser o mesmo a ser implementado no BPMS adotado pela organização.

O fato de BPMN permitir que usuários de negócio possam mapear e detalhar seus processos, leva muitas ferramentas vislumbrar a participação destes usuários de forma mais ampla do que a simples definição e detalhamento para o desenvolvimento de aplicações tradicionais. O usuário de negócio capacitado pode: definir a cadeia de atividades e suas dependências, definir regras de negócio para manejar fluxos alternativos, detalhar o que deve ser solicitado a cada participante nas atividades para que as mesmas sejam consideradas como concluídas, definir quem são os responsáveis por realizar o trabalho de cada tarefa.

Para tanto, existem algumas premissas básicas na realização de um projeto como este:

I. O(s) usuário(s) de negócio precisa(m) ter alto domínio sobre tecnologia e sobre a ferramenta para compreender e aplicar corretamente cada um de seus recursos;

II. O(s) usuário(s) de negócio deve(m) ter noções de construção de telas/formulários através do qual os participantes irão interagir com o processo em suas atividades;

III. O processo deverá ser essencialmente humano e restrito às informações coletadas em sua execução.

O resultado do processo sem envolvimento da TI está de certa forma limitado às funcionalidades mais básicas da solução de BPM, produzindo um workflow de atividades humanas com baixo nível de (ou sem) inteligência. Sem programação não é possível utilizar-se da inteligência que a organização já possui e que está distribuída nos seus sistemas sob a forma de informação.

Um dos aspectos mais importantes do processo é a informação. Naturalmente, durante o desenho do processo de negócio são identificadas necessidades de informações que precisam ser reunidas de fontes diferentes e eventualmente transformadas para sustentar a execução do processo.

Assim, inevitavelmente a participação de profissionais de TI acaba sendo necessária. Não apenas para o resgate e armazenamento de informações no decorrer do processo, mas a própria questão da interface do usuário nas atividades do processo – que muitas vezes requer mais do que oferece o formulário básico que pode ser construído com os recursos disponibilizados pela ferramenta.

O que ocorre então é a necessidade da própria TI rever seu papel, sobretudo do Analista de Sistemas. O novo analista deve ajudar a construir o processo, identificando juntamente com o negócio os componentes de software que precisam ser desenvolvidos para:

  • coletar informações do processo para alimentar os sistemas legados;
  • buscar informações de sistemas legados para disponibilizar aos participantes do processo, minimizando  a necessidade de acessar a diferentes sistemas para isso;
  • identificar melhorias de interface que reduzam o esforço de interação do usuário com o processo (como busca de valores existentes, cálculos, etc);
  • identificar validações que possam ser feitas pelo sistema para garantir a integridade do processo;
  • identificar formas mais eficazes de realizar o balanceamento de atividades em grupos.

Automatizar atividades humanas sem fazer uso inteligente dos recursos computacionais da empresa no que se refere à obtenção de informações agregará pouco ou nenhum valor ao processo e como consequência apresentará retorno do investimento muito abaixo das expectativas.

Benefícios da Automação de Processos

A automação de processos procura definir e otimizar os processos de negócio para, em seguida, executá-los sobre uma arquitetura de sistemas informatizada. Esta automação não está limitada à mera execução de atividades automáticas por computadores; vai além, mantendo uma ampla intervenção humana e a participação dos diferentes participantes relacionados, como colaboradores, clientes e parceiros.

Um BPMS (Business Process Management System) oferece os seguintes controles de integridade de um processo:

  • A ordem das atividades é mantida e regulada pelo BPMS.
  • A realização das atividades previstas é garantida.
  • Garantia das condições necessárias para encerramento de cada atividade.
  • Controle de cadeias de responsabilidade (alçadas de decisão)
  • Controle de papéis e responsabilidade.

Ao automatizar, garantimos a execução do processo em sua forma, cumprindo-o fielmente da maneira como foi pretendido e eliminando as possibilidades de infringir as regras de integridade do processo, seja por fraude, desconhecimento ou negligência.

O rápido progresso da tecnologia também pode ajudar a economizar tempo e a dirimir os problemas da distância. Se em outros tempos essas eram barreiras à execução de um trabalho, isto já não é mais verdade. Um processo automatizado permite que os participantes realizem suas tarefas a partir de locais de trabalho virtuais, em que os funcionários operam remotamente entre si ou com a gerência.

A interação com um processo automatizado não está restrita a uma ferramenta ou um meio apenas. É possível implementar um processo com interação através de e-mails, sistemas legados, aplicações móveis (smartphones, pdas, celulares, tablets), portais e sistemas web.

Pode-se implementar um processo em ambientes de Intranet ou Extranet, permitindo a participação ativa de clientes, parceiros e fornecedores e possibilitando que equipes ou filiais trabalhem cooperadamente mesmo à distância.

Outra grande vantagem de se automatizar um processo de negócio reside na simples premissa de que nos casos em que a interação humana agrega pouco valor à realização da tarefa, estas atividades manuais podem ser automatizadas, poupando tempo e recursos.

Calcular Impostos

A atividade “Calcular Impostos” executa automaticamente uma atividade que dependia de decisão humana de acordo com uma série de regras pré-definidas.

Se em um processo as pessoas precisam interagir com diferentes sistemas para realizar suas tarefas, é possível desenhá-lo de forma que essas interações sejam feitas de automaticamente. Isto gera ganhos em produtividade, pois os participantes não necessitam mais inserir dados manualmente, reduz a possibilidade de erros humanos e assegura, pelo BPMS, o controle e tratamento das integrações com outros sistemas.

Gerar Pedido via EDI

"Gerar Pedido via EDI" é uma atividade de sistema que gera, automaticamente, um pedido no sistema EDI.

O tempo dedicado à transferência de uma atividade de um participante a outro pode, também, ser excessivamente longo. Por vezes é preciso levar documentos fisicamente a alguém para que o processo possa seguir seu caminho e é necessário que cada pessoa conheça o processo ou, ao menos, quem é a próxima pessoa a interagir com ele. Um conhecido caso deste tipo de situação são os processos judiciais, que até recentemente sempre tramitavam entre tribunais em grandes volumes de papéis impressos. Esta troca de mãos da informação agrega grande lentidão ao processo.

Neste sentido, o processo automatizado poupa tempo e recursos porque permite o tráfego eletrônico de documentos (ou informações). Também o BPMS envia a atividade ao próximo participante de forma praticamente imediata e, como é ele quem identifica o próximo participante, as pessoas podem se concentrar em executar suas tarefas diminuindo a necessidade de que conheçam o processo em sua totalidade.

E a proatividade de um processo automatizado não está limitada a repassar atividades, ele também controla os prazos de execução de tarefas e executa as ações definidas quando estes não são cumpridos, sem a necessidade de intervenção ou monitoramento.

Timeout de Prazo

A atividade “Aprovar Pedido de Férias” tem prazo definido. Quando este prazo expira, o BPMS automaticamente envia uma outra atividade informando sobre o atraso.

A automação de um processo permite obter uma enorme quantidade e variedade de indicadores extremamente úteis para a gestão. São meios que permitem saber, por exemplo, quanto tempo o processo está levando, se parou, quanto tempo parou e porque parou. Isto é possível porque o BPMS armazena todas as informações referentes às execuções das instâncias dos processos.

Com isto, é possível consultar o estado atual e histórico de cada processo ou atividade, identificando participantes, dados inseridos e resultados obtidos em cada uma das instâncias.

Dashboard de Monitoramento

Exemplo de dashboard de monitoramento dos processos em tempo real

Com as ferramentas incluídas na maioria dos BPMS, pode-se extrair relatórios para analisar as informações e indicadores medidos na execução das diferentes instâncias do processo. A consolidação e análise dessas informações oportuniza a melhoria contínua destes processos, dando ao gestor as informações que este necessita para tanto.

O controle de qualidade de um processo de negócio está necessariamente ligado a indicadores e estes são difíceis de se obter. A automação de processos permite obtê-los de forma facilitada em relação aos métodos tradicionais, possibilitando enormes oportunidades de medição e evolução do negócio.