The BPM Experience

Por Maurício A. Santos, ProcessMind

A pergunta pode até parecer um pouco estranha, mas considero que é uma das mais importantes ao se iniciar um trabalho de análise de processos. É comum encontrarmos documentação detalhada de um processo mas que, na prática, continua com diversos problemas de padronização, falta de controle, gargalos, retrabalhos etc etc etc. Muitas vezes é mais crítico termos um bom plano de ação para implementação de melhorias no processo do que ter sua documentação detalhada até o nível de atividades e tarefas.

Não que o mapeamento de um processo não seja importante, mas antes de se começar a análise do processo devemos fazer algumas perguntas como:

- Qual o objetivo do mapeamento?
- O que eu espero ao final do mapeamento?
- Como a documentação será utilizada?
- Quem é o cliente do trabalho de mapeamento e o que ele deseja?

Algumas respostas e o conseqüente nível de detalhamento necessário dos processos que encontramos em nossos trabalhos são os seguintes:

1. Objetivo = Implantar melhorias e controlar o desempenho do processo

Neste caso, um bom mapeamento gerencial do processo é suficiente, procurando identificar quem são os clientes do processo, quais suas necessidades e como está o desempenho do processo. Algumas reuniões com os usuários são suficientes para se levantar as oportunidades para melhorar o processo, bem como quais devem ser os indicadores necessários para medir o desempenho do processo. Dedica-se então maior tempo no detalhamento dos planos de ação para implementar estas melhorias. Os fluxos de atividades, neste caso, não são necessários ao trabalho.

2. Objetivo = Definir responsabilidades no processo e as interfaces entre os participantes

Neste caso, já será necessário entender as regras de trabalho e de execução do processo. É necessário, entretanto, desenhar uma visão macro do fluxo de atividades do processo (sem muitos detalhes), a fim de identificar quando e quais informações são passadas de um participante para o próximo. Porém, não é necessário detalhar estas atividades (em tarefas), o que só vai fazer o trabalho demorar mais para acabar e os resultados serão os mesmos no final.

3. Objetivo = Automatizar o processo e implementar ferramenta de BPMS

Neste caso, o nível de detalhamento deverá ser bem maior, principalmente para se levantar todos os dados do processo, bem como as regras para execução de cada atividade. Quase sempre, porém, não será necessário mapear as tarefas do processo, pois o BPMS será utilizado somente para automatizar as atividades.

4. Objetivo = Treinar novos usuários e/ou escrever instruções de trabalho

Neste caso sim, será necessário descer o nível de detalhamento do processo o máximo possível, para que a documentação gerada seja uma eficiente ferramenta de treinamento das pessoas. Este nível de detalhamento é comum para processos mais operacionais, com alta repetição, nos quais a padronização é essencial para se garantir a qualidade do trabalho.

Outros exemplos podem ser dados a cada projeto que participamos. O importante é ter consciência de que não adianta sair elaborando extensa documentação do processo (AS IS e TO BE) em todo e qualquer projeto de análise de processos, sob o risco de se gastar tempo e dinheiro e não alcançar os resultados esperados. Infelizmente, vemos isso acontecer com freqüência, o que acaba inviabilizando até a continuidade do trabalho de processos nas empresas.

Lembre-se: o que se procura normalmente é a melhoria do processo e não sua documentação!!!

Bom trabalho.

• An Insider’s View of BPMN 2.0
  by Bruce Silver on BPMS Watch
• Which comes first: process or service? Part 1
  by Neil Macehiter and Neil Ward-Dutton on ebizQ
• Which comes first: process or service? Part 2
  by Neil Macehiter and Neil Ward-Dutton on ebizQ

• Which Way for BPMN 2.0?
  by Bruce Silver on BPMS Watch
• Creativity Management – The New Challenge for BPM
  by Stefan Seidel and Michael Rosemann on BPTrends
• SAPPHIRE: Perfectly Ordinary BPM
  by Sandy Kemsley on Column 2

A primeira edição do BPM Forum Day, um encontro presencial dos membros do grupo de discussão virtual BPM Forum, será realizada na manhã da quarta-feira, dia 30/04/2008, em São Paulo.

Será um evento informal e com muita discussão. Teremos duas palestras de 45 minutos cada (30 minutos reservados para apresentação e 15 minutos para debate), além de um painel de debate sobre o tema BPM vs. SOA.

(more…)

Por Maurício A. Santos, ProcessMind

Mais do que concorrentes, a gestão da qualidade e a gestão de processos são disciplinas complementares que, se bem conduzidas, podem levar a organização a alcançar elevados patamares de produtividade e eficácia.

Em alguns casos até, as duas disciplinas tem sido gerenciadas como uma atividade única, uma vez que ambas tem o mesmo objetivo: a melhoria da performance empresarial a partir da melhoria de seus processos, tornando a administração dos negócios mais transparente e auxiliando na tomada de decisão e gestão corporativa.

(more…)

• Looking for Essential Business Entities
  by Martyn Ould on Riva Method
• Human Processes: Ruling Unruly Rules
  by Keith Harrison Broninski on BPTrends
• O Mais Importante são as Pessoas
  by Rafael Bortolini on BPM Hoje

• Respect for People
  by James P. Womack on BPTrends
• Don’t give customers what they think they want
  by Steve Towers on Bennu Group
• Process Component Models: The Next Generation In Workflow?
  by Tom Baeyens on InfoQ

• Getting started on that process architecture
  by Martyn Ould on Riva Method
• Gartner Business Process Management Summit 2008 Coverage
  by Sandy Kemsley on Column 2
• Why are enterprise applications so dumb?
  by James Taylor on Enterprise Decision Management

• Don’t rely on taxonomies and definitions - use method
  by Martyn Ould on Riva Method
• Process architecture vs process mapping
  by Keith Harrison-Broninski on IT Directions
• The Interaction of Process Modeling with Process Execution
  by Jim Sinur on Jim Sinur’s BPM Blog

Por Luis Bender, ProcessMind

Um assunto que cada vez mais tem chamado minha atenção é a eficácia da automação de processos de razoável complexidade através da utilização de BPMSs de mercado. Ou seja, qual a aderência dos BPMSs às necessidades de automação dos processos de negócio reais das empresas. Não estou falando aqui do “processo de reembolso de despesas” ou similares que os fornecedores de BPMS utilizam para demonstrar seus produtos, mas sim de processos reais das empresas, com intensa participação humana, colaboração entre participantes, decisões complexas, diversas exceções (muitas delas imprevisíveis - é o mundo real), integrações com sistemas corporativos legados não orientados a serviços, etc.

Caso não haja compatibilidade entre a natureza do processo e a flexibilidade oferecida pelo BPMS, poucas serão as chances de sucesso da automação e grandes as chances dos participantes utilizarem intensamente meios alternativos para execução do processo (e-mail, planilhas, etc). É claro que existem muitos outros fatores que contribuem para o sucesso da automação de um processo, como a metodologia utilizada, o apoio da alta direção, etc, mas vamos nos ater no aspecto “flexibilidade requerida pelo processo vs. flexibilidade oferecida pelo BPMS”.

(more…)