Evento gratuito mostra como automatizar processos com Metodologia Ágil

De 13 a 17 de agosto, a iProcess e a Lecom estarão realizando a semana do desenvolvimento ágil de processos, um evento onde serão ministradas aulas exclusivas do EAD de Transformação Digital Orientado a Processos da iProcess ensinando as empresas como realizar a automação de processos utilizando a metodologia ágil.

Veja a nossa  programação:

  • Aula 1 – Dia 13/08, segunda-feira: Introdução ao paradigma Ágil
  • Aula 2 – Dia 14/08, terça-feira: Fundamentos da Aplicação de Métodos Ágeis em Projetos de Tecnologia
  • Aula 3 – Dia 15/08, quarta-feira: Princípios do Desenvolvimento ágil orientados a Automação de Processos
  • Aula 4 – Dia 16/08, quinta-feira: Diretrizes para a Definição de Releases de Processos em uma Metodologia

E na sexta-feira, 17/08, teremos uma aula BÔNUS, AO VIVO, às 10h, com Eduardo Britto, tirando todas as dúvidas. É só deixar as perguntas nos comentários.

Deixe anotado a data: de 13 a 17/08. As aulas serão disponibilizadas no seu e-mail com o link de acesso.

Inscrições gratuitas, garanta sua participação:

Esperamos vocês lá.

 

A nova geração de BPMS na nuvem – e como eles podem alavancar a gestão por processos na sua empresa

A primeira geração de ferramentas para controlar atividades de processos, antes mesmo de BPM se tornar uma disciplina, eram os Workflows – soluções muitas vezes disponibilizadas como parte de uma solução maior (como um ERP) que possibilitava alguma customização dos fluxos de tarefas envolvidas em algum negócio. De forma especial, esses workflows visavam controlar fluxos de aprovações e ações e tinham um caráter fortemente humano.

Com a evolução da tecnologia e o crescimento das bases de informações, distribuídas em diversas aplicações diferentes dentro da infraestrutura das empresas, aliado ao crescente foco na otimização de processos dentro das empresas, estas soluções ganharam uma sigla própria: BPMS – Business Process Management Suites.

Os BPMS agregam diversas funcionalidades que possibilitam modelar, controlar e monitorar a execução dos processos de negócio, de forma transversal. Isto quer dizer que estas tecnologias evoluíram para um controle de execução dos processos buscando maior interação entre atividades humanas e disparo de ações em diferentes sistemas de informação, conforme a necessidade.

Com foco em tornar as interfaces de interação humana mais ricas (com construções de telas mais elaboradas) e adoção de melhores práticas no acionamento de ações em outros sistemas (especialmente visando aderência com arquitetura SOA), estas soluções acabaram se tornando suítes excessivamente robustas, que exigem elevada infraestrutura computacional pra sustentá-las, e, como consequência, tornando-se tão caras que acabaram afastando o sonho de gerenciar processos de muitas organizações onde o custo não justificava o investimento.

Nos últimos anos porém, temos visto nascer uma nova geração de suítes para gerenciamento de processos despontando no mercado de tecnologia – os BPMS na nuvem, em geral disponibilizados no modelo SaaS (Software as a Service).

Veja como as novas soluções de BPMS na nuvem podem alavancar as iniciativas de gerenciamento de processos em empresas de todo porte:

Motor de processos mais enxuto agiliza a disponibilização dos processos

A grande maioria dos BPMS tradicionais possuíam uma arquitetura na qual a camada de apresentação (telas das tarefas) eram acionadas da mesma forma que outros serviços, o que envolvia uma série de configurações como mapeamento de variáveis de entrada e saída, controles de salvamento intermediários dos dados e componentes visuais que eram um verdadeiro quebra-cabeças. Entre outros problemas, isso dificultava o envolvimento da equipe de negócios na definição das interfaces de uso, pois exigiam conhecimento técnico e de lógica de programação.
Os BPMS na nuvem, em geral, buscam formas mais simplificadas de possibilitar uma construção de interface rica nas tarefas de usuário do processo. Alguns recursos de BPMN de alta complexidade em processos (e baixíssimo uso em projetos reais), como gateways complexos ou controles de transações, não costumam fazer parte dessas suítes, que buscam uma relação 80-20 (cerca de 20% dos elementos que atendem a 80% das necessidades dos processos a serem gerenciados nas organizações).

