Codificação zero

Versus escrever código atrás das caixas

 

BPMN e BPEL fazem para uma combinação extremamente poderosa porque apresentam um caminho do diagrama ao código sem ter que realmente escrever o código. Vamos enfrentar isto, muito trabalho no desenvolvimento destas duas especificações, foi beneficiado pela quantidade de experiência coletiva sem precedentes que nenhum fornecedor poderia combinar com seus próprios recursos. O que esse significa é que a maioria de produtos de BPM, que são baseados em notações proprietárias e em linguagens da execução realmente requerem a escrita de bastante código a fim fazer processos executáveis. Duplo clique sobre as caixas e as setas, e códigos escritos em Java ou as linguagens proprietárias mostrarão sua face. Nada contra o código, mas apenas que manter é mais difícil e mais caro do que a escrever. A BPM 2.0 possibilitou executar os processos mais complexos sem ter que escrever o código. O governo holandês fez apenas aquele para um processo que tivesse um quarto de milhão atividades, assim que se trabalhar para elas em tal escala, deve trabalhar para muitas outras organizações.

Mas por que codificação zero importa? Esta é a oitava edição da nossa publicação semanal do BPM 2.0. Hoje, eu tentarei explicar porque o código zero importa. A maioria das soluções de BPM necessitam que os usuários escrevam manualmente o código atrás das caixas e das setas usadas descrever um processo. Não há nada de errado sobre código do software, mas o código é uma das coisas para que menos é mais, e há mais de uma razão para que seja verdadeiro.

Primeiramente, BPM necessita a participação de analistas do negócio, mas os analistas do negócio não podem ler nem escrever código. O pessoal técnico habilitado poderia escrever o código atrás das caixas e das setas que os analistas do negócio extrairiam, mas das eles não ajudariam realmente a construir uma ponte entre o negócio e o TI, dividindo-se? BPM 2.0 advoga um modelo onde os processos executáveis sejam executados por analistas de processos, e estes poderiam escrever o código se tivessem que realmente, mas tendem a preferir usar ferramentas gráficas preferivelmente.

Há 8 milhões de programadores Visual Basic hoje . é a maior comunidade programadores hoje . e deve haver uma razão porque Microsoft chamou de BASIC sua ferramenta de desenvolvimento Visual. Se nenhuma lógica do negócio puder se esconder atrás das caixas, os analistas do negócio será mais provável, que os analistas de processos compreendam o que fizeram, e esta é uma maneira certa construir uma ponte entre o negócio e o TI divididos, para não se destruir inteiramente.

Em segundo, os seres humanos fazem erros, e o exercício do código da escrita é um erro - propenso. Na média, uma forma do processo em BPMN leva a 10 linhas do código de BPEL, e uma linha do código de BPEL substitui aproximadamente 10 linhas do código de J2EE. Significa que 100 linhas do código J2EE desagradáveis teriam que ser escritas se as ferramentas da geração de BPEL não existirem. Se seu processo tiver centenas ou milhares das etapas (ou de 250.000 como o um Intalio construiu para o governo holandês), aquele é dezenas dos milhares ou de centenas de milhares das linhas do código. O código comercial tem tipicamente em qualquer lugar de um a sete erros por 1000 linhas do código de acordo com um relatório do National Cyber Security Partnership.s Working Group on the Software Lifecycle (Source: ZDNet).

Isto significa que em média o projeto de BPM terá centenas, se não milhares de erros nele, que terá que ser reparado manualmente, um por um. Se você deixar uma ferramenta zero do código BPM gerar o código para você, você não tem que preocupar-se mais sobre estes erros. Concedido, o gerador de código da ferramenta de BPM poderia ter alguns erros, mas será provavelmente serão reparados pelo fornecedor antes que você obtenha os erros que você mesmo criará escrevendo o código manualmente. Além disso, uma vez que os erros da ferramenta são fixos, produzem o código válido qualquer um que usa.

