Workflow em BPM

Programação Arquitetura
#1

Bom dia pessoal,

Temos um sistema de extrema complexidade e alta disponibilidade rodando aqui. Existe uma espécie de fluxo tatuado em código. Mas sugeri que alterassemos um pouco e tentassemos colocar em BPM.

Uma outra pergunta: tenho estudado muito BPM em geral e jBPM. Porquê diabos não existe uma maior adoção de BPM? Alguém imagina?

Alguém aqui sabe me dizer um bom benchmarking sobre o jBPM? O que acham da idéia?

Grato!

#2

Na minha opinião são vários fatores, mas o principal é a falta de cultura para modelagem de processos de negócio nas organizações.
O que exigiria a presença de um Analista de Negócio para fazer este trabalho, e aos Analistas de Sistemas caberia converter este processos de negócios para os sistemas, usando jBPM ou BPEL, etc.

#3

[quote=Italivio]Na minha opinião são vários fatores, mas o principal é a falta de cultura para modelagem de processos de negócio nas organizações.
[/quote]

Sem dúvida, há um problema cultural.

Também há outros agravantes. Muitas vezes, nem os próprios fornecedores sabem orientar os clientes no processo de adoção de BPM/SOA em novos projetos. Isso tem levado a um grande número de projetos fracassados e os clientes têm ficado “traumatizados” com qualquer coisa que esteja relacionada a esses conceitos.

De qualquer maneira, BPM e SOA vieram para ficar e as empresas que não enxergarem isso vão ficar para trás.

#4

[quote=andre_salvati][quote=Italivio]Na minha opinião são vários fatores, mas o principal é a falta de cultura para modelagem de processos de negócio nas organizações.
[/quote]

Sem dúvida, há um problema cultural.

Também há outros agravantes. Muitas vezes, nem os próprios fornecedores sabem orientar os clientes no processo de adoção de BPM/SOA em novos projetos. Isso tem levado a um grande número de projetos fracassados e os clientes têm ficado “traumatizados” com qualquer coisa que esteja relacionada a esses conceitos.

De qualquer maneira, BPM e SOA vieram para ficar e as empresas que não enxergarem isso vão ficar para trás.[/quote]

Concordo…Alem do que a empresa precisa antes de mais nada, saber o melhor processo de trabalho que lhe cabe…desde quando o processo começa e onde termina…
trabalhei muito tempo com processo workflow…em jbpm …ele tem suas vantagens mas possui desvantagens tambem…eu particularmente acho muuito legal mesmo os conceitos aplicados…por mim só faria sistema baseado em BMP…

Na minha opinião tambem muito projetos dão errado é pq nem todo sistema é passivel de aplicação dos conceitos workflow…tem isso tambem…ja peguei implementação que se fosse melhorar e fosse moldar ao desejo do cliente nao daria pra aplicar muito conceito que o BPM exige que seja seguido…

Bom essa é uma area que vai dar muito dinheiro ainda…profissional com esse conhecimentos são caros e raros…esse foi um dos motivos maiores que me levou a estudar conceitos de BMP a fundo…

jbpm é apenas uma implementação do java que é open source…
existem muuuuuuitas outras que são pagas (ITALIUM,XEROXx,etcetc) que fazem a mesma coisa…
acho que tem um documento do grupo gartner que diz quais a referencia que uma ferramente workflow deve ter pra se encaixar num grupo perfeito segundo os conceitos…

#5

Vale lembrar, também, que BPM também é uma cultura nova. Isso traz certa resistência, porque as pessoas preferem usar aquilo que já conhecem e confiam do que adotar novos processos. E também, como foi citado pelo André, uma série de fracassos de SOA tem levado as empresas a levantar barreiras ainda maiores com relação a tudo que se relaciona a SOA - como BPM.

[]´s

#6

Não adianta, também, tentar usar BPM em tudo. Toda e qualquer tecnologia deve ser usada com parcimônia, onde se aplicar. Muitos projetos para empresas têm fluxos bem definidos de operação, mas nem todos. Então, cuidado, OK?

[]´s

#7

Bom antes de um projeto de BPM entrar, precisa ter uma etapa prévia que é o levantamento de processo o “As-is”, não tão densa que disperdice dinheiro, mas é importante conhecer o passado e focar no “to-be”. Após o fluxo de modelagem, se começa o desenho desses processos.

Importante lembrar que normalmente esse tipo de abordagem está mais no nível do negócio e hoje o cenário é mais maduro. As ferramentas melhoraram muito, várias estão na sua 6 ou 8a versão.

#8

[quote=Kenobi]Bom antes de um projeto de BPM entrar, precisa ter uma etapa prévia que é o levantamento de processo o “As-is”, não tão densa que disperdice dinheiro, mas é importante conhecer o passado e focar no “to-be”. Após o fluxo de modelagem, se começa o desenho desses processos.

[/quote]

Vulgo “reengenharia de processos”. Que, segundo a Wikipedia, é um tópico sobre administração. =P

[]´s

#9

Bom, eu não sei. Desde que conheci BPM (desde agosto do ano passado) tenho visto que é muito interessante e MUITOS problemas nossos seriam resolvidos se a arquitetura fosse feita baseada em workflows.

#10

