Convite para Evento: Roadshow sobre Força de Trabalho Digital (RPA) na região sul e sudeste

Após o sucesso do primeiro evento sobre Força de Trabalho Digital realizada em São Paulo em abril, o grande número de downloads do nosso e-book sobre RPA e do grande interesse no Webinar sobre Robotização, a iProcess atende a pedidos e lança um Roadshow sobre Força de Trabalho Digital na região sul e sudeste.

O evento será gratuíto com vagas limitadas e irá abordar, entre outros temas:

  • O que são trabalhadores digitais e quais os benefícios de sua adoção;
  • Como as tecnologias estão evoluindo para levar mais autonomia e inteligência aos robôs;
  • Quais os principais desafios nos projetos de robotização;
  • Qual a relação entre BPM e RPA,
  • Entre outros assuntos!

 

O Roadshow será realizado em 5 cidades no turno da manhã conforme programação abaixo:

  • 22/05 em Caxias do Sul (RS)
  • 23/05 em Porto Alegre (RS)
  • 24/05 em Curitiba (PR)
  • 25/05 em Joinville (SC)
  • 13/06 em São Paulo (SP)

Não perca esta oportunidade única de discutir um tema tão importante e impactante para as organizações com o time da iProcess. 

Vagas limitadas. Inscreva-se já:

 

Como as Capacidades Robóticas irão impactar o seu trabalho nos próximos anos

O tema da Robotização tem gerado um interesse intenso das organizações nos últimos meses. Com a promessa de ser uma solução efetiva na busca pela eficiência, o uso da capacidades robóticas também podem ser uma iniciativa inteligente e rápida para a implementação de projetos de transformação digital.

Segundo um  estudo da McKinsey, cerca de 30% das tarefas executadas hoje por pessoas podem ser reproduzidas por robôs! O elevado número de tarefas repetitivas com alto potencial de automação traz para as organizações uma oportunidade única de implementar iniciativas com elevado retorno de investimento e aumento de eficiência em suas operações.

Para explorar estas e outras questões e mostrar que já existem tecnologias e práticas de adoção do trabalhador digital que a iProcess fez o seu primeiro Webinar sobre Robotização!

Se você quer saber mais sobre o assunto, não deixe de baixar o nosso e-book sobre RPA e conhecer o nosso novo treinamento “Do Planejamento à Implantação: Como Implantar uma Força de Trabalho Digital”.

E, em breve, inscreva-se no nosso Roadshow sobre Capacidades Robóticas que acontecerá em diversas cidades da região sul e sudeste.

 

Newsletter do blog da iProcess traz conteúdo exclusivo sobre Gestão por Processos

Como mais de 40.000 acessos por mês, o blog da iProcess tem se firmado cada dia mais como uma importante fonte de conhecimento sobre BPM & RPA.

Pensando em oferecer um serviço cada vez melhor, a iProcess está lançando a sua newsletter mensal, que levará um resumo de tudo o que foi publicado e do que está por vir direto para o seu email

Além disso, os assinantes do nosso blog terão acesso a conteúdos exclusivos sobre conteúdos publicados pela iProcess e saberão das novidades em primeira mão.

Não perca tempo, assine o blog da iProcess e tenha muito conteúdo e informação sobre processos direto na sua mão.

Para assinar, basta clicar no banner publicado em nossos artigos.

Superando os Desafios do Primeiro Projeto de Automação

O sucesso do primeiro projeto de automação de processos de uma organização depende de inúmeros fatores, que vão desde a escolha adequada do processo a ser automatizado até o impacto que o redesenho tecnológico do processo e a receptividade das área envolvidas no uso da nova tecnologia.

Com 18 anos de experiência em automação de processos, a iProcess apresentou neste webinar  os principais desafios e lições aprendidas para superar as dificuldades da primeira automação de processos de uma organização.

 

Assine a lista do blog da iProcess para receber mensalmente informações sobre tudo o que foi publicado no nosso blog e o que tem por vir por ai!