Finalmente, o código do software for geralmente imperativo, quando o código zero projeto-dirigido o desenvolvimento tende a ser muito mais declarativo na natureza. O que estes os meios são que a informação contida dentro dos diagramas de BPMN é muito mais explícita, essa informação equivalente encaixada no código de J2EE ou de C#. Uma informação mais explícita, mais fácil começa com a plataforma de BPM forneça a simulação, eliminando erros, relatando e potencialidade de otimização. Para encurtar a história, o código é melhor escrito pelo fornecedor e os clientes devem focar seus esforços em melhorar seus processos do negócio melhor que o código usado para suportá-los.

http://www.projeler.com.br/artigos_bpm20h.jsp

 

BPEL

Versus BPEL, BPML, WSFL, XLANG, XPDL

 

Até um tempo atrás, não havia nenhum padrão para processos executáveis. XLANG estava emergindo, WSFL não existia, e pessoal do workflow haviam produzido nada mais do que um conjunto de relações totalmente inúteis. Então o BPMI.org liberou a especificação da BPML, que forçou Microsoft e IBM para abandonar XLANG e WSFL respectivamente. Por razões políticas, Microsoft e IBM decidiram escrever sua própria especificação, em vez de adotar BPML, que conduziu à liberação de WS-BPEL, um ano depois que a primeira execução comercial da especificação da BPML distribuída em produção. Três anos das discussões públicas seguidas, até que o BPMI.org foi fundido com a OMG e decidido finalmente deixar a BPML em favor de BPEL. Até então, nenhum padrão real estava disponível nos últimos seis anos, que contribuíram a retardar a baixa adoção do BPM.

As coisas são um pouco diferentes hoje. BPEL ganhou, BPEL 2.0 é uma especificação boa o bastante para os clientes construírem processos de missão crítica com, e todos os grandes fornecedores adotaram-na. BPM 2.0 trabalha graças ao BPEL, bem como bases de dados relacionais trabalha graças ao SQL. Os analistas de processos não devem realmente importar-se com ele, porque não terá que escrever uma única linha do código de BPEL se escolherem a ferramenta certa, mas BPEL é como o DNA do processo, ele é o padrão em que tudo é construído ao redor. Assim se você estiver ouvindo que BPEL não importa, ou que o produto que você está considerando para aquisição declarar que suportará BPEL ano seguinte, não se engane: você está a ponto de comprar uma parte muito cara de software proprietário que você terá que se livrar de mais cedo do que você pensa, assim como os que a recém se adaptaram ao padrão.

Mas por que BPEL importa? Fora os 250 fornecedores de BPM podem ser encontrados no Google, menos de 10 suportam BPEL de forma nativa. Os outros 240 fazem geralmente um caso que BPEL não importa realmente, porque nenhum analista do negócio o usaria diretamente. Estão certos e errados.

Estão certos, no sentido que, nenhum analista de negócio . ou analista de processos . terá que escrever uma única linha do código de BPEL. Em vez deste, usarão uma ferramenta de modelagem de processos que gere o código para eles. Mas são também estão errados, o que se importam com a maneira que o código é gerado, por três razões principais.

Primeiramente, usar um motor de processos que suporte BPEL de forma nativa assegura que os processos que são distribuídos nele poderão ser distribuídos em outro motor de processos também. Tanto quanto eu posso dizer, esta é a melhor política que de seguro todo o cliente poderia iniciar. Admitidamente, o fato é que BPEL tem as versões múltiplas (1.0, 1.1, 2.0) e suporta definição proprietária de extensão . muito semelhante ao SQL com SQL-87, SQL-92 e stored procedures proprietárias . tal portabilidade deverá ocorrer. Não obstante, é muito mais fácil do que optar por uma linguagem proprietária do fornecedor tal.

