terça-feira, 16 de setembro de 2008

Hospedagem na Web Grátis

 

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.

terça-feira, 20 de maio de 2008

Modelagem de Processos com BPMN 1.1

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

 

Tela ®Intalio|BPMS Designer 5 Community Edition - Todos os direitos reservados. - www.intalio.comA 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

 

terça-feira, 29 de abril de 2008

Coldfusion 8 conversando com Intalio BPMS

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

 

sexta-feira, 4 de abril de 2008

ColdFusion MX7/8 vs Intalio BPMS - Round II

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:

 

sexta-feira, 28 de março de 2008

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

 

BPMN: o Modelo E-R dos Processos

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

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

 

sexta-feira, 14 de março de 2008

Intalio BPMS Server X ColdFusion MX 7.0.0

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.

quinta-feira, 28 de fevereiro de 2008

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

·         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