Windows Workflow Foundation x BPMN BPEL não é BPM e Vice-Versa

BPM e metodologias de gerenciamento de projetos

27 de Novembro de 2007 às 21:10 Rafael Bortolini  | Enviar por e-mail Hits para esta publicação: 1513

Vamos abrir uma espaço para falar um pouco sobre automação de processos e metologias de gerenciamento de projetos.

Antigamente, por termos vindo de uma fábrica de softwares, estavamos acostumados com o modelo de gerenciamento de projetos “tradicional”, muito centrado pelas definições e conceitos do PMI.

E funcionava. A metologia do PMI é utilizada mundialmente com sucesso na gestão de projetos das mais diferentes magnitudes, sendo referência quando pensamos em alcançar os objetivos do projeto dentro dos custos e prazos definidos. Se falamos em software, então, o PMI é extremamente importante. Quando começamos a trabalhar com automação de processos e BPM, quase cinco anos atrás, o uso do PMI foi uma decisão natural , algo feito quase sem pensar. Treinamentos foram realizados, certificações foram buscadas. Artefatos foram adaptados, planilhas de controle criadas, métricas definidas. O PMI sempre foi uma referência e eu mesmo acabei de renovar minha filiação com o instituto.

A verdade, entretanto, é que, ao longo dos anos, sempre alguma coisa estava errada, alguma coisa esta faltando, alguma não estava fechando - e não sabiamos o quê.

Poucos meses atrás, nosso amigo, parceiro e grande orientador Luís Bender me passou uma folinha e disse para eu ler. Era um resumão do SCRUM, uma das metologias ágeis mais difundidas no mundo. Peguei o avião de volta para Porto Alegre e fui lendo no caminho. Na mesma noite, conversei com o Camilo, amigo que está trabalhando com TI na Nova Zelândia. Do nada, ele me falou que lá a certificação SCRUM é mais requisitada pelos empregadores do que a PMP. Peraí, disse eu, alguma coisa está errada.

Os próximos dias foram de leitura profunda do assunto e atualização sobre um tópico que sempre tinha visto com maus olhos. Um pouco de preconceito com XP, para variar, que alguém deve ter me passado. Ao final de alguns dias, estava mais claro do que nunca: não havia metodologia melhor de controle de projetos que se adaptasse as nossas necessidades do que a metologia ágil, mais especificamente, a SCRUM.

Explico:

- Automação de processos com software de BPM significa entrega de valor rápida, e é isso que vendemos. Precisamos colocar o software/processo no ar rapidamente, precisamos mostrar que tecnologia de processos funciona;

- Automatizar processos significa executar um processo diversos vezes, identificar pontos de melhorias e modificar o processo/software incrementalmente, adicionando novas funcionalidades todo o dia, que se adaptem a necessidade do cliente;

- Automação de processos significa retroalimentar o processo, modificá-lo conforme a necessidade e modificá-lo conforme a empresa muda suas regras de negócio, ou seja, andar na mesma velocidade da empresa. É o contrário do software tradicional, que fica estagnado no ponto onde o programador encerrou, ou vai até onde o contrato de manutenção permite.

- Automatizar processos com BPM é muito, mas muito mais rápido do que desenvolver software tradicional. O fato é que toda a documentação, toda a padronização e controle que os métodos tradicionais de projetos pregam, se aplicada em um projeto de BPM, levam muito mais tempo do que a própria automação do processo. Ou seja, você fica mais tempo documentando e analisando o processo do que transformando ele em realidade.

Um fato que observamos logo no início dos projetos de BPM é que, antigamente, estavamos acostumados a fazer protótipos dos sistemas antes de desenvolvê-los, e isso parecia uma boa prática. Porém, fazer protótipo de processo que vai ser automatizado com BPM é de total inutilidade e significa retrabalho, pois as vezes o protótipo pode levar mais tempo do que a automação simplificada do processo.

Enfim, uma metodologia de gerenciamento de projetos que irá trabalhar com automação de processos de negócio com BPM deve levar em conta os seguintes pontos:

- O escopo não está bem definido pois em geral as pessoas não trabalharam com processos antes e não tem idéia de como funciona;

- O escopo e funcionamento do sistema muda conforme o uso, e a mudança é saudável e significa que a empresa está evoluindo;

- O próprio uso do processo irá levantar tópicos e serem melhorados no sistema e isso deve deve algo natural;

Se você se enquadra nessa realidade, dê uma chance para as metologias ágeis. Quer saber mais sobre o assunto? Pode começar aqui.

 

Publicação arquivada em: Estratégia e gestão, BPM

Enviar por e-mail | Hits para esta publicação: 1514

