Viagem em Business Process Modeling

Parametros em Comandos SQL ODBC no ENSEMBLE/Intersystems

2010-05-25T12:02:00.001-03:00

Quando uma query ou comando SQL possuir funções no parametro ou mais de uma tabela, pode haver erros na camada ODBC, ocasionada pela impossibilidade de descobrir o tipo de dado dos parametros passados;

Para evitar esse erro, pode-se concatenar o parâmetro do comando na string SQL ou usar a seguinte regra:

- Criar uma array multidimencional com os tipos de dados descritos abaixo:

set sql = " Update tab1 " _

" set Codigo = tab2.Codigo " _

" from Tabela1 tab1 " _

" left outer join Tabela2 tab2 on rtrim(tab2.Usuario) = rtrim(?) and tab2.Status = 'A' " _

" where Codigo = ?"

set pParams = 2

set pParams(1) = pRequest.Usuario

set pParams(2) = pRequest.Codigo

set pParams(1,"CType") = $$$SqlVarchar

set pParams(1,"SqlType") = $$$SqlVarchar

set pParams(2,"CType") = $$$SqlInteger

set pParams(2,"SqlType") = $$$SqlInteger

set rc = ..Adapter.ExecuteUpdateParmArray(.Linhas, sql, .pParams)

Processo de SAC em BPMS da Intersystems (Ensemble)

2009-08-07T18:04:00.001-03:00

Fluxo do BPM em Ensemble

Interface do Workflow em Coldfusion MX

Hospedagem na Web Grátis

2008-09-16T17:52:00.001-03:00

Ola pessoal, achei este site de hospedagem grátis, se alguem precisar:

Hospedagem na Web Grátis, sem propaganda, sem letras miúdas.

O Que voce vê é o que voce têm.

Aqui o que voce pode ter :

350 MB Espaço em Disco

100,000 MB em Uso da banda

Subdominio gratis ou seu próprio dominio registrado

Instalador automatic (20 Scripts Populares)

Acesso via FTP e Web

Construtor fácil de Web

5 Bancos de dados MySQL Databases com suporte complete a PHP

Zend & Curl Enabled

Ativação imediata!

Entre agora e registre seu site com ativação imediata - http://www.000webhost.com/77654.html

Repassem aos amigos.

Modelagem de Processos com BPMN 1.1

2008-05-20T13:33:00.001-03:00

Modelagem de Processos com BPMN 1.1

Aprimore processos de negócio e resultados com a
nova versão 1.1 da Business Process Modeling Notation

A décima primeira edição do treinamento Modelagem de Processos com BPMN da PROJELER vai capacitar profissionais a trabalhar com a Business Process Modeling Notation, a mais nova e avançada notação para representar graficamente os processos de negócio.

Objetivos

Formar profissionais capazes de diagnosticar e otimizar os processos de negócio, proporcionando uma vantagem competitiva sustentável pela facilidade de reavaliação e reorientação da atuação da empresa.

Capacitar os participantes a desenhar processos de negócio com a Business Process Modeling Notation, utilizando ferramentas de código aberto que podem ser instaladas em seus computadores.

Público-alvo

Gerentes, supervisores e responsáveis por processos, planejamento estratégico, desenvolvimento de novos negócios, qualidade e projetos.

Profissionais envolvidos com iniciativas relacionadas à evolução e otimização de processos de negócio.

Profissionais de Tecnologia da Informação envolvidos com a automação de processos de negócio.

Didática

O treinamento tem enfoque totalmente prático, facilitando o entendimento e a aplicação dos métodos através de aulas expositivas, exercícios práticos e simulações com software Open Source.

Conteúdos

Estratégia e os processos (POR QUE?)
Elementos da notação BPMN (QUE É?)
Metodologia para modelagem de processos (COMO?)
Módulo Extra:

Planejamento da implementação do novo modelo de operação e automação dos processos
Apresentação de um caso real de projeto desde o desenho em BPMN até a execução em BPEL e monitoramento de indicadores do processo com BAM.

Inscrições

As inscrições poderão ser realizadas diretamente pelo site.
10% de desconto para inscrições antecipadas, para mais de uma inscrição no mesmo pedido ou associados da ABPMP.org.

Locais e Datas

PORTO ALEGRE

Corporate Station - Moinhos de Vento

09 e 10 de junho de 2008

SÃO PAULO

Mercure Privilege - Moema

12 e 13 de junho de 2008

Horário: das 08:30 às 18:00 horas

Carga Horária: 16 horas

A inscrição inclui: Conteúdo em CD, material didático em português, coffee-breaks e certificado.

Cada participante deverá portar seu próprio notebook. Configuração mínima: 1.4 GHz 512MB RAM.

Este treinamento é pré-requisito para Automação de Processos com BPEL.

Dispomos também de treinamento In company com local, datas e horários flexíveis.

Mais informações

www.projeler.com.br
contato@projeler.com.br
Tel 51 2117 1872 | 11 3717 5271 Skype projeler

PROJELER

Av. Getúlio Vargas, 901/1302
90150-003 Porto Alegre-RS

Coldfusion 8 conversando com Intalio BPMS

2008-04-29T17:02:00.001-03:00