Capacidade de integração com outros serviços oferecidos na nuvem amplia a inteligência do negócio

As soluções na nuvem baseiam-se em estruturas de conectividade já bastante estabelecidas ao mesmo tempo que conseguem adaptar-se mais rapidamente a novos protocolos de conexão – o que possibilita aos processos aproveitarem a riqueza da conectividade da internet para executar ações não apenas através do acionamento de serviços da sua infraestrutura de informação, mas também de outros serviços disponíveis através da web (por exemplo: serviço de verificação de risco de crédito).

Elimina necessidade de adquirir e manter infraestrutura própria para a solução

Muitas vezes ignorado no custo da solução, ter um BPMS instalado na infraestrutura do cliente não envolve apenas os custos com licenças de uso da solução. É comum que esse tipo de plataforma envolva outros custos como aquisição e manutenção de um servidor próprio de aplicações, e licenças de outros softwares de infraestrutura complementares como portais, barramentos, etc. As soluções disponibilizadas na nuvem já abstraem estes custos, porque muitas vezes uma mesma infraestrutura pode ser compartilhada com outros clientes – mantendo-se é claro o controle de segurança e sigilo sobre os dados de cada um. Este modelo de compartilhamento torna estas soluções mais acessíveis, além de serem modulares (podem ser combinadas com outras soluções de apoio à gestão como portais de gestão de conteúdo, ferramentas analíticas, etc)

Investimento pode começar numa iniciativa simples e crescer junto com o negócio

Os BPMS disponíveis na nuvem permitem gerenciar o custo, ampliando o número de licenças ou a capacidade de processamento conforme a organização for implantando os processos e envolvendo mais pessoas. Assim, a iniciativa de suporte tecnológico para BPM não precisa iniciar grande – ela pode começar com passos bem medidos e planejados de investimento.

Isto também simplifica “dar um pé atrás”. Se o primeiro projeto já demonstrou que a ferramenta não é a mais aderente para as necessidades de processo ou mesmo da cultura da empresa, é mais fácil repensar e mudar de plataforma (sem aquela sensação de ter que forçar a barra para justificar o tempo e dinheiro gasto na aquisição e implantação de uma plataforma muito robusta).

Mais simples de começar

As plataformas de BPM na nuvem já estão prontas e são rapidamente disponibilizadas mediante um start up muito menor. Ainda que seja necessário algum trabalho de inicialização da plataforma, como por exemplo integração com as soluções de gestão de identidades da organização, estruturação da hierarquia de áreas e funções, etc, ainda assim o início do uso da solução é mínimo perto das plataformas instaladas. Além disso, estas ações de inicialização podem acontecer em paralelo à modelagem e configuração do primeiro processo, trazendo ainda mais agilidade para a implantação da solução.

Isto possibilita começar com processos simples e pequenos, sem integração ou baixa interação com outros sistemas, demonstrando resultados rapidamente e possibilitando disseminar a cultura BPM na organização.

Modelagem na nuvem estimula a colaboração e transforma gestores e participantes em profissionais do conhecimento

Os modelos de processos na nuvem podem são mais fáceis de serem compartilhados e editados por grupos de pessoas, ao mesmo tempo que controlam diferentes niveis de segurança (quem pode ver, quem pode editar, quem pode disponibilizar) e mantêm histórico das diferentes versões do processo.

Isto estimula os participantes a contribuírem mais ativamente na elaboração do fluxo e também das interfaces e formulários para as tarefas que serão executadas no processo automatizado.


Procurando ajuda para identificar a plataforma de BPM mais alinhada com as necessidades da sua empresa? Conheça os serviços da iProcess em soluções e projetos de automação de processos:
http://iprocess.com.br/bpm/automacao-de-processos/

 

3 dicas para se preparar para o exame CBPP – Certified Business Process Professional

CBPP – Certified Business Process Professional, concedida pela ABPMP Internacional, é certificação a mais valorizada atualmente no mercado brasileiro para os profissionais envolvidos em gestão por processos de negócio, e uma das mais importantes em caráter internacional.