Em segundo, projetando os processos que são ser distribuído visado um servidor executável de BPEL permite que os desenvolvedores façam algumas suposições a respeito da execução ambiente que os hospedará: as interfaces web services estarão lá para interagir em qualquer momento com os processos em sua execução, os dados par auditoria terão certo formato . ou pelo menos são definidos uma semântica comum, e uma coleção de processos estarão definidos e construídos antecipadamente, sem ambigüidade. Isto faz o desenvolvimento de ferramentas baseadas em padrões para monitoração da atividade de negócio e análise dos processos e simulação muito mais fáceis dentro do eco-sistema do BPM.

Em terceiro lugar, se os fornecedores do workflow, gostando ou não . usualmente para eles BPEL não se transformou em um padrão de fato na indústria. A maioria de fornecedores de BPM hoje foram fornecedores do workflow no passado, e a grande comunidade de workflow fez um bom trabalho que fragmentou o mercado, e ninguém desenvolveu nem suportou um padrão útil. Pensar em dividir-se para conquistar é uma estratégia onde ninguém conquista realmente qualquer coisa em primeiro lugar. Em conseqüência, os fornecedores de workflow tem um interesse investido dentro BPEL, a fim retardar sua baixa adoção e sua própria evolução em relação à sua irrelevância. Mas não há engano. Quando a maioria dos fornecedores de TI . incluindo IBM, Microsoft, Oracle e SAP . concordam com o padrão fornecido, não há muito espaço para mais outro. QL pode ter sido melhor do que o SQL vinte anos atrás, mas a suporte que a IBM deu ao SQL o fez um vencedor certo. O suporte para XPDL seria uma perseguição nobre somente se XPDL fosse tecnicamente superior a BPEL. Não é, e conseqüentemente eu não vejo razão em não usar BPEL. E se você pretender usar um produto que não suporte BPEL de forma nativa, certifique-se de pedir que o fornecedor de BPEL ajude-o migrar para um que o faça. A última vez onde eu verifiquei isto, não era tão difícil.

Um dos melhores lugares para aprender mais sobre BPEL está no blog de um de meus concorrentes, uma publicação excelente no BPEL Radio publicado por Edwin Khodabakchian, vice-presidente de desenvolvimento de produto da Oracle. Edwin foi fundador da Collaxa, companhia que desenvolveu o primeiro trabalhando para execução de BPEL. Ele sabe o que está falando, e confia nisto.

http://www.projeler.com.br/artigos_bpm20e.jsp

 

Adorado pelo pessoal de ABAP, PHP e VB

Versus usado somente por peritos em J2EE

 

Os produtos de BPM da primeira geração necessitavam competências em J2EE, ou mesmo linguagens de script proprietárias, como se o mundo necessitasse de outra linguagem de programação. Tanto quanto eu gosto de J2EE como um fornecedor do software, isto é uma especificação anormal, complexa, que está fora do alcance para a maioria das pessoas de TI. A programação orientada a objetos é extremamente poderosa, mas como ela ou não, a maioria os programadores não a compreendem, nem pelo menos usariam algo mais simples como PHP ou Visual Basic. Há 2 milhões programadores de Java por aí, e eu conto que somente uma fração deles pode escrever componentes de EJB. Menos ainda sabem combinar EJB com o JMS, o Servlets e os Mensage-Driven Beans. Compare isso aos 3 milhões de desenvolvedores PHP e aos 8 milhões de codificadores em VB para aí, e você começará a ter este cenário. BPM 2.0 não é para os gurus de J2EE, e nem limitado a eles. BPM 2.0 alveja os analistas de processos que podem ler um diagrama em BPMN, para compreender a representação da árvore de um esquema XML, clicar e arrastar formas em uma tela. Se você pensar que pode fazer sem grande esforço, BPM 2.0 trabalhará para você.

Mas o que há de errado com J2EE? Java . e J2EE corporativo . são tecnologias extremamente poderosas. O problema é que poder vem acompanhado de complexidade, e J2EE é um exemplo perfeito para isto. O site do Java Community Process (JCP) possui 320 pedidos de especificação (JSRs), e a especificação Beta da API corporativa da edição 5 tem 1438 classes. De qualquer maneira você percebe que o Java cresceu, ficou grande e do complexo.

