Nova agenda de cursos RPA 2019

Nós da iProcess estamos muito empolgados com a tecnologia RPA (Robotic Process Automation) e se você já nos acompanha aqui no Blog ou em nossas redes sociais ( Facebook, LinkedIn, Twitter, YouTube) sabe que compartilhamos nossa experiência com RPA de diversas formas.

Isto acontece pois temos um portfólio completo de serviços para cobrir toda a sua jornada, da descoberta de processos à automação e somos representantes das duas principais plataformas de automação do mercado: UiPath e a Automation Anywhere.

 

 

 

 

Então hoje vamos compartilhar nossa nova agenda de cursos de RPA que vai rodar novamente o Brasil com turmas em algumas das principais cidades:

  • De 23/10 a 24/10  |  Manhã e Tarde  |  São Paulo/SP
  • De 30/10 a 31/10  |  Manhã e Tarde  |  Salvador/BA
  • De 05/11 a 06/11  |  Manhã e Tarde  |  Curitiba/PR
  • De 12/11 a 13/11  |  Manhã e Tarde  |  Porto Alegre/RS
  • De 04/12 a 05/12  |  Manhã e Tarde  |  Belo Horizonte/MG
  • De 18/12 a 19/12  |  Manhã e Tarde  |  Brasília/DF

Conheça o programa completo do curso acessando nosso site da iProcess Education no link da imagem abaixo:

Como escolher o primeiro processo de robotização?

E a nossa série de vídeos no canal do YouTube da iProcess continua!

E para você não perder nenhuma novidade, acesse o canal YouTube iProcess, inscreva-se e ative as notificações.

No vídeo anterior, realizamos o webinar: O que é um CoE RPA e porque muito em breve você vai precisar de um. Nele mostramos a necessidade de termos definições claras de governança e quais os principais processos e padrões que a sua empresa precisa estabelecer para viabilizar o crescimento das suas iniciativas de robotização.

Mas caso você esteja iniciando nesta jornada de robotização em sua empresa, a primeira pergunta que você deve fazer é:

Qual processo eu devo escolher para robotizar?

Neste vídeo vamos te ajudar a escolher os processos ideias para liderarem as iniciativas das primeiras robotizações.

Gostou deste vídeo?

Esta e outras discussões sobre a adoção da força de trabalho digital são parte do curso RPA do Planejamento à Gestão: Como implantar uma força de trabalho digital, da iProcess Education.

Confira as próximas turmas e inscreva-se!

E não esqueça de se cadastrar no mailing do blog para receber todas as novidade.

Modelos de Gestão do CoE RPA

Conforme exploramos em um webinar recente sobre CoE RPA, o investimento em robotização comumente inicia com uma experimentação, onde a organização desenvolve e experimenta o primeiro robô.

Como os resultados com ganhos de tempo e liberação de força de trabalho humana em atividades repetitivas são imediatamente percebidas e mensuráveis, o primeiro robô costuma ser a porta de entrada para o crescimento da iniciativa.

Em pouco tempo a iniciativa de robotização tende a se expandir para outras atividades e áreas. Nestes projetos iniciais, começamos a identificar características que devem se transformar em políticas e padrões internos, como os métodos de avaliar se uma tarefa é realmente robotizável, que tecnologias serão usadas, quanto trabalho leva para fazer, como formalizar o entendimento do trabalho do robô, as ações de monitoramento e o gerenciamento de riscos operacionais.

Assim, nos primeiros projetos, entendemos como a iniciativa se encaixa dentro da cultura e visão de aplicação desta tecnologia na organização e uma estrutura mínima de governança começa a ser estabelecida.

Este passo é bem importante para que a equipe envolvida comece a estruturar um centro de governança (ou Centro de Excelência – CoE) antes que o RPA se popularize demais e a organização perca controle sobre seus robôs, expondo a atividade do negócio a sérios riscos operacionais.

O CoE (Center of Excellence) é a estrutura organizacional responsável por realizar a gestão e governança da adoção do trabalhador digital dentro da organização, definindo e garantindo a execução dos processos de:

  • Descobrir e priorizar novas demandas;
  • Implementar tarefas robotizadas;
  • Monitorar a execução do trabalho robotizado;
  • Sustentar a operação robótica.