Processos, Pessoas e Transformação Digital

O que será que acontece quando colocamos, numa mesma mesa, um especialista em Processos, outro em Internet das coisas e um terceiro em coach pessoal e profissional?

Como o avanço da tecnologia irá impactar a vida das pessoas? Como processos e tecnologias podem se integrar? Como “coisas”, processos e pessoas trabalharão juntas? Como ficam as pessoas diante de um cenário de profunda de transformação?

Estes entre outros assuntos são discutidos  no programa de rádio #Inovação, conduzido Debora Vilella, que entrevista Eduardo Britto, Diretor da iProcess e especialista em Gestão por Processos; Giovanni Comunello, CEO da iTinvent e especialista em Internet das Coisas (IOT) e Ana Paula Thiesen, Diretora da Insight Desenvolvimento e  Master Coach Pessoal & Profissional.

E se você deseja se preparar para liderar a transformação digital na sua organização, conheça o curso de TRANSFORMAÇÃO DIGITAL ORIENTADA A PROCESSOS,

um programa de treinamento à distância criado para formar os profissionais que conduzirão as organizações para transformar os seus processos com o uso da tecnologia, aliando inovação a eficiência.

Inscreva-se na lista de contatos da iProcess para receber notícias sobre cursos, treinamentos, novas publicações no blog e datas dos próximos webinares! Basta preencher o formulário de contato no site da iProcess: http://www.iprocess.com.br/contato

 

Avaliação de Produtos: Oracle Process Cloud Services (Oracle PCS)

No mercado de automação de processos há mais de 20 anos, a Oracle acaba de lançar uma solução para automação de processos simples, leve e que roda em ambiente na nuvem: o Oracle Process Cloud Service, ou Oracle PCS.
Com o foco na automação de processos, o produto possui recursos interessantes para a modelagem e execução de processos, todos disponibilizados em um ambiente simples de boa usabilidade que permitem tanto o usuário de negócios com a área de TI realizarem a automação de seus processos.

 

Na lista abaixo analisamos como a plataforma atende a alguns dos principais requisitos de BPMS:
  • Modelagem com BPMN: Possui suporte tanto a nível de modelagem como a nível de implementação e execução de grande parte dos recursos oferecidos pela notação BPMN.

    Modelagem do processo com BPMN

  • Modelagem de Formulários: Com o uso da tecnologia Webforms, permite o desenvolvimento de formulários em ambiente visual de forma fácil e rápida com os recursos de arrastar e soltar. É possível definir um formulário para cada atividade ou reaproveitar um mesmo formulário em várias atividades, agilizando o desenvolvimento da automação.

    Editor de formulário visual (WYSIWYG)

  • Regras de Negócio em Formulários: Possui uma linguagem nativa de script que manipulam as propriedades dos elementos dos formulários. A linguagem permite a configuração de regras de negócio básicas e avançadas, mas de acordo com o que se deseja fazer, um conhecimento e familiaridade com programação começa a se fazer necessário.
  • Integração com Sistemas: Possui nativamente a chamada de serviços. Contudo, como o ambiente está em ambiente cloud e não existe hoje formas de se estabelecer uma VPN ou um túnel privado com o cliente, faz-se necessário que os serviços estejam disponíveis em ambiente público na web.

    Configuração de acionamento de serviços pelo processo

  • Orquestração de Sistemas: Apesar de não ter recursos mais poderosos para a implementação de processos de natureza sistêmica, o PCS se integra naturalmente com outro produto da Oracle chamado ICS – Integration Cloud Service – que permite a configuração de um barramento de serviços em ambiente de nuvem, facilitando a orquestração deste tipo de necessidade.
  • Gestão de Conteúdo: De forma similar como resolve as necessidades de processos sistêmicos, o PCS se integra de forma nativa com o Oracle Documents, plataforma de gestão de documentos na nuvem da Oracle que permite o compartilhamento, colaboração, visualização, controle de versão e trâmite dos documentos ao longo dos processos.
  • Motor de Regras: Possui um ambiente próprio para a configuração de regras de negócio que são consumidas por atividades do processo através da configuração de tabelas de decisão.

    Criação de Regras de Negócio

  • Ambiente de Execução: Bastante prático e funcional, possui uma lista de trabalho onde são executadas as atividades humanas. Permite a criação de filtro para a seleção de atividades e a consulta de onde está um determinado processo e qual o seu histórico de execução.

    Ambiente de execução do processo

  • Mobile: Possui aplicativo próprio para iOS eAndroid para a execução de processos em ambiente mobile.
  • Indicadores e Relatórios: Disponibiliza uma série de relatórios e dashboards pré-prontos que permitem o acompanhamento de qualquer processo modelado na plataforma. Contudo, possui nativamente poucos recursos de customização destes indicadores.

    Indicadores e relatórios do Oracle PCS