J2EE foi supostamente para trazer portabilidade para as aplicações desenvolvidas, mas a realidade é que além das as mais simples que tomam somente a vantagem de um recipiente de Servlet, você não pode mover aplicações de servidor de aplicação para outro, especialmente se empregarem componentes dos Enterprise Java Beans (EJB).

O modelo de componentes EJB 3.0 prometem mudar isto. Infelizmente, quando um problema é reparado aqui, um novo aparece. Nós experimentamos isto recentemente quando nós tentamos mover nosso servidor de processos para o Apache Geronimo. Tudo trabalhou muito bem até que nós tentamos empacotar todos componentes junto . servidor de processos, serviços de workflow, motor de XForms, etc. . então quebrou. De algum modo, um componente desligava um serviço compartilhado de Log4j, e nós não tivemos uma maneira fácil de isolar qual componente estava com falha. Este problema irritante, junto com uma dúzia de similares, manteve uma equipe de três do melhores programadores Java, ocupados a maior parte do último trimestre. Se uma empresa de software como a Intalio, que o negócio é desenvolver o software, estar enfrentando este tipo de desafio, como será para os usuários finais cujo negócio preliminar está vendendo dispositivos ou está processando transações financeiras? Bem, tanto quanto eu posso dizer de muitas discussões com clientes, não é que grande tampouco.

Seu programador médio e não posso tratar neste nível de complexidade. Não que não é esperto o bastante, mas tenho as coisas melhores a fazer, como tomar cuidado do negócio por exemplo. E que é verdadeiro para J2EE é também verdadeiro para tecnologias colaterais, tais como o Eclipse por exemplo, tentado sempre usar EMF e GEF? Para mim, BPM 2.0 é toda sobre oferecer um pulo do quantum de abstração que permitirá seu desenvolvedor médio . pessoal de ABAP, PHP e VB . abstrair esta complexidade e focar em níveis mais elevados, como processos, regras, e relações. Para estender estes desenvolvedores sem a complexidade do J2EE e .NET, a BPM 2.0 dá-lhes as ferramentas para ser produtivos, como vingança. Isso é precisamente porque gostam disto.

 

http://www.projeler.com.br/artigos_bpm20d.jsp

 

Uma única ferramenta no Eclipse

Versus múltiplas ferramentas de múltiplos fornecedores

 

Não faz muito tempo, que para mapear e distribuir o código processos eram necessárias sete ferramentas: uma para modelar o processo no nível do negócio, outra para descrever detalhes técnicos, uma terceira para construir conectores aos sistemas externos, uma quarta para mapear a entrada e saída de dados, uma quinta para especificar regras de negócio, uma sexta para projetar interface de usuário do workflow, e uma sétima para distribuir todo o código em uma coleção de componentes proprietários para execução. Todos os tipos requeriam diferentes competências, funcionaram em ambientes diferentes, usavam linguagens diferentes, perdiam informação entre um e outro, complexo de montar para que o usuário final pudesse realmente os usar sem necessidade serviços de consultoria caros de um fornecedor de software que juntou várias partes construídas a partir de múltiplas aquisições.

BPM 2.0 põe tudo que você necessita dentro de uma ferramenta, e essa ferramenta está no Eclipse. Com Oracle e SAP atualmente suportando o Eclipse, nenhum outro ambiente integrado de desenvolvimento . ao lado do Microsoft Visual de Estúdio . terá importância, daqui um tempo sua ferramenta de BPM 2.0 funcionará nativamente no Eclipse.

Mas por que o Eclipse é importante? Minha definição para BPM 2.0 indica que um BPMS deve ser construído em torno de uma única ferramenta no Eclipse, e esta indicação radical merece uma explanação mais completa, como foi ilustrado por algumas das discussões que seguiram para colaborar com a publicação original do BPM 2.0.