Se o modelo de gestão do CoE RPA será uma estrutura centralizada ou decentralizada na organização, depende de diversos fatores. Os principais são: a maturidade da organização com tecnologias de robotização e de transformação digital, a cultura organizacional, a visão de futuro e os planos de sustentação. Em alguns casos, a distribuição física de matriz/unidades também pode influenciar nesta decisão.

Vamos discutir três modelos, seus benefícios e pontos de atenção.

CoE RPA Distribuído

O modelo de CoE distribuído/descentralizado tem seus recursos distribuídos nas unidades de negócio da organização.

Os processos de descobrir e priorizar novas demandas, implementar tarefas robotizadas, monitorar e sustentar são executadas pelas unidades de negócios separadamente.

Prós:

  • Aumenta a capacidade de executar projetos de automação, já que cada área poderá estabelecer suas prioridades e avançar com seus projetos.
  • Possibilita às equipes criar soluções personalizadas com a proximidade com a operação do negócio.
  • O gerenciamento dos custos é simplificado, já que custos e recursos robóticos são específicos de cada unidade.

Cons:

  • Requer capacitar mais pessoas para se atuar nos diferentes papeis dos projetos de robotização.
  • O conhecimento e experiência obtidos pelos projetos de cada equipe acabam ficando muito concentrados.
  • Requer um esforço maior na garantia da aplicação dos padrões organizacionais
  • Tende a obter níveis de maturidade diferentes entre os times.
  • Há uma menor otimização de recursos robóticos, uma vez que um time pode ter tarefas demais a automatizar mas precisa restringir aos robôs disponíveis para seu time enquanto outra área não evoluiu muito na robotização e tem recursos subutilizados.

CoE RPA Centralizado

O modelo de CoE centralizado reúne todos os recursos para conduzir a automação RPA para a organização em um time integrado.

Os processos de descobrir e priorizar novas demandas, implementar tarefas robotizadas, monitorar e sustentar são executadas por uma equipe dedicada e especializada.

Prós:

  • A centralização de expertise permite que o time aprenda e desenvolva novas habilidades a partir das experiências dos diversos projetos.
  • Potencializa o ganho de escalabilidade na utilização da força de trabalho robótica.
  • Otimiza de recursos técnicos nos diferentes projetos de robotização.
  • Otimiza de recursos robóticos, possibilitando que um robô possa ter sua agenda de trabalho ocupada com atividades de diferentes unidades de negócio.
  • Possibilita maior gestão e padronização dos processos.
  • Possibilita melhor garantia da aplicação dos processos.
  • Uso de plataforma compartilhada.

Cons:

  • A expansão da iniciativa de processos pode ser mais lenta uma vez que o time está concentrado em um conjunto limitado de projetos de automação.
  • As unidades precisam concorrer pela priorização de seus projetos (como comumente acontece hoje com projetos de TI).
  • Os projetos tendem a apresentar maior esforço para alocação de recursos de negócio.

CoE RPA Híbrido

No espectro entre a gestão da força de trabalho digital centralizada ou distribuída, podem haver tons intermediários que combinam aspectos dos dois modelos  para melhor atender às necessidades e características da organização.

Estas definições podem influenciar a definição de papéis, processos e recursos.

Alguns exemplos:

  • COE Centralizado reúne periodicamente aprendizados para evoluir processos
    mas ciclo de vida da robotização é aplicada de forma distribuída nas unidades de negócio.
  • Processo de descoberta e análise da demanda é realizado pelas unidades, com implementação pelo CoE centralizado.
  • Processo de implementação pelo CoE centralizado mas monitoramento e
    sustentação providos pela unidade de negócio.

A decisão sobre o modelo de gestão, o estabelecimento de processos, papéis e recursos é uma importante reflexão que precisa estar no roadmap da organização que inicia sua jornada na adoção da força de trabalho digital e precisa ser iniciada tão logo as primeiras experiências de robotização comecem a acontecer.

Gostou deste artigo?

Esta e outras discussões sobre a adoção da força de trabalho digital são parte do curso RPA do Planejamento à Gestão: Como implantar uma força de trabalho digital, da iProcess Education. Confira as próximas turmas e inscreva-se!

 

 

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/

 

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.

 

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 sobre o valor a ser entregue pelo processo, expectativas de custo e qualidade
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. :-)