Nesta solução de BPM, a Oracle provê todo o ambiente e infraestrutura do produto, tendo um modelo de licenciamento baseado na compra de créditos que podem ser utilizados o licenciamento por usuário, com valores distintos de acordo com o tipo de usuário: Administrador, Participante e Invocador.

 

Na avaliação da iProcess…

… o Oracle PCS chega como um bom produto para a implementação de processo de baixa e média complexidade, sendo uma plataforma bastante produtiva para o desenvolvimento dos processos a que se propõem e tendo um bom custo x benefício para empresas que querem rapidamente implementar muitos processos com predominância de atividades humanas na sua organização.
É uma solução de rápida adoção, visto que podem ser adquiridos poucos usuários a um custo acessível e que o ambiente em algumas horas já estará disponível para as áreas de Ti e negócios dada a facilidade da automação na nuvem.
Como pontos a melhorar está a necessidade dos serviços do cliente terem que estar expostos na web para serem evocados e pouca customização de relatórios e indicadores.

 

Para conhecer um pouco mais do Oracle PCS, assista aos vídeos abaixo.

 

Vídeo 1: Os benefícios da automação de processos com o Oracle Process Cloud Services

Vídeo 2: Demonstração de utilização do Oracle Process Cloud Services

Para mais informações, fale com a iProcess ou entre em contato com a gente no email contato@iprocess.com.br.

10 pontos chave a considerar na hora de estimar um projeto com BPMS

Com um largo know-how em automação de processos e já tendo realizado algumas centenas de implementações nas mais diversas ferramentas, a estimativa de esforço para a automação de um processo é quase que uma prática diária na iProcess.

Como somos muito questionados sobre como fazemos isso, e neste artigo indicamos algumas diretrizes para auxiliar nossos clientes a fazer avaliar a sua estimativa.

1. Estimativa de implementação é somente uma parte da Estimativa do Projeto

Falaremos neste artigo sobre o esforço direto de um programador para pegar um processo desenhado e detalhado funcionalmente e implementa-lo em uma ferramenta de BPMS. Contudo, isso costuma ser menos da metade do esforço de um projeto!
Um projeto de automação bem elaborado precisa que se faça o levantamento do processo, sua modelagem para automação, projeto técnico, roteiro de testes, preparação de dados de sistemas legados, execução e ajustes da sua validação, homologação com o usuário, elaboração de documentação, elaboração de planos de instalação, instalação em ambiente de homologação e produção, acompanhamento em produção, suporte dos primeiros dias, gerência de projeto, gerência de configuração, gestão de requisitos, entre outros!
Evidentemente que tudo isso é um mundo a parte, e dependerá das características do processo, da cultura da organização e do seu processo de desenvolvimento. Contudo, são atividades que não podem ser desprezadas, pois garante a qualidade do resultado da entrega da automação.

2. Estimativa de Processos não é Estimativa de Software