Os ambientes integrados do desenvolvimento (IDEs) são como Sistemas Operacionais, no sentido que fornecem a infra-estrutura de software que os fornecedores podem construir suas ferramentas, sem ter que re-inventar a roda toda hora. E, bem como Sistemas Operacionais, tendem a ser a vítima de se tornar uma commodity e da consolidação, mais cedo ou mais tarde. A Oracle transformou-se um dos mais fortes apoiadores do Eclipse, Borland decidiu vender seu grupo de JBuilder, e NetBeans não está dirigindo exatamente desenvolvedores à plataforma Sun.

Isto deixa os dois no ringe: Eclipse e Microsoft Visual Studio. Mas porque Microsoft não gosta se expor aos seus os concorrentes, a maioria vasta de fornecedores de BPMS adotaram Java como a plataforma de desenvolvimento, e esta são onde o Eclipse entra no jogo. Ou seja, se você for Microsoft, seu BPMS será construído em torno do Visual Estúdio, mas se você não for, o Eclipse serão caminho.

O benefício principal de usar um IDE padrão para desenvolver as ferramentas que farão parte para oferecer BPMS é que você pode alavancar os componentes existentes que já foram desenvolvidos por terceiros. Por exemplo, Intalio está usando um editor de XForms WYSIWYG desenvolvido com a Orbeon, que estão disponíveis como plug-ins do Eclipse. Também, porque o Eclipse fornece a suporte para os sistemas de controle de fontes os mais populares, integrar com a infra-estrutura de gerenciamento do ciclo de vida da aplicação simplificado, e o fornecedor de BPMS começa tudo isto essencialmente livre.

Deve ser dito, usar o Eclipse em vez de uma estrutura proprietária cria um par dos desafios. Primeiramente, o Eclipse é uma plataforma muito complexa que faz uso extensivo de tecnologias avançadas tais como EMF e GEF. A curva de aprendizagem para este é consideravelmente íngreme, e a produtividade de um colaborador Java que converter-se ao Eclipse pode ser reduzido significativamente para os primeiros três a seis meses. Em segundo, porque o Eclipse foi desenvolvido originalmente para engenheiros de software, torna tudo mais complexo do que deve ser para desenhista de processos médio. Em conseqüência, um fornecedor de BPMS que adota o Eclipse como IDE deve certificar-se esconder esta complexidade de usuário mais simples. Esta não é uma tarefa fácil, mas os benefícios que você pode ganhar funcionando no Eclipse compensam pela maior parte o esforço da migração. Obrigado IBM por esta parte do software!

http://www.projeler.com.br/artigos_bpm20c.jsp

 

Inicie com um BPMS completo

Versus começar com uma ferramenta de modelagem de processos

 

Porque BPM foi originalmente produzido para aos analistas do negócio, fornecedores pensaram que seria uma boa idéia começar somente com a ferramenta que o analista do negócio da poderia usar, isto é, algum tipo da ferramenta diagramação de fluxogramas. O problema, é que isso é exatamente o que os clientes fizeram, mas não fizeram nada mais além disso, por uma razão muito simples: uma vez que um analista do negócio tem diagramado um processo com uma ferramenta que não reforce nenhuma regra que faça o processo ser executável, não há nenhuma maneira fazer esse mais processo executável mais tarde. Todo este trabalho será desperdiçado e o analista do negócio se sentirá iludido.

Se você quiser tentar com BPM 2.0, meu conselho é .não compre uma ferramenta de modelagem de processos.. Ao invés, inicie com um BPMS completo e comece a construir processos executáveis no primeiro dia. Alguns chamarão isto de Desenvolvimento Ágil para processos de negócio. Eu chamo BPM que funciona.

Mas o que é um BPMS completo? Para mim, um BPMS deve suportar o desenho e a execução do processo, conseqüentemente uma ferramenta de modelagem de processos simples com potencialidades de simulação do processo não a qualifica como um produto de BPM 2.0. Também, um BPMS deve suportar orquestração dos serviços e interações humanas no fluxo de trabalho. Você pode pensar como dois lados da mesma moeda, numa face os sistemas de retaguarda de TI, em outra face pessoas com suas interfaces. Como resultado disto, um BPMS completo tem três componentes principais: uma ferramenta de desenho dos processos, um motor de execução de processos, e uma interface de usuários para os fluxos de trabalho.