É um grande investimento na carreira profissional de quem atua no mercado de BPM. Por isso, compartilhamos aqui algumas dicas interessantes para você que está se preparando para fazer o exame e se tornar um profissional de processos de negócio certificado.

1) Estude o BPM-CBOK

A base para esta certificação é o Corpo Comum de Conhecimento em Gerenciamento de Processos de Negócio (BPM CBOK), que atualmente encontra-se na sua terceira versão.
O BPM CBOK discute nove áreas de conhecimento sobre a Gestão por Processos distribuindo-as em duas perspectivas – a das atividades do ciclo de vida de processos  (gerenciamento de processos, modelagem, análise, desenho, gerenciamento de desempenho, e transformação de processos), e a da disciplina em nível organizacional (organização do gerenciamento de processos e gerenciamento corporativo). Além disso, também dedica uma área específica para tratar as diferentes tecnologias que suportam a prática de BPM nas organizações.

É importante conhecer bem os conceitos relacionados a cada uma dessas áreas de conhecimento.

Você pode iniciar seus estudos do BPM CBOK com a versão digital deste guia, que pode ser obtido através do próprio site da ABPMP Brasil:
http://www.abpmp-br.org/bpm-cbok-v3-0/

Se você precisar de uma ajuda para revisar a fixação dos conceitos, a iProcess Education tem um kit de Simulado para Exame CBPP, com cerca de 150 questões diferentes sobre todas as áreas de conhecimento do BPM CBOK e inspiradas no exame.
Saiba mais em: http://iprocesseducation.com.br/simulado_CBPP


2) Aproxime a prática do seu dia a dia às boas práticas recomendadas pelo BPM CBOK

O BPM CBOK não é um livro de instruções sobre como aplicar BPM, mas ele faz um alinhamento de questões relevantes e que devem se tornar práticas comuns entre os profissionais nesta disciplina de gestão de negócios.

Avalie o cenário atual da sua organização e trace paralelos com as práticas sugeridas pelo guia. É a melhor forma de fixar os conceitos e se alinhar com a visão de gestão por processos, além de uma excelente forma de avaliar o nível de maturidade da sua empresa no gerenciamento de processos de negócio.

Avalie também se você está preparado para se tornar um profissional CBPP. Como ela é uma certificação de proficiência em BPM, é preciso comprovar experiência para se submeter ao exame. Se precisar, invista em cursos que possam ajudar na sua preparação. 

A iProcess Education tem o compromisso de alinhar em seus treinamentos a teoria do BPM CBOK com a experiência prática dos diversos projetos pela nossa equipe.  Confira as próximas edições do programa de formação Ciclo BPM – Da Estratégia à Medição.


3) Participe do BPM Bootcamp e considere isto um valioso investimento

Com tantas oportunidades para se atuar no mercado de BPM, e tantos papéis diferentes em que uma pessoa pode se envolver, que é bastante natural que os profissionais acabem se especializando em algumas atividades ou conhecimentos específicos. Por exemplo:

  • Há profissionais de BPM que geralmente possuem uma formação em TI e quando entram no mercado de BPM, costumam ter um foco direcionado a projetos de automação de processos. Por isso sua visão da gestão por processos está mais associada à aplicação de soluções e plataformas tecnológicas para controle e monitoramento dos processos.
  • Há profissionais geralmente provenientes de formações relacionadas a O&M e qualidade, cuja especialidade está em modelar e padronizar processos organizacionais. Por isso sua visão de processos está mais relacionada à organização e documentação padronizada do conhecimento da execução de processos e a identificação e mitigação ou solução de potenciais riscos na variação da execução dos processos.
  • Há também os profissionais que atuam em projetos de análise, criando diagnóstico de processos e propondo redesenhos, muitas vezes com o objetivo de reduzir custos ou melhorar a qualidade.
  • Alguns possuem grande experiência em processos de um determinado nicho de negócio (como por exemplo os processos fiscais e tributários brasileiros, ou as particularidades dos processos na área de saúde), outros são mais generalistas, atuando com menos profundidade em uma variedade maior de processos.