A estimativa de software convencional utiliza métodos como Pontos de função (PF) ou Unidades de Casos de Uso (UCP) para realizar a estimativa de esforço. São técnicas que utilizam como referência a complexidade da interface de usuário. Na automação de processos é diferente, pois a complexidade está ligada diretamente aos elementos BPMN que compõem o seu processo e a complexidade em implementá-los​ no BPMS adotado​. Logo, estas técnicas não tem aplicação direta para estimar esforço de automação de processos.

3. Você deve conhecer o seu processo (ou projetar como ele deveria ser)

Não tem jeito: você não tem como estimar um processo que você não​ o​ conhece. O esforço de implementação de um processo está ligado diretamente às suas características, elementos necessários e respectivas complexidades. Logo, você precisará levantar o processo.
Caso não haja esta possibilidade, você deverá inferir esta complexidade e assumir o risco no momento da automação de ter que realizar ajustes para mais ou para menos.

4. Cada ferramenta de automação possui uma produtividade diferente

Não existe um número mágico que traga o esforço de implementação de um processo em todas as ferramentas. Cada ferramenta possui suas peculiaridades: algumas são mais produtivas, outras são mais completas e outras são mais complexas. Em algumas uma atividade humana é feita com muita facilidade, mas uma integração com um webservice ou um banco de dados dá muito trabalho.
Por isso, você deve antes de mais nada escolher a ferramenta em que será feita a automação para somente depois avaliar o seu esforço.

5. Identifique o modelo de dados do Processo

O que diferencia uma instância de processo de outra em execução são os dados em que elas manipulam. Cada processo tem atrelado a si um modelo de dados específico, que determina quais informações são manipuladas, incluídas ou consultadas ao longo do processo.
A complexidade do modelo de dados de um processo está ligado diretamente ao número de informações que são manipuladas e as suas características: se existem dados mestre-detalhe, se é feita a manipulação de arquivos, entre outros fatores.
A estimativa de esforço deve levar em consideração este montante e complexidade para projetar o esforço de manipulação destas informações ao longo do processo.

6. Identifique os elementos de processo que são implementados na sua ferramenta

O esforço de automação de um processo está ligado diretamente aos elementos que ele possui. Um processo com 2 atividades humanas e 2 gateways tende a ser 4x mais rápido de ser desenvolvido do que um processo com 8 atividades humanas e 8 gateways por exemplo.
A estimativa de automação de processos está ligada diretamente ao número de elementos que o seu processo possui, e é por isso que você deve conhecê-lo para poder estimá-lo.

7. Identifique os fatores de complexidade de cada elemento

Contudo, somente identificar os elementos não é o suficiente, pois um mesmo elemento pode ter uma implementação fácil ou complexa. Por exemplo, você pode ter
um gateway que somente testa se na atividade anterior houve uma aprovação ou reprovação (simples) ou um gateway que valida uma complexa regra de negócio;
Uma integração que passa o número do CNPJ e recebe o nome do cliente ou o cadastro de uma nota fiscal ​e seus itens ​em um ERP;
Uma atividade humana que informa ao solicitante que seu pedido chegará em 20 dias ou uma atividade distribuída para o ator mais produtivo entre uma série​,​ que possui um SLA rígido, controle de prazos e alertas e escalonamento caso a mesma não seja realizada em até 3 dias úteis antes do prazo final do processo.
Para mapear estas condições, você deve criar critérios de complexidade e atribuir um esforço para cada nível de complexidade.

8. Classifique o seu processo de acordo com estes fatores

Uma vez entendido os fatores para a projeção de complexidade de implementação de um processo, o processo escolhido deverá ser classificado: seus elementos contados, a complexidade de cada elemento avaliada e o esforço da sua implementação calculado.

9. O desenvolvimento das telas das atividades são parte significativa do esforço