Se você quiser um BPMS mais completo, três potencialidades adicionais são necessárias: suporte a regras de negócio complexas, monitoramento das atividades de negócio (BAM), e uma maneira controlar versões de documentos anexados as instancias dos processos. Não importa realmente se estas potencialidades forem oferecidas de forma nativa pelo núcleo do BPMS, nem é fornecido por componentes externos, contanto que o ciclo de vida de processos do negócio seja preservado, com codificação zero e distribuição em um clique.

E se você quiser ser realmente extravagante, mais três coisas podem ser adicionadas: um barramento de serviços corporativo (ESB), um repositório de metadados, e um conjunto para inteligência de negócio (BI) que lhe ajude a cortar e fatiar os dados que saem da infra-estrutura de BAM. Uma vez alcançado esse nível de sofisticação, você obterá um BPMS completo que possa ser usado para controlar virtualmente qualquer tipo de processos do negócio, dentro dos ambientes mais complexos. Agora, vamos fazer um exame e olhar como a Intalio está construindo tal coisa. Primeiramente, nós desenvolvemos uma ferramenta de desenho de processos (que usa o Eclipse como base), um servidor de processos, e um conjunto para fluxos de trabalho. Em segundo, nós escolhemos como parceiros preferidos Corticon e OpenLexicon para regras de negócio, Actuate Birt para monitoramento das atividades do negócio (BAM), e Alfresco para gerenciamento de conteúdo (ECM), LogicBlaze ServiceMix e MuleSource para barramento de serviços (ESB), Pentaho para extração, transformação e carga de dados (ETL), IBM WebSphere para servidor de aplicações, Orbeon para formulários, Liferay para portal e MySQL para banco de dados. A integração com estes produtos é feita com nosso programa de desenvolvimento de demanda dirigido (D3).

Se você estiver procurando um BPMS completo, experimente Intalio.

http://www.projeler.com.br/artigos_bpm20b.jsp

 

Usado por Analistas de Processos

Versus introduzido no mercado aos analistas de negócio

 

Vamos começar derrubando a maior mentira sobre BPM, que é que os analistas do negócio poderiam usar uma ferramenta de BPM modelar e distribuir um processo executável do negócio. Embora isso tenha sido verdadeiro para os fluxos de processos centrados em documentos mais simples, tais como, quando um analista do negócio especifica o processo de revisão de um release para ser liberado em um site Internet, isto logo é quebrado quando o processo envolverá transações com o qualquer tipo do sistema de retaguarda de escritório, por duas razões principais: primeiro alguém do TI terá que abrir portas no sistema ERP corporativo para a analista do negócio; em segundo, o analista dito do negócio não vai querer receber chamadas do CEO no meio da noite se o sistema de ERP não puder gravar ordens de compra novas. Conclusão: BPM 2.0 não é para analistas do negócio não técnicos. Nunca devem ter sido, nunca à vontade, e ninguém deve importar-se. Ao invés do BPM 2.0 é para os analistas de processos que se articulam bastante com o público de negócio, e são também técnico o bastante para compreender a diferença entre um laço do-while e um comando for-each. Não construiremos uma ponte entre o negócio e a TI dividindo e autorizando analistas de negócio para começar a livrar-se do pessoal de TI. Em vez disto, deixar apenas uns analistas de processos mais técnicos compreenderem exigências do negócio e executá-las diretamente no processo, enquanto alavanca sistemas de TI. Nem top-down nem bottom-up, é uma abordagem middle-out, e é único que faz uma abertura mais estreita.