As diferentes formas de atuar na disciplina de BPM faz com que a visão conceitual relacionada ao tema de processos tenha uma perspectiva diferente para cada um destes profissionais, e pode estar limitada ao seu conjunto de técnicas e práticas. O profissional CBPP precisa ampliar sua visão além da sua prática diária, devendo conhecer a disciplina BPM em todas as suas áreas de conhecimento, mesmo que sua atividade profissional esteja aprofundada em uma ou duas delas.

Por isso, considere a participação no BPM Bootcamp não como mais um custo para buscar a certificação, e sim como um investimento justamente na ampliação desta visão. O BPM Bootcamp oportuniza a discussão e troca de experiência com profissionais que atuam sob as mais variadas perspectivas da gestão por processos nas organizações e que estão, naquele momento, visando o mesmo alinhamento que você.

Geralmente, o BPM Bootcamp acontece nos dias que antecedem a data de exame para a certificação. Acompanhe a agenda de eventos da ABPMP Brasil e verifique qual o próximo BPM Bootcam e CBPP Exam mais próximo de você:

http://www.abpmp-br.org/

Outras dúvidas sobre o BPM Bootcamp podem ser obtidas diretamente com a equipe da ABPMP pelo email secretaria@abpmp-br.org.

 

5 fatores de sucesso para enfrentar os problemas de integrações na automação de processos

Tendo participado de vários de projetos de automação de processos, se tem algo que podemos afirmar como sendo um denominador comum a projetos de automação em empresas das mais diferentes áreas, é dos problemas que surgem quando existe necessidade de integração do processo automatizado com outros sistemas/organizações.

O fato é que problemas relacionados a integrações invariavelmente vão ocorrer, apenas variando de acordo com o grau de complexidade do processo e das integrações em si. Por outro lado, existem sim alguns fatores e cuidados que podem evitar problemas ou facilitar a sua resolução.

Ter conhecimento destes fatores no projeto vai prepará-lo melhor para o que vem pela frente.

Vamos a eles?

1. Ter uma boa governança dos serviços/integrações/funcionalidades disponíveis

Durante a automação do processo, é comum detectar uma ou mais necessidades de integração (ex: salvar alguma informação digitada durante a execução do processo num banco de dados).

Em nossa experiência, boa parte dos problemas que ocorrem nestes casos se devem a falta de governança da organização em relação aos serviços, integrações e sistemas existentes, ou seja, não se sabe se aquela necessidade de integração do processo já se encontra disponível (ex: através de um webservice).

A consequência disso é a necessidade de se discutir do zero esta integração, fazer orçamento e incluí-la no escopo, o que leva a aumento do prazo e custo do projeto. Um fator que minimiza bastante estes problemas é se a organização já trabalha numa Arquitetura Orientada a Serviços, ou simplesmente SOA (mais informações aqui, aqui e aqui), bem como dispor de ferramentas de governança/pesquisa de serviços.

2. Prever o modelo de dados do processo adequado as necessidades de integração

Quando um processo será automatizado, deve-se previamente fazer uma análise para definir o “modelo de dados” do processo, ou seja, as informações que serão visualizadas e manipuladas ao longo da execução do processo (veja aqui para mais informações).

A definição deste modelo de dados costuma ser mais transparente quando estamos falando de informações que ficam visíveis no formulário eletrônico do processo, ou seja, as informações que os usuários vão visualizar/editar ao acessar as tarefas. Mas infelizmente não é tão óbvio quando falamos de integrações.

Por exemplo, se é necessário chamar uma integração para atualizar uma informação no ERP a partir do processo automatizado, pode se descobrir que uma das informações obrigatórias para se chamar esta integração é específica daquele sistema (ex: um determinado identificador), e esta informação não foi prevista inicialmente no modelo de dados.

Com frequência, inclusive, ocorre a situação de que para obter a informação que você precisa para chamar uma integração, é necessário chamar outra integração!

Este fator costuma gerar muitas dores de cabeça, em muitos casos não é fácil prever todas as possibilidades.

3. Ter conhecimento das funcionalidades e limitações do framework de integração do BPMS

Mesmo que inicialmente a empresa tenha adquirido uma solução de BPMS para um processo pontual ou para apenas gerenciar fluxo de trabalho sem integrações com outros sistemas, o fato é que as necessidades da organização mudam. Quando chegar o momento em que as iniciativas de automação de processos passarem a demandar mais inteligência, com integração de dados existentes em outros sistemas, é importante conhecer as funcionalidades e limitações de integração do BPMS.