Depois de muitas tentativas de fazer o Coldfusion conversar com o BPMS da Intalio, entre elas, usar Proxy de webservices, da WSO2 OxygenTank, (http://wso2.org/projects/esb/java) que na tentativa de filtrar o que estava provocando erros no axis do Coldfusion, acabou não funcionando, pois o problema eram os BUGs do próprio Axis da Apache.

Eu ia construir uma série de webservices em C# que funcionassem como Proxy, convertendo as chamadas do Intalio BPMS para o Coldfusion e vice versa. Mas o empreendimento seria grande demais, pois a cada manutenção do de qualquer serviço tanto de um lado como do outro, deveria ser feita manutenção no meio também.

Então tomei uma decisão radical: mergulhar no código fonte do Axis (disponível na Apache em http://svn.apache.org/viewcvs.cgi/webservices/axis/trunk/) e tentar corrigir seus problemas perante o Intalio. Eu já sabia que o problema era ele, pois sua tecnologia foi substituída pelo Axis2, mas o Coldfusion continua usando a versão 1.

No site da apache (https://issues.apache.org/jira/browse/AXIS) mostra todos os bugs conhecidos e corrigidos do Axis, e encontrei um relacionado com o problema que tive, relacionado com as declarações <SOAP:FAULT>.

Comecei a fazer testes nos fontes do Axis e encontrei vários pontos que provocavam problemas.

O Coldfusion lida com webservices gerando códigos em Java de cada um dos serviços, e essa geração é feita pelo axis usando o comando WSDL2Java.

Ao gerar os fontes em Java para o Coldfusion, o axis falhava na geração de nomes de classes os mesmos não compilavam dentro do CF.

Fui eliminando os problemas um por um e acabei chegando a um ultimo, uma função chamada getAttachments dentro da classe stub.java – sempre que compilava o wsdl para Java conflitava essa função. O problema era a chamada do serviço TaskManagementService do Intalio, que tem uma operação com o mesmo nome, e o axis acabou gerando esse método com o mesmo nome do herdado, provocando um conflito de heranças.

Esse eu também corrigi, e agora estou usando um AXIS personalizado dentro do ColdFusion 8 (funciona no 7 tambem).

Se alguém tiver o mesmo problema é só me pedir que eu mando o pacote do Axis para testar.

Fernando Francisco de Oliveira

Analista de Suporte - TI

Dental Morelli

ColdFusion MX7/8 vs Intalio BPMS - Round II

2008-04-04T10:16:00.000-03:00

Mais divergências nas comunicações de serviços :

· O Intalio BPMS usa as ultimas versões dos softwares de serviços da Apache, o Axis2.

· O Coldfusion MX7 e 8 ainda usam o Axis Versão 1 – Versão 1.2/1.3/1.4

Isso faz com que os serviços de webservices gerados no Intalio, gerados pelo Axis2, sejam mal interpretados pelo Coldfusion, não reconhecendo os elementos <soap:fault> existentes nas chamadas das funções que tem manipulação de erros:

TaskManagementServices

Isto é devido a um bug no Axis, relativo a manipulação do protocolo Soap 1.2, conforme encontrei no JIRA:
https://issues.apache.org/jira/browse/AXIS-2614

Eu baixei os fontes do Axis e corrigi o bug mencionado, mas não solucionou o problema, pois ele passou, mas gerou erros em outras rotinas.

Toda vez que se faz uma chamada de um WebService pelo Coldfusion, que tem o Java como base, ele roda as rotinas para geração de classes (em Java) para acesso aquele serviço, usando as rotinas wsdl2java existentes no framework axis. O resultado do fonte gerado é um código Java que dá erro de semântica ao compilar. Então o processo para ai.

Vasculhando os fontes do axis, encontrei dezenas de entradas TODO, justamente em pontos que manipulam o protocolo Soap 1.2, com as mesmas características do ponto onde corrigi.

Fiz a tentativa de instalar o Coldfusion 8 dentro do servidor Apache Geronimo, acreditando que desta maneira ele faria uso do novo Axis (o 2), mas foi em vão, pois o Axis ainda vai para dentro da instalação do mesmo.

A próxima tentativa será a utilização de um Servidor Proxy de serviços que converta os formatos de protocolo, para tentar compatibilizar os serviços. Aguardem mais noticias:

Codificação zero

2008-03-28T10:02:00.000-03:00

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

2008-03-28T09:56:00.000-03:00

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

2008-03-28T09:54:00.001-03:00

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

2008-03-28T09:54:00.000-03:00

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

2008-03-28T09:53:00.000-03:00

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

2008-03-28T09:52:00.001-03:00

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

2008-03-28T09:52:00.000-03:00

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

BPMN: o Modelo E-R dos Processos

2008-03-28T09:28:00.000-03:00

Neste artigo, buscaremos apresentar a motivação para o nascimento do BPMN, suas principais características e seus possíveis impactos na modelagem de sistemas de TI.

A Torre de Babel dos Processos
Até muito recentemente, qualquer trabalho de modelagem ou redesenho de processos precisava, logo em seu início, tomar uma difícil decisão – definir qual técnica de modelagem de processos seria utilizada. Opções não faltavam – técnicas como Swimlanes, IDEF0, Event-Process Chain, Diagramas de Atividade UML e Redes de Petri eram apenas algumas delas.

Apesar de muito úteis e poderosas, estas técnicas compartilhavam alguns problemas: ou eram proprietárias, ou eram incompletas, ou eram incompatíveis com outros modelos, especialmente modelos de TI. E muitas vezes, elas eram tudo isso ao mesmo tempo. Mais: nenhuma delas era claramente um padrão para modelagem de processos, nem padrão de direito nem de mercado.

Além disso, (ou talvez por isso mesmo) a maioria dos processos eram (e ainda são) modelados usando notações “ad hoc”, inventadas sob demanda para cada projeto ou para cada empresa, em geral utilizando ferramentas de diagramação como o Microsoft Visio. Ou seja, modelavam-se processos que praticamente só conseguiam ser entendidos completamente por quem os havia modelado.

Evidentemente, é absolutamente impossível, em um cenário como esse, tentar fazer avançar o BPM. Pois, se não há uma uniformidade básica sobre como modelar processos de negócios, como poderá haver um entendimento claro sobre o funcionamento deste processo? Como ele poderá ser discutido com outras pessoas, redesenhado e automatizado, se ele utiliza uma notação que não é padronizada?

Para termos a correta dimensão deste paradoxo, podemos fazer uma simples analogia com a área, muito bem estabelecida, de banco de dados. Será que esta disciplina conseguiria ter alcançado o sucesso que tem se não existisse uma notação universalmente aceita como o Modelo Entidade-Relacionamento? Como seria o mundo da TI se, cada vez que fôssemos modelar um banco de dados, tivéssemos que primeiro definir qual técnica de modelagem iríamos usar (ou pior, se inventássemos nossa própria notação para cada projeto!).

Absurdo? Bem, esse era o ambiente que, até bem pouco tempo atrás, aguardava quem precisava modelar e automatizar processos de negócio.

BPMN: A Resposta Certa ao Desafio
O BPMN (Business Process Modeling Notation) é um padrão para modelagem de processos. Criado inicialmente pelo BPMI (Business Process Management Initiative), foi incorporado pela OMG (Object Management Group) após a fusão entre estas entidades, ocorrida em 2005.

O enorme sucesso do BPMN em se estabelecer como padrão para o BPM vem de três razões principais. A primeira é que foi sempre um objetivo fundamental seu oferecer uma notação de fácil entendimento por todos os envolvidos com processos. Assim, tanto usuários de negócios quanto profissionais de TI conseguirão facilmente ler um modelo de processos em BPMN. Desta forma, o BPMN torna-se, na prática, uma ferramenta que cria uma língua comum entre as áreas de negócios e TI, reduzindo a distância existente entre elas.

A segunda razão é que o BPMN foi dotado de uma série de recursos que tornam possível a modelagem de processos extremamente complexos. O uso de tais recursos é opcional e, assim, o modelo pode ser construído apenas com os elementos mais simples, para facilitar a leitura. Ao utilizar estes recursos, pode-se chegar a um nível bastante refinado do comportamento do processo, agregando várias informações técnicas, e permitindo o mapeamento automático para padrões de execução de processos, como o BPEL. Assim, se consegue uma transição natural da modelagem para a execução dos processos.

A terceira razão para o sucesso do BPMN é que ele possui uma sólida fundamentação matemática. O BPMN foi construído sobre os conceitos do Pi-Calculus, uma derivação do Cálculo de Processos para a representação de processos dinâmicos e móveis. Mais uma vez, a analogia com banco de dados é pertinente, pois uma das grandes razões do sucesso dos bancos de dados relacionais foi seu embasamento na teoria relacional.

Primeiros Passos em BPMN

O BPMN define um único tipo de diagrama, chamado de Business Process Diagram (BPD). Neste diagrama, como ilustrado na figura, são dispostos os diversos elementos que formam o BPMN.

O BPMN possui diversos elementos, sendo que os básicos são apenas 4: atividades, eventos, gateways (decisões) e sequence flows (rotas). Com apenas estes 4 elementos, é possível construir modelos bastante expressivos de processos, fazendo com que o BPMN seja efetivamente fácil de aprender e simples de utilizar.

À medida que coletamos mais dados sobre o processo a ser modelado, podemos utilizar as diversas variações destes elementos, cada uma com uma semântica precisa (por exemplo, eventos baseados em tempo). Podemos também adicionar novos elementos que enriquecem a semântica do processo.

Assim, de forma geral, um modelo BPMN nos permite representar os seguintes conceitos:

Processos, sub-processos e atividades
Loops, instanciação múltipla de atividades e transações de compensação
Eventos de início, de fim e intermediários no processo (ex: um processo pode iniciar a partir do evento “Email vindo do cliente”)
Decisões, paralelismo e sincronização de processos
Organizações, departamentos e papéis que participam do processo
Trocas de mensagens entre organizações participantes do processo (essencial para representar cenários B2B)
Objetos de dados que tramitam ao longo do processo

Com estes recursos, o BPMN permite a criação de modelos excepcionalmente sofisticados – com a vantagem adicional de poderem ser facilmente compreendidos.

O Caminho Adiante
Hoje, não há mais nenhuma dúvida que o BPMN é a técnica de modelagem preferencial para qualquer projeto de BPM. O uso de outras técnicas deveria ser considerado apenas em casos excepcionais, tais como aqueles em que há um grande legado de processos modelados em outras técnicas. Caso contrário, não há boa razão para não usar o BPMN.

Nós, da iProcess, já pudemos experimentar na prática os benefícios da facilidade de uso do BPMN. Já temos utilizado a técnica para discutir modelos de processos com usuários de negócio de clientes, com excelentes resultados. Na visão dos usuários, a notação é clara e intuitiva, sendo compreendida de forma praticamente instantânea. O que mais podemos querer de uma técnica de modelagem?

Além disso, não podemos deixar de analisar o significado da fusão entre o BPMI (criador do BPMN) com a OMG (mantenedora de diversos padrões, como UML e CORBA). A verdadeira questão está no desejo de ambas organizações de incorporar o BPMN na UML. Como se sabe hoje, a UML não conta com técnicas apropriadas para a modelagem de processos, e o BPMN virá justamente cobrir esta lacuna. Assim, muito em breve, teremos o BPMN como parte da mais difundida técnica de modelagem de sistemas do mundo. Se alguém ainda tinha dúvidas sobre a importância da modelagem de processos para a concepção de sistemas, este fato deve eliminá-las.

Por tudo isso, demos a este artigo o título acima. Acreditamos que a relevância do BPMN para o BPM será a mesma do Modelo Entidade-Relacionamento para banco de dados. O BPMN será a técnica que permitirá que a modelagem de processos seja ensinada, divulgada e promovida em massa, no mercado e nas universidades. Em outras palavras, que deixe de ser uma atividade secundária, quase um nicho, para se tornar uma ferramenta indispensável para profissionais de negócios e de TI.

Extraído de http://www.iprocess.com.br/newsletter/2/index.htm

Modelagem de Processos com BPMN

2008-03-28T09:24:00.000-03:00

Competir, vencer, satisfazer os clientes e trazer lucratividade significa para uma organização nos dias de hoje, gerenciar bem os processos de negócio. Inicie por uma modelagem dos processos intuitiva, precisa e rica em detalhes.

Este artigo é o primeiro de uma série que tem como objetivo introduzir a Business Process Modeling Notation. Esta notação permite diminuir as distâncias entre o mapeamento dos processos nas áreas de negócio e a adaptação técnica destes processos na TI, criando assim, um "idioma comum" de entendimento dos requisitos alinhados com os objetivos do negócio.

O que é BPMN?

A Business Process Modeling Notation (BPMN) está se consolidando como o mais importante padrão de notação gráfica aberta para desenhar e modelar processos de negócios. Com ela é possível modelar os processos de negócio capturando e documentando modelos atuais (AS-IS) em diagramas de fácil entendimento, projetar e descrever modelos ideais (TO-BE), estender detalhes técnicos, monitorar e mensurar o negócio com indicadores de desempenho baseados nas atividades dos fluxos de processos automatizados.

O objetivo do desenho é ser de entendimento rápido por todos os usuários de negócio, para que permita aos analistas criarem seus primeiros esboços dos processos e os arquitetos de TI e desenvolvedores adaptem os processos a serem gerenciados e monitorados.

História

Com o objetivo de criar padrões e uma arquitetura comum para gerenciamento de processos de negócio, foi criada a Business Process Management Initiative (BPMI, http://www.bpmi.org), uma organização sem fins lucrativos, iniciada pela Intalio Inc. em 2000 e que recebeu imediatamente o suporte de gigantes da indústria como a IBM, SAP, BEA, Fujitsu, WebMethods e IDS Scheer.

Em agosto de 2001, o Business Process Modeling Notation Working Group (BPMN-WG), da BPMI.org, foi formado por 35 empresas e iniciou os trabalhos para criar a BPMN. A versão 1.0 da especificação escrita por Stephen White da IBM saiu em maio de 2004 e rapidamente se estabeleceu como notação padrão para modelar processos executáveis de negócio. Em junho de 2005, a BPMI anunciou sua junção a OMG (Object Management Group), associação sem fins lucrativos que desde 1989 desenvolve e mantém padrões e especificações, dentre elas, a notação UML. Segundo a OMG, até abril deste ano, existem quarenta e três fornecedores que suportam a notação e mais quatro estão em fase de implementação. A última especificação da BPMN é de fevereiro de 2006, mas uma nova versão provavelmente surgirá até o final de 2007.

Benefícios

Existem muitos softwares para BPM com notações diferentes e proprietárias. Ao contrário disso, a BPMN é simples e ao mesmo tempo muito poderosa e, principalmente, um padrão de mercado sem a necessidade de ficar preso a um determinado fornecedor.

O objetivo do desenho é ser de entendimento rápido por todos os usuários de negócio

A BPMN suporta orquestração de serviços e a execução de tarefas humanas do workflow, ao permitir coreografia de múltiplos processos de negócio. Além disso, possui o mapeamento para gerar as linguagens XML para execução de processos em BPML e BPEL diminuindo distâncias entre o desenho do processo e a sua automação.

Esta notação é excelente para desenhar os eventos de negócio necessários para se trabalhar na arquitetura orientada a serviços (SOA) e descrever como a organização responderá às suas exceções e regras de negócio, proporcionando assim, o refinamento de políticas ágeis da organização.

Permite às organizações se ajustarem rapidamente as novas circunstâncias internas e de B2B do negócio. Por meio da notação gráfica a compreensão do desempenho da colaboração entre seus departamentos e das transações de negócio com outras organizações torna-se facilitada. Os participantes dos processos de negócio poderão ser pessoas ou grupo de pessoas, sistemas de informação ou outro processo. Estes participantes são representados dentro do diagrama em BPMN por uma metáfora de piscinas e raias onde são identificadas as trocas de serviços, produtos, valores, transações, informações e conhecimento entre as clientes, fornecedores e parceiros da organização.

Conclusões

BPMN é, de fato, um padrão, utilizada por importantes empresas e possui uma boa variedade de ferramentas. No futuro, estão previstos diagramas de mais alto nível além de uma especificação para fazer o caminho inverso da linguagem de execução BPEL para a notação BPMN.

Maurício Bitencourt, PMP, é empreendedor em soluções BPM, Diretor Executivo e fundador da Projeler.

Extraído de http://www.baguete.com.br/artigosDetalhes.php?id=320

Intalio BPMS Server X ColdFusion MX 7.0.0

2008-03-14T08:21:00.000-03:00

Estive brigando com os servidores de BPMS e Coldfusion MX por vários dias: motivo:

O Coldfusion não estava aceitando conversar com o Intalio BPMS Server via WebService. Comportamento estranho, pois os dois foram construídos em Java, e utilizam a mesma plataforma de serviço WSDL : O Apache Axis

Enquanto o Axis do Intalio estava entregando um pacote SOA com header “Content-Type” com três parâmetros, o Axis do Coldfusion se recusava a aceitar o terceiro parâmetro.

Baixei os fontes do projeto da Intalio, através do site http://www.intalio.org/confluence/display/TEMPO/Home, e fui investigar se o cabeçalho era forjado ou não pelo serviço da Intalio. Descobri que eles apenas faziam uso das bibliotecas existentes da Axis, portanto o problema estava no próprio AXIS.

Procurei pelos fontes do Axis e vi que era padrão poder adicionar um parâmetro ACTION no Header “Content-Type”.

Fui analisar a versão do Axis usada no Coldfusion e descobri que ele estava usando a versão 1.2RC2 ! Olhando o arquivo c:\CFusionMX7\lib\axis.jar e dentro dele, usando um descompactador, na pasta META-INF o arquivo MANIFEST.MF dizia a versão 1.2RC2 de 2004.

Fui no site da Apache AXIS e baixei o mais recente axis.jar e substitui o que veio no Coldfusion.

Funcionou perfeitamente ! Agora os dois serviços estão conversando !

Mais noticias em breve.

Clinical Manager System - Versão Gratuíta MS-DOS

2008-02-28T17:51:00.000-03:00

· Apresentação do Sistema

O Sistema de Administração de Clínica CMS® é um instrumento poderoso no Controle das Tarefas em Clínicas Médicas, automatizando muitos processos manuais, disponibilizando mais tempo para outras tarefas.

Características do Sistema :

1. Controle da Agenda dos Médicos, com agendamento rápido sem necessidade de cadastrar o Paciente, o que é feito no dia da consulta; obedecendo o horário do médico na clínica e os dias de folga e feriados;

2. Controle da Agenda da Fisioterapia, permite limitar o número de fisioterapias simultâneas da clínica; permite registro das avaliações do fisioterapeuta por paciente;

3. Registro dos Serviços executados na Clínica, assim como as Taxas e Materiais utilizados nos serviços;

4. Cálculo automático do custo dos Serviços, baseados na Tabela de Serviços Médicos da AMB, considerando os Coeficientes de Honorários aplicados por cada convênio e as exceções de preços de Taxas e Materiais;

5. Cadastro de Pacientes, suas consultas e com verificação seus prazos de retorno, de acordo com o convênio;

6. Cadastro de Médicos, indicação de Convênios a qual o médico não é conveniado, para que a Clínica faça o repasse dos honorários; indicação da especialidade da consulta, para Clínicas com várias especialidades;

7. Cadastro de Anestesistas, com parametrização igual ao Médico, para indicação de quais convênios não é conveniado;

8. Cadastro de Serviços, seus preços em Real ou CH, permite indicar as exceções de preços por convênio para um serviço ou um grupo de serviços;

9. Cadastro de Materiais, assim como os serviços, os materiais podem ter preços diferenciados por convênio; Permite também fazer composição de materiais em outro material chamado Composto, permitindo criar materiais que variem o preço de acordo com seus componentes;

10. Cadastro do Código Internacional de Doenças (CID) para utilização no registro das consultas e atestados;

11. Cadastro de Farmacos para utilização na emissão de receitas.

12. Emissão o Faturamento Individualizado por Convênio de todos os serviços prestados pela Clínica, com os preços calculados de acordo com a tabela da AMB padrão mais as exceções aplicadas de cada convênio. Registra o faturamento nas Contas a receber automaticamente.

13. Controle das Contas a Pagar e Receber;

14. Recebimento no Caixa dos Pacientes particulares ou que seu convênio faz futuro reembolso, separa automaticamente o valor destinado aos honorários dos médicos e anestesistas dos honorários da clínica. O caixa deve ser zerado todos os dias;

15. Emissão de Recibos e atestados, através de textos de livre digitação para maior flexibilidade, controla os recibos emitidos por médico;

16. Registro da Consulta Médica com a indicação da anamnese, exame físico e o CID, inclusão de uma receita por consulta e o registro dos procedimentos efetuados.

17. Estatísticas Diversas

18. Controle de Usuários do Sistema, permite atribuir grupos de usuários a tarefas, restringindo o acesso de usuários às suas tarefas, permite bloqueio de funções dentro de certas opções, por usuário ou por grupo de usuários. Sistema de Mensagens interno ou externo do sistema.

· Requisitos Mínimos Recomendados para execução do Sistema CMS® :

¨ Para o Sistema Operacional MS-DOS

§ Processador i386

§ 4 Mbytes de Memória RAM ( O ideal é 16 Mbytes )

§ 5 Mbytes de espaço livre inicial de Disco Rígido

¨ Para o Sistema Operacional Windows 95

§ Processador Pentium

§ 16 Mbytes de Memória RAM ( O ideal é 16 Mbytes de Memória Virtual)

§ 5 Mbytes de espaço livre inicial de Disco Rígido

Opera em qualquer tipo de rede : Novell, Windows, Lantastic, etc.

Consulte a versão Gratuita do Sistema na Tork Informatica pelo site HTTP://www.tork.com.br

Nós não vemos necessidade para usar BPM

2008-02-26T10:20:00.000-03:00

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

Conduza o Caminho (fluxo de processos e dados)

2008-02-25T14:02:00.001-03:00

Qualquer ferramenta pode ser usada erroneamente, e eu acredito que esta é a razão pela qual muitos programadores odeiam BPM. Eles somente não sabem como as ferramentas BPM devem ser usadas... e eu adoraria corrigir esta situação.

Se você estudar Desenvolvimento orientado a Processos, você amará BPM. Se não você tentará usar as suas ferramentas BPM como um ambiente de desenvolvimento de aplicações tradicionais e acabará com um bagunça sem controle.

É tudo sobre processo...

Antes de começar o desenvolvimento, responda as seguintes perguntas na ordem:

1. Quais são os passos?

2. Quais são os possíveis caminhos para esses passos?

3. O que controla o caminho dos dados do processo ?

4. Como os dados fluem através do processo ?

Quanto você souber as respostas, então iniciará o seu desenvolvimento com o diagrama de processos e o usará para dirigir o caminho do desenvolvimento nesta ordem:

1. Modelar o fluxo do processo

2. Definir os dados que controlam o fluxo do processo.

3. Construa uma interface de usuário “suficiente” que permita manipular os dados necessários para navegar através de todos os caminhos do processo.

É abolutamente crítico que você faça estes passos para construir o seu projeto... e uma vez que estiver pronto, faça o seguinte:

Passe por TODOS os caminhos do processo com o seu Cliente de Negócios.

Se você seguir todos estes passos, então fará mostrar todas as falhas do fluxo do processo muito tempo antes de qualquer codificação em uma LINDA interface que estará ERRADA.

O processo deverá guiar a Interface do Usuário, mas muitas vezes gastamos tempo mostrando uma tela sexy para os clientes, nos levando a um modelo de processo ruim. Todos nós cometemos esta falha, e nós sabemos por experiência própria que isso estraga todo o resto do ciclo de vida do projeto.

Sim... o desenvolvimento de interface em algumas ferramentas BPM frequentemente requer esforços sobre-humanos para cconstruir uma tela bonita com AJAX, e é freqüente você acabar construindo telas bonitas usando ferramentas complementares. Mas não é por isso que alguns projetos BPM falham...

Projetos BPM falham quando o time do projeto não segue os passos de Design orientado a Processos que demonstrei no inicio do artigo. Se você tem tido problemas com BPM... tente do meu jeito na próxima vez. Eu creio que você ficará gratamente surpreso se o fizer.

Extraído e traduzido do original em Inglês de John T. Reynold em http://thoughtfulprogrammer.blogspot.com/2008/02/drive-path-process-and-data-flow.html

Porque programadores Java odeiam BPM?

2008-02-25T11:57:00.001-03:00

Programadores Java odeiam BPM.

A seqüencia acima foi intencionalmente elaborada para ser controvérsia. As pessoas tendem a ler blogs controversos, e eu gostaria que lesse este. Agora que eu tenho sua atenção, gostaria de pedir que lesse o resto.

Muitos programadores Java odeiam ter que usar ferramentas BPM ao invés das ferramentas orientadas ao objeto que estão acostumados.

Eu trabalho em muitos projetos BPM, e também com muita gente que trabalha também com outros muitos projetos BPM, e eles tem encontrado resistência dos programadores Java tradicionais. Programadores Java (em geral) usariam seu framework “Struts and Spring” ao invés de ficarem presos ao pacotes BPM.

Frameworks Java como “Struts and Spring” são a infraestrutura... eles provem suporte necessário para “sua livre criatividade”, então eles podem ser verdadeiros programadores. Você pode construir qualquer coisa com “Struts and Spring” (se voce já for mestre nas entranhas do JAVA). Eles são leves, eles são ágeis, e parecem sexys para resumir.

Pacotes BPM estão na sua cara, eles roubam a sua criatividade. Eles ditam como você irá desenvolver a sua aplicação.

Pacotes BPM são chatos. Eles forçam você a usar ferramentas aponte-e-clique ou arraste-e-solte para desenhar seus diagramas de processos, modelos de dados e formulários. O que é pior, eles encorajam o pessoal de negócios a modelar processos e desenhar formulários eles mesmos... Felizmente o pessoal de negócios é muito intimidado com essas ferramentas, mas abre as portas para eles olharem sobre nossos ombros e se meterem em nosso trabalho.

Isto realmente não parece algo que programadores realmente gostam, não é ?

Pacotes BPM são ameaças aos programadores JAVA tradicionais. Estes pacotes estão longe de serem perfeitos, mas até mesmo no estado atual podemos ver para onde as coisas estão andando. Os dias em que o Guru Java era indispensável estão sumindo... Nós nos acostumamos a usar Java para construir ferramentas que conhecer o Java propriamente dito era menos importante, e isto abriu lugar para competição de pessoas que não gastaram anos aprendendo Java.

Nós somos vitimas de nosso próprio sucesso... e isto nos sairá caro.

É por isso que Programadores Java odeiam BPM.!

Extraído e traduzido do original em Inglês de John T. Reynold em http://thoughtfulprogrammer.blogspot.com/2007/10/why-do-java-developers-hate-bpm.html

ENC: [NS] Modelagem de Processos com BPMN

2008-02-15T08:28:00.000-02:00

Modelagem de Processos com BPMN

Aprimore processos de negócio e resultados com a Business Process Modeling Notation

A décima edição do treinamento Modelagem de Processos com BPMN da PROJELER vai capacitar profissionais a trabalhar com a Business Process Modeling Notation, a mais nova e avançada notação para representar graficamente os processos de negócio.

Objetivos

Capacitar os participantes a desenhar processos de negócio com a Business Process Modeling Notation, utilizando ferramentas de código aberto que podem ser instaladas em seus computadores.

Público-alvo

Gerentes, supervisores e responsáveis por processos, planejamento estratégico, desenvolvimento de novos negócios, qualidade e projetos.

Profissionais envolvidos com iniciativas relacionadas à evolução e otimização de processos de negócio.

Profissionais de Tecnologia da Informação envolvidos com a automação de processos de negócio.

Didática

O treinamento tem enfoque totalmente prático, facilitando o entendimento e a aplicação dos métodos através de aulas expositivas, exercícios práticos e simulações com software Open Source.

Conteúdos

Introdução à modelagem de processos
Análise da estratégia e desdobramentos nos processos
Metodologia para modelagem de processos
Elementos da notação BPMN
Melhores práticas e padrões avançados
Planejamento da implementação do novo modelo de operação e automação dos processos

Inscrições

As inscrições poderão ser realizadas diretamente pelo site.
Descontos de 10% para inscritos até o dia 29/02 e para mais de uma inscrição no mesmo pedido.

Locais e Datas

PORTO ALEGRE

Corporate Station - Moinhos de Vento

10 e 11 de março de 2008

SÃO PAULO

Mercure Privilege - Moema

17 e 18 de março de 2008

Horário: das 08:30 às 18:00 horas

Carga Horária: 16 horas

A inscrição inclui: Conteúdo em CD, material didático em português, coffee-breaks e certificado.

Cada participante deverá portar seu próprio notebook. Configuração mínima: 1.4 GHz 512MB RAM. Configuração recomendada: 2.0 GHz 1GB RAM. Necessária rede sem fio (wireless).

Este treinamento é pré-requisito para Automação de Processos com BPEL.

Dispomos também de treinamento In company com local, datas e horários flexíveis.

Mais informações

www.projeler.com.br
contato@projeler.com.br
Tel 51 2117 1872 | 11 3717 5271
Skype projeler

PROJELER

Av. Getúlio Vargas, 901/1302
90150-003 Porto Alegre-RS

Automação de Processos com BPEL

2007-12-17T09:10:00.001-02:00

Abaixo o conteúdo programático do segundo curso :

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

Conheça como a Arquitetura Orientada a Serviços (SOA) poderá reduzir gastos com desenvolvimento, trazer flexibilidade em relação a adoção de novas práticas de negócio e reutilização de serviços.

Com a orquestração de serviços da BPEL os componentes de software são facilmente localizados e reutilizados, conforme a adaptação dos processos de negócio, proporcionando um menor tempo de resposta às demandas com a conseqüente redução de custos com desenvolvimento.

O treinamento Automação de Processos com BPEL da PROJELER vai capacitar profissionais a trabalhar com a linguagem BPEL 2.0 a partir de modelos desenhados na notação BPMN. A BPEL (Business Process Execution Language), como o próprio nome sugere, é uma linguagem para a definição e execução de processos de negócios que vem ganhando força ao estabelecer um novo padrão mundial de gestão competitiva.

Objetivos

Formar profissionais capazes de automatizar os processos de negócio a partir da modelagem em BPMN

Proporcionar maior fluidez das informações com o conseqüente aumento da velocidade das operações da empresa.

Benefícios

Melhor integração entre pessoas, sistemas e processos.

Coordenação mais automática dos fluxos de trabalho.

Público Alvo

Analistas de Processos envolvidos com a modelagem de processos e o gerenciamento dos projetos nesta área.

Engenheiros de software envolvidos na criação de SOA para integração com os processos.

Profissionais de Tecnologia da Informação envolvidos com a automação de processos de negócio.

Didática

Neste treinamento serão realizadas dinâmicas para gerar aplicações em BPEL, envolvendo a integração de BPEL4People para as atividades humanas e WebServices para integração dos sistemas.

O treinamento tem enfoque prático e é realizado por meio de aulas expositivas, exercícios práticos e simulações em computador com Software Open Source para facilitar o entendimento e a aplicação dos métodos.

Instrutor

Maurício Bitencourt: Formado em Administração de Empresas com Ênfase em Análise de Sistemas de Informação (PUCRS) e Project Management Professional (PMP) certificado pelo PMI. Trabalha há 18 anos na área de Tecnologia da Informação, atuando no desenvolvimento de sistemas administrativos, financeiros e comerciais para diversos ramos de negócios. É sócio-diretor da Projeler.

Conteúdos

Introdução à programação orientada a processos

Fundamentos do XML e mapeamento dos dados do processo com XPath

Geração automática de serviços a partir de acessos a bases de dados SQL

Integração dos sistemas e atividades humanas com os processos

Geração de código BPEL a partir da modelagem do processo em BPMN

Execução, monitoramento e administração das instancias no servidor de processos

Carga horária: 16 horas

Curso de Modelagem de Processos com BPMN

2007-12-17T09:09:00.001-02:00

Abaixo o conteúdo programático do primeiro curso :

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

O treinamento Modelagem de Processos com BPMN da PROJELER vai capacitar profissionais a trabalhar com a Business Process Modeling Notation, a mais nova e avançada notação para representar graficamente os processos de negócio.

Objetivos

Formar profissionais capazes de diagnosticar e aperfeiçoar os processos de negócio, proporcionando uma vantagem competitiva sustentável a partir da facilidade de reavaliação e reorientação da atuação da empresa.

Capacitar os participantes a desenhar processos de negócio com a Business Process Modeling Notation, utilizando ferramentas de código aberto que podem ser instaladas em seus computadores.

Benefícios

Formalizar processos existentes e levantar necessidades de melhoria. O direcionamento dos esforços para formalizar e entender os processos permite diminuição de gargalos, remoção de etapas, automação de fases manuais e, se necessário, a reengenharia integral ou parcial dos fluxos.

Facilitar a automação eficiente do fluxo do processo. O processo é decomposto em múltiplas atividades com o estabelecimento de um tempo menor entre cada uma delas elas. As atividades passam a ser executadas em paralelo, e seus resultados podem ser posteriormente sincronizados no processo.

Liberar as pessoas para atividades mais relevantes. Com a automação dos processos, é possível aproveitar melhor os recursos humanos da empresa, que ganham tempo para se dedicar a atividades mais relevantes, bem como a novas oportunidades.

Simplificar questões de órgãos reguladores e de conformidade. A formalização dos processos facilita auditorias e ajuda as organizações a atender vários requisitos de regularização.

Público Alvo

Profissionais envolvidos com iniciativas relacionadas à evolução e otimização de processos de negócio.

Gerentes, supervisores e responsáveis por processos, planejamento estratégico, desenvolvimento de novos negócios, qualidade e projetos.

Profissionais de Tecnologia da Informação envolvidos com a automação de processos de negócio

Didática

O treinamento tem enfoque totalmente prático, facilitando o entendimento e a aplicação dos métodos por meio de aulas expositivas, exercícios práticos e simulações com Software Open Source.

Instrutor

Conteúdos

Introdução à modelagem de processos

Análise da estratégia e desdobramentos nos processos

Metodologia para modelagem de processos

Elementos da notação BPMN

Melhores práticas e padrões avançados

Planejamento da implementação do novo modelo de operação e automação dos processos

Carga horária: 16 horas

Procura por BPM

2007-12-11T22:24:00.000-02:00

Na empresa, fui designado para pesquisar ferramentas para desenvolvimento de um projeto que inicialmente pensava-se, ser apenas um workflow de atividades.

Com base nos requisitos do mesmo, encontrei várias ferramentas que possibilitavam a implementação parcial, daí descobri que as necessidades iam além do workflow precisamos mesmo é de Automação de Processos via BPM.

Então voltei o foco da pesquisa para ferramentas de modelagem de processos e motores (engines) de orquestração.

Entre vários produtos disponiveis encontrei primeiramente o uengine (http://www.uengine.org), que se mostrou um produto interessante, mas colocar os negócios da empresa em um produto sem suporte não é algo aceitável.

Voltei a procurar e encontrei a Intalio (www.intalio.com) que fornece várias versões do produto, desde a versão gratuíta, com suporte pela comunidade, como versões de suporte 24x7.
Baixei o engine da intalio em http://bpms.intalio.com e comecei a testar. O designer é baseado no Eclipse (www.eclipse.org) e a modelagem segue o padrão BPMN 2.0.

Ainda assim tive dificuldades para entender o seu funcionamento e seus recursos.
Com essa necessidade, é que participei do curso de Modelagem de Processos com BPMN e Automação de Processos com BPEL, dado pela Projeler, em São Paulo.

Posso dizer que os cursos deram material teórico e prático que faltava para iniciar as implementações que necessitamos.
Ainda temos muito que aprender, mas a vida é um eterno apredizado. Vamos em frente e mão na massa.

Curso de Modelagem

2007-12-05T11:01:00.001-02:00

Semana passada fiz um curso de Modelagem de Processos em BPMN e Automação de Processos com BPEL na Projeler.

Foi o inicio deste blog.