Mas quem é o analista de processos? Um teste simples é perguntar a um candidato se ela compreende as diferenças entre um laço do-while, while-do e um for-each. Se puder explicá-lo a um analista do negócio o que um laço você encontrou a pessoa que procurava. Você o encontrará entre os 8 milhões de programadores de Visual Basic, os 3 milhões fãs do PHP, o milhão da tribo PL/SQL, e meio-milhão de entendidos em ABAP. Se você comparar com aos 2 milhões de pessoas que podem escrever o código de Java nos dias de hoje, este é um bom grupo. Se você adicionar a esta mistura pessoas que compreendem HTML, você terá de mais de 20 milhões pessoas que você poderá extrair deste. E se você quiser compreender porque um mestre em Java e J2EE não deve ser um pré-requisito para usar um BPMS, apenas leia o programa de estudo para o curso no jBPM oferecido pela JBoss:

"O estudante deve ter a experiência precedente em desenvolvimento com Hibernate aplicação. O estudante deve saber configurar um simples SessionFactory para Hibernate, utiliza uma Session Hibernate e demarcar transações e como executar perguntas básicas em objetos do Hibernate".

Para mim, é muito bonito para mostrar uma tampa. BPM 2.0 não é para inflexíveis.

http://www.projeler.com.br/artigos_bpm20a.jsp

 

BPM 2.0

Por Ismael Chang Ghalimi, CEO, Intalio

 

Versão em Português

Prefácio

 

Este documento é uma compilação de 18 artigos semanais publicados no blog IT|Redux entre os dias 13 de março de 2006 e 10 de julho de 2006. As publicações originais foram ligeiramente editadas a fim caber no formato desta compilação. As referências e os comentários adicionais dos usuários estão disponíveis online.

 

Este documento foi originalmente editado usando a ferramenta ThinkFree Office 2.0 de produtividade para escritório.

Introdução

 

Há seis anos, eu escrevi o primeiro artigo sobre BPMS. Era uma das publicações semanais que ajudaram definir o conceito para BPM e começar uma nova indústria. O acrônimo de três letras, emprestado dos músicos, se transformou numa sensação imediata, bem sucedida além de todas as expectativas que poderíamos ter tido naquele momento. Alguns diriam até, bem sucedidos.

 

Hoje, o codinome BPM é usado para descrever qualquer legado dos produtos de workflow, motores da regras de negócio, ferramentas diagramação de fluxogramas, geradores de código Java, ou mesmo serviços de consultoria de reengenharia de processos de negócio. Esta confusão, perpetuada por fornecedores de software e por analistas da indústria igualmente, serve a duas finalidades principais: permite todo fornecedor que puder mostrar caixas e setas em seu produto vender sua caixa, enquanto que qualquer analista que possa compilar uma lista dos fornecedores mencionados vendem seus serviços brilhantes a usuários totalmente confusos.

 

Em conversa com clientes, eles solicitam uma mudança. Na tentativa da primeira versão do BPM, não encontraram o que procuravam, e estão querendo saber, se vale à pena tentar, se houvesse qualquer outra coisa. A notícia boa: há, eu a chamo de BPM 2.0 . um termo inventado originalmente por meu bom amigo de Bruce, e está disponível agora. A má notícia: a definição que eu dou para BPM 2.0 é radical, não saiu de qualquer lugar e, a maioria dos fornecedores não gostarão. Mas supõe o que? Eu estou mais interessado em fazer clientes felizes do que deixar outros fornecedores dormirem tranqüilos, especialmente quando forem meus concorrentes. Assim, damos aqui, boas-vindas a BPM 2.0!

Sobre o autor

 

Ismael Ghalimi é um empreendedor apaixonado, e um observador da indústria, fundador e CEO da Intalio, criador do BPMI.org e um iniciador do Office 2.0. Ismael é mergulhador profissional, piloto privado, e fanático por American V-Twin. Ismael pode ser contatado em ismael@itredux.com.

Sobre a tradução para o português

 

Esta é uma tradução para o português brasileiro, autorizada pelo autor que poderá não corresponder fielmente ao texto original. Contribuições para melhorias são bem vindas pelo email contato@projeler.com.br.

 

http://www.projeler.com.br/artigos_bpm20.jsp