Em meu recente blog “Programadores Java odeiam BPM” tinha a intenção de atiçar algumas pessoas e gerar uma boa discussão. E teve sucesso... Eu tive vários retornos e honestos (ex. “eu odeio email”).
Muitas pessoas disseram “Nós não vemos necessidade para ferramentas BPM.” ... e eu gostaria de falar sobre isto neste artigo.
Eu realmente não estou surpreso com a média de desenvolvedores Java que não vêem necessidade para o BPM... de fato eu não me surpreendo que o trabalhador médio em qualquer industria não vê necessidade para BPM.
Todos nós trabalhamos ativamente em processos de negócios. Todos nós interagimos com que participa do processo de negócios.
Quase todos nós participamos no processo de negócios. Nós não pensamos muito nisso porque geralmente não ligamos o que o processo completo é... E geralmente somente ligamos para as tarefas que temos que fazer em qualquer processo.
Por exemplo: Quando você solicita um Empréstimo você é participante no “Processo de origem do empréstimo”. Geralmente você não quer saber sobre todos os passos do processo. Você não quer saber de todas as tarefas que quem empresta tem que fazer. Você só se interessa pelo passo onde você preenche o formulário de pedido e o processo que você responde à decisão de quem empresta.
Quando desenvolvemos software somos participantes do “Processo de Desenvolvimento de Software”. Falando por mim mesmo, quando eu estou trabalhando no “modo Programador” eu não quero saber de todos os passos do processo. Eu só me interesso em entender todos os requisitos, escrever o código e corrigir os bugs que a área de QA encontra.
Meu Gerente de Projeto (GP) se preocupa com mais passos do desenvolvimento de software que eu. Gerentes de Projeto tem que coordenar as tarefas dos programadores e todo o resto no projeto. A maioria dos GPs que eu encontrei não pensa nos seus projetos como instâncias de um processo de desenvolvimento de software... Eles tendem a ver seus projetos como calendários, os quais explicam através dos gráficos Gant no Microsoft Projeto, e isso é tudo que eles precisam em termos de ferramenta de suporte.
Somente quando você tiver em um nível mais alto na organização, talvez um VP de desenvolvimento, você talvez encontre alguém que realmente se preocupe com todo o Processo de Desenvolvimento de Software. Se sua organização é grande o suficiente, o VP pode ser responsável por vários projetos rodando ao mesmo tempo com cada projeto em diferentes pontos no processo.
Enquanto todos os projetos da empresa estiverem completos dentro do prazo e dentro do orçamento, o seu VP provavelmente deixará o Processo de Desenvolvimento de Software de lado. Por uma estranha razão, todos os VP que eu trabalhei deixaram de lado o PDS.
VP de desenvolvimento trabalha no PDS para tentar reduzir os custos, para ter um calendário mais previsível e geralmente para deixar seu empregados loucos. Eles tentam fazer mais dinheiro. O VP de desenvolvimento médio gosta de encontrar problemas no processo, “melhorá-lo” e fazer tudo isso de novo.
A sua empresa tem muitos processos de negócios alem do Processo de Desenvolvimento de Software. Algum são realmente banais, alguns dos nossos processos críticos estão em ultimo lugar.
Todos os seus Executivos estão realmente interessados em gerenciar todos esses processos de negócios. Processos ineficientes geram maior custo, tanto em termo de gastos e perda de lucros, como em eficiência do processo.
Gerenciando um processo...
O primeiro passo no gerenciamento de um processo é saber o que realmente o processo é. Isto inclui os passos que são feitos pelas pessoas e os passos que são feitos pelas maquinas. Eu uma vez achei necessário reunir em uma sala diversas pessoas para encontrar o que cada um pensava como o processo era e então descobrir que o processo não era nada do que pensavam que era. Grandes empresas gostam de gastar dinheiro para diagramar seus processos... os quais eles arquivam por cinco anos até fazerem isso de novo.
O segundo passo em gerenciar processos é recolher métricas... Quanto tempo (em media) demora cada etapa do processo para ser executado? Quantas vezes os processos são repetidos ? (presumivelmente devido a erros)
O terceiro e quarto passo em gerenciar um processo é analisar e ativamente gerenciar o processo. Use as métricas que você recolheu para analisar a performance , desenvolver um processo melhor e testá-lo repetidamente. Isto é Melhoria Continua de Processos.
Todos os bons pacotes de BPM dispõem de uma infraestrutura de suporte para todos esses passos necessários.
Primeiro: Conheça o processo
No coração de todos os pacotes BPM está um “motor” de processos que executa definições de processos. Estas definições são usualmente representadas graficamente usando a notação BPMN. Os diagramas de processos são usualmente gerados em conjunto com as pessoas de negócios que são suas detentoras... Por favor note que é muito mais importante que as pessoas de negócios saibam “ler” o diagrama de processo que ser capaz de desenhá-lo. O “motor” de processos irá executar o diagrama, então se ele estiver errado, o processo estará errado.
Eu gusto de dizer que os processos são compostos por “Serviços Humanos” e “Serviços Autonomos”. A maioria dos pacotes BPM disponibiliza ferramentas que ajudam a construir “Serviços Humanos”. Essas ferramentas são basicamente editores de formulários, que são boas para fazer muitas tarefas orientadas a usuários, mas não significa que são usadas para desenhar interface de cliente sofisticadas... Todos os bons pacotes BPM provem interfaces que lhe permitem anexar a qualquer cliente que você deseje construir. Se você quiser uma aplicação Swing para executar uma tarefa, então você pode escrever uma aplicação Swing e anexa-la no processo. Se você quiser usar o NetBeans ou Eclipse para executar uma tarefa você pode fazer isso também.
BPM não é sobre trocar tudo nas aplicações que você usa. É sobre coordenar o uso dessas aplicações para executar um processo.
Mas de volta para saber o que o processo é... Você sabe o que o processo é porque você sempre pode vê-lo. A definição do processo não é espalhado entre vários aplicativos e tarefas escondidas. Está contida em uma única definição precisa.
Segundo: Obter métricas
Desde que o motor de processo está gerenciando o processo, o motor sabe quando cada tarefa é iniciada e finalizada. O motor sabe quem executa cada tarefa.
Isto torna incrivelmente fácil de medir um processo.
Terceiro: Analise o processo
Todos os bons pacotes BPM disponibilizam ferramentas para analisar todas essas métricas que você capturou. Os pacotes realmente bons deixam você usar até dados históricos para simular como uma mudança proposta em um processo seria executada no passado.
Quarto Modificar o processo
Com a analise em mãos, voce pode voltar e modificar o processo... Isto é realmente fácil, porque como você pode se lembrar, a definição do processo está em um só lugar.
Eu não posso deixar de enfatizar como é útil ter a definição do processo dirigindo todo o resto. Em essência, você tem uma visão centralizada no processo da sua base de código. Em meus dias pré-BPM eu me juntaria a um projeto e teria gasto semanas para rastrear o código que seria responsável por um comportamento especifico de um processo. Com a ferramenta BPM, você pode sempre iniciar com o diagrama de processo e descer para o código quando necessitar de mudanças.
Mas não posso eu mesmo colocar todos esses recursos num só lugar?
Com certeza voce pode! O que voce acha que os criadores do BPM fizeram ?
Pergunta errada.... O seu cliente pagará para colocar todos esses recursos juntos E pagará para você desenvolver o processo em cima disso ?
O otimismo me diria : “Com certeza irão !”
O realista me diz : “Porque fariam isso ?”
Parece chato... Porque eu não deveria simplesmente ignorar o BPM?
Não há motives para prestar atenção ao BPM enquanto você não construir aplicações centradas em processos.
Se uma aplicação que você escrever envolver um único participante, você nunca precisará do BPM... mas eu encorajo você a dar uma boa olhada nas aplicações, porque elas funcionariam melhor se fossem centradas em processos.
Por exemplo... todo sistema de Rastreamentos de Problemas implementa processos com múltiplos participantes. Tristemente os processos são normalmente codificados entro dessas ferramentas, mas mais e mais você encontrará ferramentas de Rastreamento (como Jira) que provêm interfaces de web-services para interagir melhor com outras ferramentas que são usadas em processos mais amplos.
Outro exemplo... Seu IDE favorito. Mais e mais nós estamos vendo funcionalidades orientadas a processos surgindo nessas ferramentas. Por que não usar um motor exeistente (como Apache ODE) e fazer essas ferramentas mais flexíveis ?
Pensamento final...
Desde o inicio, o núcleo da maior parte da programação tem sido Definições de Processos e Estruturas de dados. BPM é o nosso ultimo lembrete disso.
Extraído e traduzido do original em Inglês de John T. Reynold
Nenhum comentário:
Postar um comentário