Por exemplo, alguns questionamentos comuns nestes casos:

  • Posso chamar webservices através do BPMS?
  • Consigo conectar diretamente num banco de dados através do BPMS?
  • Existem adaptadores nativos que permitem conexões com sistemas conhecidos no mercado?
  • O BPMS me permite realizar transformações complexas de dados ao chamar ou obter o retorno de um webservice?
  • Existe algum formato específico de assinatura do serviço para poder ser acionado?
  • Com que tecnologias o BPMS permite fazer integração? Soap? Rest? Corba? EJB? .net? Controle de arquivos no filesystem? Outros?

Este conhecimento é importante para detectar eventuais restrições da ferramenta, identificar a necessidade de utilizar outras ferramentas em conjunto ao BPMS, ou no pior dos cenários até a troca do próprio BPMS. Por exemplo: se o BPMS não é capaz de fazer transformações de dados complexas ao chamar um webservice, então possivelmente será necessária outra ferramenta (ex: uma ferramenta de barramento de serviços) que fará esta transformação no lugar do BPMS, expondo para o BPMS uma versão simplificada do serviço. Neste mesmo exemplo, pode ser que esta ferramenta adicional não exista na organização, e precisa ser previsto a sua contratação e implantação, dentro do escopo do projeto de automação.

Entenda a importância de uma avaliação detalhada sobre recursos ​dos produtos ao adquirir uma plataforma ​BPMS com ​esta coleção de artigos sobre Seleção de Plataformas de BPM.

4. Equipes dos sistemas disponíveis para apoiar o projeto

Parece chover no molhado, afinal se um processo automatizado precisa se comunicar com o sistema X, então a equipe de apoio deste sistema tem que estar envolvida, certo? Bem, temos algumas histórias de iniciativas de automação de processos aprovadas em nível executivo, mas que durante o andamento do projeto as equipes dos sistemas estavam em uma das seguintes condições:

  • Não estavam sabendo do projeto – o popular “cair de paraquedas”  (sim, é comum);
  • Sabiam do projeto e que em algum momento iriam se envolver, mas não tinham nenhum contexto dos objetivos do projeto e o seu papel (tem na prática os mesmos efeitos nocivos da situação anterior);
  • Sabiam do projeto e tinham o contexto, mas não tiveram a alocação reservada para apoiar o projeto (“Eu conheço o projeto e entendo o que devo fazer, mas não sei se vou conseguir ajudá-los ainda neste mês…”).

Quando as equipes dos sistemas começam a se envolver no projeto, é comum surgirem problemas e limitações que não se tinha noção, o que pode ocasionar necessidade de se rediscutir a solução. Aqui o apoio da liderança executiva e da gestão de projetos é fundamental para minimizar os problemas, reforçando a alocação das equipes dos sistemas envolvidos, para se envolverem no projeto de automação o quanto antes, preferencialmente ainda durante as fases de análise e projeto.

5. Atenção à  etapa de testes

Se existem integrações no processo, obviamente as mesmas precisam ser bem testadas, envolvendo as equipes responsáveis pelos sistemas de origem/destino das informações.

Ocorre que na automação de processos, assim como no desenvolvimento tradicional de sistemas, pode ocorrer a tendência de dar ênfase maior apenas a “interface” do processo, que no caso do BPMS são os formulários das atividades enviadas para os usuários. Mas obviamente as integrações que são feitas automaticamente pelo processo devem ser testadas com o mesmo cuidado, verificando se estão retornando ou gravando as informações corretamente.

Isto comumente é realizado utilizando os recursos de rastreamento/auditoria presentes das próprias ferramentas de BPMS (verificando o que está recebendo ou enviando de informações), bem como acessando diretamente o sistema com o qual se tem a integração (para verificar se os dados sendo obtidos/atualizados pelo BPMS estão corretos).

Estas verificações normalmente exigem um conhecimento técnico maior (ex: visualizar payloads em XML, acessar as informações diretamente em tabelas do banco de dados do sistema em questão, etc).

 