​Mesmo com estes cuidados, as coisas não são tão fáceis como parecem, e apesar de estarmos falando de desenvolvimento de processos, eles possuem um componente importante chamado de interface de usuário das atividades humanas.
Na iProcess estimamos que o desenvolvimento de interfaces exige em média um esforço de 40% a 70% do esforço de desenvolvimento de um processo e depende muito dos recursos visuais e da linguagem de programação que cada ferramenta disponibiliza para a implementação das suas interfaces.
Existem soluções de BPMS cuja interface é “engessada” (no sentido que você define poucas coisas em termos de layout e comportamentos) enquanto que outras você pode fazer tudo o que qualquer linguagem moderna de programação web permite.
Por isso, você deve também mapear a complexidade de desenvolver cada interface e realizar uma contagem exclusiva para as mesmas.

10. Elabore uma planilha para calcular o esforço

Se você chegou até aqui, deve ter visto que são muitas variáveis e informações a serem consideradas. Em processos de complexidade média ou alta, com dezenas de atividades e subprocessos, levantar e calcular todas estas informações à mão torna-se quase impossível.
Logo, sugerimos que você elabore uma planilha com todos estes cálculos e utilize-a como ferramenta para realizar a estimativa do seu processo.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Desafios de Projetos: Mapeamento Conduzidos por Facilitadores das próprias Áreas de Negócio

Dando andamento ao assunto apresentado no artigo Vale a Pena Mapear Todos os Processos da Organização? gostaríamos de falar um pouco sobre uma iniciativa que tem aparecido como alternativa para as empresas que desejam mapear os seus processos sem a necessidade de realizar um investimento pesado em consultoria: a busca pela capacitação dos lideres funcionais de suas área de negócio com o objetivo de habilitá-los ao mapeamento de seus processos!

Não há dúvidas que esta abordagem tem um apelo bastante interessante sob vários aspectos, pois ela consegue com uma única iniciativa não só capacitar seus principais recursos como também economizar algumas centenas ou milhares de horas de consultoria com o uso da sua própria força de trabalho. Além disso, ninguém melhor do que os colaboradores das próprias áreas de negócio para saber quem deve ou não ser entrevistado, se o processo foi todo mapeado e se as informações que estão ali documentadas correspondem à realidade. Para completar, o projeto desta natureza tende a se tornar bastante ágil dado o paralelismo que podemos alcançar ao capacitar um recurso de cada área de negócio.