11 Comentários Faça seu próprio

  • 1. renato  |  27 de Novembro de 2007 às 22:24

    para quem se interessar, 2 e-groups muito interessantes sobre SCRUM:

    http://br.groups.yahoo.com/group/scrum-brasil/
    http://groups.yahoo.com/group/scrumdevelopment/

  • 2. jorge mathias  |  28 de Novembro de 2007 às 22:25

    pigs and chikens!
    sCRUM roxxx!

  • 3. jorge mathias  |  30 de Novembro de 2007 às 22:27

    Interessantíssimo tópico. Estamos utilizando metologias ágeis a um ano em nossa empresa (equipe de 10 desenvolvedores) com sucesso inesperado. Basicamente SCRUM e XP. Mas é muito interessante ver com a metologia ágil pode realmente fazer a difereça em alguns tipos de projetos com características especiais, como é o caso de automação de processos com BPM

  • 4. LUANA  |  5 de Dezembro de 2007 às 22:29

    Ainda não me convenci. Usamos RUP e PMI e para projetos de maior porte e criticidade o formalismo é essencial. A maior parte dos clientes não está preparada para os métodos ágeis ainda. Não digo que nunca estarão, mas se o cliente não tiver o perfil o projeto não sai.

  • 5. Lauro Schumberg  |  5 de Dezembro de 2007 às 22:32

    Gostei!

    Obrigado por compartilharem a experiência de vcs!
    Estamos com um projeto grande de automação de processos usando ferramenta de BPM e a indefinição dos usuários é tão grande que o projeto parece desandar. Vou aprovetar um stand-by temporario no projeto e rever se podemos “chupar” algo desse tópico

    Depois posto os resultados

  • 6. André Lopes Neto  |  10 de Dezembro de 2007 às 22:33

    Esse assunto é tão vasto que poderia render um TC ou trabalho de pós-graduação

  • 7. Marcelo Falco  |  11 de Dezembro de 2007 às 22:34

    Alguém conhece algum custo de MS Project para indicar? Aqui em São Paulo. Desde já obrigado

  • 8. Jonas Brodt  |  13 de Dezembro de 2007 às 22:35

    Interessante

    Vocês estão usando algum software para controlar o backlog, etc.?

  • 9. Luciana Oliveira  |  11 de Janeiro de 2008 às 16:21

    Este artigo fez com que eu tomasse uma decisão que estava retardando a algum tempo: vou utilizar SCRUM para gerenciar projetos BPM. Como para esse tipo de “desenvolvimento” o retorno deve ser muito rápido, não podemos demorar muito tempo documentando.
    Esta é uma solução que podemos adaptar quando em algum momento for necessário um pouco de formalidade.

  • 10. R.Baccelli  |  8 de Abril de 2008 às 04:13

    Demorou… é assim que nós, os mais antigos em processos, trabalhamos. Quando citamos, ementrevistas, os volumes de processos mapeados/ajustados/mantidos X tempo , tem gestor que desconfia. Hoje mesmo um gerente de PMO deixou escapar sua surpresa e acho que perdi o contrato… eles acabam duvidando da qualidade de nosso trabalho. Tomara que eu esteja errada.
    Quando conheci o XP (Desenvolvimento Ágil) achei bastante adequado essa forma de trabalhar também para a TI; e verifiquei que seus resultados conseguem acompanhar a dinãmica do mercado e da economia… quando bem aplicado e com a equipe certa, é claro! …. mas aí é outra história…

  • 11. R.Baccelli  |  8 de Abril de 2008 às 04:32

    … e para a Luana, que a esta altura do campeonato não vai ler meu comentário, enfatiso que vc não deve treinar apenas a sua equipe em desenvolvimento ágil, mas o cliente também, pois ele é parte essencial da equipe. Quando um Gerente de Projeto não consegue convencer o cliente de que ele pode apresentar resultados rápidos, muitíssimo rapidamente, fazendo entregas semanais e priorizadas pelo próprio cliente, de acordo com o que ele formaliza semanalmente, aí é uma questão de propor um piloto de algumas semanas com o, digamos, “Kernel” do processo de negócio… é batata! O gestor vê resultado rápido e consistente e está envolvido até o pescoço com a formalização… é batata, ele não vai parar! É uma maneira nova de atender a atual dinâmica do mercado… e a moda antiga de formalizar a visão, o escopo, o contrato como um todo, precisa se adequar também.
    That´s life!

Deixe um Comentário

Requerido

Requerido,escondido

Linkar esta publicação  |  Assine os comentários via o RSS


Calendário

Novembro 2007
S T Q Q S S D
« Out   Dez »
 1234
567891011
12131415161718
19202122232425
2627282930  

Minhas Publicações Recentes

Publicações por Mês

Meta