Sem dúvida existem outros fatores envolvidos, mas acreditamos que os fatores citados acima dão um bom norte para a equipe do projeto se preparar e enfrentar os problemas que podem ocorrer nas integrações durante a automação de processos.

 

Diagramas BPMN com ou sem raias: 3 abordagens em que o foco da modelagem faz a diferença

Usar ou não usar pools e lanes (piscinas e raias) na modelagem de processos é uma discussão de longa data e persistente ainda nos dias de hoje.

A especificação da notação BPMN apresenta e explica a utilização destes componentes mas declara que o seu uso é opcional, o que dificulta ainda mais o entendimento por algumas equipes sobre quando e como usá-los.

Modelar com swimlanes pode trazer clareza visual sobre as entidades organizacionais envolvidas no processo, porém tende a deixar o diagrama mais carregado visualmente, já que haverá mais linhas para se cruzarem e em alguns casos conectores mais longos para unir atividades em raias distantes.

Não utilizar swimlanes, por outro lado, permite aproximar as atividades e elementos do fluxo criando um diagrama teoricamente mais enxuto, mas torna implícito a identificação das áreas e papéis resolvidos – o que até poderia ser resolvido por outros artifícios como o uso de anotações ou complementação na descrição das tarefas (forçando a ter caixas maiores para cada elemento do fluxo e igualmente carregando visualmente o diagrama do processo).

Entre os prós e contras de cada abordagem, há um aspecto muito mais relevante a ser considerado: para quê o modelo de processo está sendo criado.

Exploramos aqui três focos de modelagem que podem ajudá-lo nessa avaliação.

Para ilustrar cada abordagem, vamos utilizar como exemplo um fluxo inspirado no clássico processo de tele-entrega de pizza, traduzido livremente do modelo “5.2 The Pizza Collaboration” em BPMN 2.0 by Example (já usamos este exemplo em um outro artigo sobre modelagem de processos no blog da iProcess – aqui).

1. Quando o foco é analisar como as atividades adicionam valor ao processo 

Neste caso, a melhor abordagem de modelagem pode ser sem lanes, desenhando o processo como um fluxo linear em que todas as atividades essenciais estão em uma mesma linha, e tudo o que é contorno/alternativa é mapeado para cima ou para baixo do fluxo.

Esta é uma abordagem de uso da notação BPMN inspirada em Lean, no qual o Value Stream Mapping (VSM) busca mapear o fluxo de adição de valor do processo.

Esta abordagem foca na fluidez das atividades essenciais à produção do resultado do processo, que são as que devem ser priorizadas em ações de melhoria do processo visando a sua otimização.

 

2. Quando o foco é compreender as responsabilidades dos envolvidos na execução do processo

Aplicar a abordagem de raias para representar os papéis envolvidos no processo é interessante para deixar mais claro visualmente as responsabilidades de cada participante.

Isto possibilita identificar que atividades são executadas por cada papel, e a partir disso identificar quais são as habilidades, competências e nível de autoridade requerido na execução de cada etapa do trabalho.

 

3. Quando o foco é tornar explícitas as interações do cliente com a organização através do processo 

Neste caso, o uso de pools e lanes traz uma camada de informação visual adicional importante, que é a da comunicação entre o processo da organização e o processo do cliente. É possível não apenas identificar onde estão os “momentos da verdade” em que o cliente interage com a organização, mas também com quem e por quê ele faz essas interações.

Esta abordagem é ideal em projetos de transformação que têm como objetivo alinhar o negócio ao foco do cliente, possibilitando compreender a sua experiência atual.

 

Todas essas abordagens são possíveis dentro da utilização da notação BPMN conforme as suas regras – portanto não existe certo e errado.

O melhor caminho é, em primeiro lugar, ter claro qual o propósito da modelagem que estamos realizando e então definir a melhor estratégia de uso da notação!


Definindo a equipe nos projetos de BPM

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

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

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

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

MODELAGEM DE PROCESSOS

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

ANÁLISE DE PROCESSOS

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

REDESENHO DE PROCESSOS

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

AUTOMAÇÃO DE PROCESSOS

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

OUTROS PAPÉIS IMPORTANTES NO GERENCIAMENTO POR PROCESSOS

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

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

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

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

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