Mas nem tudo são flores, e este tipo de iniciativa está coberto de uma série de desafios muitas vezes desconhecidos ou ignorados pelos seus gestores. Longe de serem fatores de impedimento, tais desafios representam riscos significativos para o sucesso deste tipo de projeto, e se não forem corretamente mitigados, podem levar à perda de toda a iniciativa de processos dentro da organização. Confira a seguir alguns destes pontos de atenção:

  1. Capacitar as áreas de Negócio nas ferramentas e habilidades do mapeamento de processos: Este aqui é um dos maiores riscos deste tipo de projeto. Na maioria das vezes, vemos as empresas preocupadas em capacitar os seus colaboradores no uso das ferramentas e notações para o mapeamento de processos. Contudo, fazendo uma analogia, muitas vezes esquecemos que saber escrever é bastante diferente de saber redigir: uma pessoa que sabe escrever não tem, necessariamente, a habilidade de fazer uma redação. Na escola, levamos um ano aprendendo a escrever e passamos outros 8 anos aprendendo a redigir! A mesma situação ocorre com o mapeamento de processos: O aprendizado de uma notação não garante que este colaborador saberá expressar adequadamente a realidade dos processos de negócio. Assim, tão ou mais importante que o treinamento sobre a notação ou ferramenta deverá ser o treinamento das habilidades necessárias para que o colaborador possa expressar corretamente o seu processo de negócio!
  2. Garantir que todos os envolvidos descreverão os processos num mesmo nível de detalhe: Apesar de muito semelhante à questão anterior, este tópico merece uma atenção especial por ser complementar às habilidades necessárias. Mesmo em situações em que toda a equipe está capacitada para o mapeamento de processos, faz-se necessário garantir que todos irão documentar os seus processos no nível de detalhes esperado pelo projeto. Se tal preocupação já é fundamental com uma equipe de analistas de processos “profissionais”, torna-se ainda mais importante quando capacitamos uma série de pessoas com experiências profissionais e acadêmicas distintas que não estão habituadas a fazer este tipo de trabalho. O exemplo abaixo demonstra um pouco do que queremos dizer: o mesmo processo, documentado em níveis de detalhe diferentes.
  3. Evitar que as discordâncias do dia-a-dia de trabalho atrapalhem o mapeamento: À medida que envolvemos pessoas que estão inseridas dentro do próprio processo, é muito provável que este ganho de conhecimento seja acompanhando do que chamamos de perda da isenção. Esta perda pode se refletir de duas formas. A primeira está no risco do facilitador mapear uma única visão do processo, considerada por ele correta, em detrimento a outras visões. E a segunda é o risco de que conflitos históricos entre os envolvidos no processo apareçam de forma negativa, prejudicando ou inviabilizando o trabalho. Estas situações obviamente podem também aparecer com um facilitador externo ao processo, mas este costuma ter mais flexibilidade ao gerenciá-las à medida que esta pessoa está isenta do dia-a-dia e dos problemas do processo.
  4. Avaliar como será feito o mapeamento intra-departamental: Dada a natureza transversal dos processos, é natural que um determinado processo passe por diferentes áreas de negócio. Nesse sentido, deve-se evitar que a escolha de facilitadores por área de negócio acabe hierarquizando o processo de acordo com o organograma da organização. Para evitar estas situações, sugere-se adotar inicialmente uma abordagem top-down de mapeamento, de modo a identificar desde o início as áreas envolvidas, os responsáveis por cada etapa e como ocorrerá a unificação deste trabalho. Ou, numa outra abordagem, pode-se também delegar a um único facilitador a responsabilidade por mapear todo o processo, independente das áreas em que ele passe, mesmo que para isso ele tenha que contar com o apoio dos facilitadores de cada área de negócio envolvida.
  5. Garantir disponibilidade para o trabalho: Este é outro típico desafio de qualquer projeto de modelagem, mas que torna-se mais crítico quando os próprios usuários é que mapeiam os seus processos. Se muitas vezes já é difícil arranjar tempo para que os colaboradores descrevam o seu processo para um consultor externo, quem dirá em situações em que este consultor é um colega de trabalho! Neste quesito é importante que os gestores de cada área de negócio entendam a importância da iniciativa de mapeamento e se comprometam a exigir um prazo da sua equipe para evitar que este trabalho entre num ciclo de postergação infinita.
  6. Evitar que informações deixem de ser mapeadas: O que pode ser considerado um dos grandes benefícios do mapeamento de processos ser realizado por alguém de fora da área de negócio, na abordagem interna pode tornar-se um dos principais riscos: o de que, tendo a própria área de negócio o controle do que será ou não documentado, a mesma só represente no processo aquilo que, a seu critério, não compromete a análise sobre o seu desempenho. Para minimizar esta possibilidade é fundamental que a organização comunique claramente aos os seus colaboradores que o mapeamento não tem por objetivo achar culpados, mas sim alcançar o auto-conhecimento de modo que ela possa buscar maior eficiência e eficácia nas operações.
  7. Escolher adequadamente os Facilitadores: Para minimizar alguns dos desafios apresentados, a escolha adequada dos facilitadores de cada área de negócio é fundamental. Neste quesito, critérios como o conhecimento sobre o negócio tendem a ficar em segundo plano se comparados à capacidade de ouvir e negociar do facilitador. De igual importância deverá estar a habilidade deste facilitador em mapear estes processos, pois de nada adiantará um facilitador que entenda como o processo é feito e que não tenha habilidade de documentá-lo. Neste sentido, se desejável, uma boa prova pós treinamento é de grande valia para mitigar este risco.

Apesar dos inúmeros desafios, este artigo busca trazer à tona questões que devem ser acompanhadas por aqueles que buscam nesta forma de trabalho o sucesso para o mapeamento e documentação de seus processos de negócio.

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