Fato! Mas, como mencionamos, existe o problema de 1- ser coisa nova e 2 - estar atrelado a SOA (que já gerou trauma em muitas empresas).

[]´s

#11

Fato! Mas, como mencionamos, existe o problema de 1- ser coisa nova e 2 - estar atrelado a SOA (que já gerou trauma em muitas empresas).

[]´s[/quote]

Aqui no Brasil essa sensação é menor, pois muitos projetos começaram há pouco tempo, onde as ferramentas já estavam beeem mais maduras.

#12

Fato! Mas, como mencionamos, existe o problema de 1- ser coisa nova e 2 - estar atrelado a SOA (que já gerou trauma em muitas empresas).

[]´s[/quote]

Aqui no Brasil essa sensação é menor, pois muitos projetos começaram há pouco tempo, onde as ferramentas já estavam beeem mais maduras. [/quote]

A adoção depende menos de ferramentas e mais de estratégia e processos.

Muitos projetos fracassam pq “acham” que só por estar usando o BEA Aqualogic ou Jboss SOA ou o IBM Process Server já estão implantando SOA/BPM.

#13

Fato! Mas, como mencionamos, existe o problema de 1- ser coisa nova e 2 - estar atrelado a SOA (que já gerou trauma em muitas empresas).

[]´s[/quote]

Aqui no Brasil essa sensação é menor, pois muitos projetos começaram há pouco tempo, onde as ferramentas já estavam beeem mais maduras. [/quote]

A adoção depende menos de ferramentas e mais de estratégia e processos.

Muitos projetos fracassam pq “acham” que só por estar usando o BEA Aqualogic ou Jboss SOA ou o IBM Process Server já estão implantando SOA/BPM.[/quote]

Concordo totalmente, mas antes você tinha 2 problemas o teórico e o ferramental. Hoje ao menos a segunda está bem madura, falta somente a teoria para as empresas.

#14

A Workflow Engine do jBPM interpreta XPDL ou tem seu proprio schema XML?
Ainda não tive oportunidade de trabalhar com ele.
Utilizo uma solução caseira da empresa que apesar de limitacoes esta muito bem integrado na arquitetura do sistema.

#15

[quote=FrancoC]A Workflow Engine do jBPM interpreta XPDL ou tem seu proprio schema XML?
Ainda não tive oportunidade de trabalhar com ele.
Utilizo uma solução caseira da empresa que apesar de limitacoes esta muito bem integrado na arquitetura do sistema.[/quote]

Não, a engine tem a sua própria linguagem (jPDL).

[]´s

#16

discussão interessante essa pessoal! Mas acredito que retornando a pergunta inicial, do por que as soluções de BPM ainda não decolaram, acredito que seja um apanhado de tudo isso que vocês disseram:

[quote]
Porquê diabos não existe uma maior adoção de BPM? Alguém imagina? [/quote]

  • Dificuldade em desenvolver algo padronizado tecnologicamente, ou seja, o que desenvolvemos em uma plataforma fica preso a esta
  • Mudança forte cultural, onde as pessoas ainda tem dificuldade de sair do silos de trabalho, das suas gerências e focar o seu tempo de trabalho no que realmente interessa que são os processos de negócios, alinhados a uma estratégia
  • Complexidade dos projetos de BPM, pois podem trazer junto com si, desde desenvolvimentos isolados, até em alguns casos BI, para acompanhamento do histórico do seu processo e em alguns momentos a sua melhoria. Temos também diversas iniciativas de integração, movimentos relacionados a arquitetura SOA(que ainda não estão também consolidados nas empresas), interfaces ricas e intuitivas, etc
  • Valor de um projeto de BPM, pela sua grandeza, complexidade, quantidade de envolvidos e riscos acabam tornando-o uma solução ainda hoje meio que desafio, por isso o recomendado quando se quer iniciar uma iniciativa BPM, ainda devemos partir para um piloto, em um processo não core da empresa para entendermos e aprendermos com ele.
  • A grande necessidade do patrocínio para este tipo de projeto, considerando os itens mencionados acima é algo que hoje ainda não convenceu os líderes(diretores, gerentes) das organizações a assumir a paternidade da criança e ajudar na briga
  • A gestão de mudanças para fazer um acerto com ênfase em todo o funcionamento e os entregáveis do projeto, bem como permitir que as pessoas envolvidas e que serão envolvidas quando a solução estiver funcionando, se sintam confortáveis com a nova forma de trabalho e onde ela se encontra dentro do contexto do processo e mostrando também como grande ponto deste tipo de solução que a idéia do BPM não é criar fábricas em série como na revolução industrial, mas que pretende organizar a maneira de trabalhar das pessoas, ordenando logicamente tudo o que for necessário em benefício da empresa.
  • Faltam metodologias para se trabalhar em projetos deste tipo e é uma das coisas que as empresas devem atacar tão logo resolvam trabalhar com esse tipo de disciplina, que é como os envolvidos geram seus artefatos, quais devem ser estes artefatos, quem gera o que, enfim um roteiro de condução do processo de desenvolvimento. Talvez dentro deste contexto o uso de um projeto piloto ajude na criação dessa metodologia.

Na minha visão estes fatores, não ordenados por grau de complicação, fazem parte das dificuldades deste tipo de projeto de BPM, independente de qual solução nossa empresa resolver adotar pra isso.

#17