BPM Na Veia

Service Oriented Reference Architecture – Parte 1 ½

“Qual a diferença de SOA para algo que já se fala ha muito tempo: programação (e arquitetura de aplicações) orientada a objetos (e/ou componentes)?” Esse (primeiro) comentário no nosso blog (Obrigado Mário!) me levou a entender que a visão sobre o que é uma arquitetura orientada a serviço (SOA) tem ainda não está consolidada, nem entre clientes, nem entre fornecedores. Para resolver isso resolvi criar um item 1 ½ para tentar explicar melhor esse tópico.

Quando desenvolvi meu primeiro sistema (num Apple II+, no bom e velho BASIC) tive muito trabalho, como todos que trabalharam com essa linguagem, para controlar uma quantidade imensa de GOTO’s e JUMP’s dentro do código. E não passava de um mero sistema de automação de oficina eletrônica (daquela época que as TVs apresentavam alguns problemas por ano). Mas foi exatamente assim que surgiu a programação: SEQUENCIAL. Um bloco único de código de executava do início ao fim a finalidade do programa.

Nessa época, a cadeia de valor das empresas ainda era muito restrita. Mesmo os mainframes dessa época trabalhavam com sistemas focados em uma única área: folha de pagamento, controle de estoque, etc.

Logo depois inventaram uma revolução: functions ou procedures. A programação PROCEDURAL foi um grande marco na computação: a possibilidade de reutilizar funções dentro do mesmo programa era algo incrível. Não precisávamos mais gerenciar aqueles laços de GOTO que eram responsáveis por boa parte do bugs.

Mesmo assim, com o aumento da complexidade dos sistemas, a quantidade de linhas de código levou à conclusão que seria mais fácil arrumar uma forma de deixar essas funções em módulos (vários arquivos fonte) que, em tempo de compilação, seriam resolvidos. Chegávamos ao estado da arte (na época): a programação MODULAR.

Esta ainda começou a evoluir de forma espantosa: primeiro as bibliotecas de funções de vinculação estática (em tempo de compilação, as .LIB) e depois bibliotecas de vinculação dinâmica (as conhecedidas .DLL). Naquela época não haveria mais para onde evoluir.

Neste momento da história as cadeias de valor das empresas começaram a ficar mais complexas, demandando, além de sistemas mais complexos, maior agilidade por parte do analistas e desenvolvedores.

Foi no início dos anos 90 quando apareceu um conceito que quebraria alguns paradigmas: A PROGRAMAÇÃO ORIENTADA A OBJETOS. Este era um conceito dos anos 60 que ainda não tinha tido espaço para implementação. A POO tinha como enfoque unidades de programação discretas (objetos) ao invés da programação estruturada normal. O foco da programação estruturada sempre foi a estrutura (óbvio) enquanto a POO se preocupava mais com o comportamento e com os dados. Fazendo um comparativo com a estória da evolução da eletrônica, chegávamos na era dos circuitos integrados: unidades específicas de processamento com comportamento definido, entradas específicas e saídas dependentes dos estados das entradas.

A POO já possibilitava um grande aumento da produtividade e reuso de software mas, para nossa infelicidade (ou felicidade) agora tínhamos a necessidade de fazer com que programas distintos conversassem entre si.

Aqui as cadeias de valor começaram a demandar maior troca de dados entre os diversos sistemas para agilizar os processos de negócios e tornando as empresas mais competitivas.

Entra em cena neste momento o EAI (Enterprise Application Integration). Um conjuntos de princípios arquiteturais e ferramentas (ou middleware) para promover a comunicação entre aplicativos distintos. Dentre as ferramentas destacam-se os MOM (messaging oriented middleware), camadas de software que se encarregavam das complexidades de transmitir uma mensagem da origem ao destino. Inicialmente a infra-estrutura de EIA trabalhava com integração ponto-a-ponto, o que não representava grande problema quando trabalhávamos com um número pequeno de entidades, como na figura 1 abaixo.

O sistemas de estoque tem duas interfaces: uma para o sistema de folha de pagamento (I1) e outra para o sistema de contabilidade (I6), os outros dois sistemas têm também duas interfaces cada. O número total de interfaces nesse cenário é de (somente) seis!

O problema aconteceu quando um grande número de aplicações com necessidades de intercomunicação começou a aparecer. O número de interfaces começou a ficar inviável.

A grande preocupação era o crescimento exponencial do número de interfaces. Para n aplicações, são necessárias n*(n-1) interfaces. Isso signifca que para integrar 5 sistemas, conforme a figura 2, são necessárias 5*(4)= 20 interfaces. Já para integrar 20 sistemas (o que é uma quantidade razoável de sistemas para uma empresa de médio/grande porte) são necessárias 380 interfaces!

Mais uma vez, as mentes brilhantes da computação resolveram essa complexidade de uma forma espetacular: a criação de um modelo HUB AND SPOKE. A figura 3 representa esse modelo onde, um componentes central de middleware é responsável pela transformação, mediação e roteamento das mensagens.

Esta solução prometia durar muito tempo. E durou! Os conhecidos integradores ou brokers desempenharam um papel fundamental por muitos anos, integrando sistemas de todos os tipos.

A diversidade de tecnologias suportando as cadeias de valor em conjunto com a necessidade de interconexões extra-empresa levaram à criação de um modelo mais flexível de integração entre aplicações: a CORBA.

Uma outra tecnologia importante começou a nascer: a CORBA (Common Object Request Broker Architecture). Corba é a arquitetura padrão criada pelo Object Management Group (OMG) para simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software encontradas, a CORBA atuava de modo que os objetos (componentes dos softwares) pudessem se comunicar de forma transparente ao usuário, e o mais transparente possível também para o desenvolvedor.

A CORBA definia o ORB (Object Request Broker) como um módulo intermediário entre cliente e objeto, sendo responsável em aceitar a requisição do cliente, enviá-la para o objeto competente e, assim que disponível a resposta, entregá-la para o cliente. Definia também a IDL (Interface Definition Language), uma linguagem baseada em C++ que não possuia algoritmos nem variáveis, ou seja, puramente declarativa independente da linguagem de programação utilizada para acessá-la. Possibilitava a interoperabilidade entre os diversos sistemas, visto a separação que é definida entre interface e execução. A interface de cada objeto é definida de forma bastante específica, enquanto sua execução (código fonte e dados) permanece oculta para o resto do sistema.

Com o advento da linguagem Java os conceitos de CORBA ainda foram utilizados para implementar a invocação remota de métodos (RMI – remote method interface). RMI eram formas de invocar componentes Java existentes em outras máquinas. A grande vantagem era que a RMI desonerava o programador da complexidade dessa programação.

A figura 4 demonstra a facilidade que o modelo de invocação remota trouxe. O programador (usuário) se preocupada basicamente com o desenvolvimento da aplicação enquanto a infra-estrutura CORBA e a ferramenta de desenvolvimento se encarregavam da comunicação.

O modelo RMI foi amplamente implementado quando a linguagem Java foi atualizada para sua versão corporativa: J2EE (Java 2 Enterprise Edition). A invocação de EJB (Enterprise Java Beans) sempre utilizou uma infra-estrutura de RMI. Os EJB eram abtrações de estados (session beans) e de dados (entity beans).

Quando a cadeia de valor das empresas chegou à internet a linguagem JAVA ganhou importância com sua afinidade com esse ambiente. Especialmente quando a internet deixou de ser uma vitrine e começou a ser efetivamente um canal de negócios.

A arquitetura J2EE também implementou diversos mecanismos de conexão a ambientes não-java como o JCA (Java Connector Architecture) e o JMS (Java Messaging Services) e esses, até então, estão suprindo as necessidades de integração da plataforma Java.

Entretanto, alguns fatores de negócio estão ganhando importância, demandando uma nova visão de tecnologia:

• Necessidades de redução de custos com manutenção de aplicações;

• Demandas de negócio cada vez mais complexas o que gerando aplicações igualmente complexas;

• Competitividade obrigando as empresas a reduzir o time-to-market de seus produtos e serviços;

• Necessidades regulatórias que demandam acesso mais complexo às infomações.

Para atender a esses novos princípios foi concebida a arquitetura orientada a serviços – SOA.

João Luiz Pereira Junior

BPM é Responsabilidade de Todos

Soa estranho esse título, não é? Quando escrevi, lembrei das campanhas de combate à dengue ("Combater o mosquito é dever de todos")... rsrsrs...

Pensando no tema deste blog, O que eu quero dizer com isso é que o conceito BPM é muito mais que, simplesmente, um novo jargão do pessoal de TI e que, invariavelmente, essa turma gosta de usar em conversas.

Vamos entender um pouco mais o desenho abaixo, sem pensar muito em tecnologia ou ferramentas:

CICLO DE VIDA SOA

Supondo que a "porta de entrada" para a implantação de um processo de negócio - e esquecendo que a palavra implementação pode estar associada a desenvolvimento de sistemas - temos as etapas de definição do processo (modelagem), implementação do processo "na cabeça das pessoas" (assembly), execução do processo (deploy) e acompanhamento (monitor).

Agora, vamos lembrar um pouco de um dos 1os posts deste blog (veja aqui). Lembro que comentei que BPM são procedimentos que sempre existiram nas organizações, bem ou mal seguidos, mas muito antes de pensarmos em computadores ou coisa parecida. É natural, portanto, já falarmos em envolvimento de alguém responsável pelo processo diretamente no projeto e não, simplesmente, tratá-lo como um "usuário" ou "cliente" do projeto (coisa extremamente comum dos projetos de TI).

O que tenho visto em alguns lugares que discutem BPM é um certo "descaso" com a etapa MODELAGEM, principalmente pela turma de TI. Comentários do tipo "o pessoal da minha empresa é muito imaturo para isso" ou "isso não se aplica muito para o meu caso" são frases que tenho escutado.

Entendendo que as etapas de ASSEMBLY e DEPLOY são de responsabilidade fundamental de TI (e não discuto muito sobre isso) sobraram as etapas de MONITORAçÃO e MODELAGEM, que citei no parágrafo acima. Em MONITORAçÃo, normalmente pensamos no gran-finale de um ciclo  de desenvolvimento de um processo, que é a visualização e análise de quão bem ou quão mal anda o mesmo.

Em MODELAGEM que está o "X" da questão. É neste ponto que se define como o processo anda atualmente, como ele pode ser executado, que melhorias podemos ganhar com a mudança (pensando em funcionalidades de simulação) e, mais, como poderemos "medir" o processo em execução, isto é, como veremos, na etapa de MONITORAÇÃO, se as melhorias que estamos propondo em tempo de modelagem serão, de fato, confirmadas em produção. Os famosos KPIs (indicadores chave de performance) DEVEM ser definidos neste ponto. E por quem? Pelo grupo de TI, que cuida de Web Services, EJBs, ESBs (e outros jargões) ou pelo "usuário imaturo em tecnologia" mas que sabe, de fato, os indicadores que poderão medir a saúde da empresa?

Portanto, o que quero dizer é que um projeto de BPM para ser bem sucedido é FUNDAMENTAL (coloquei maiúsculo de propósito) que os gestores do processos estejam envolvidos deste o 1o minuto do projeto e, mais, sejam parte integrante do time, durante todas as fases, principalmente, da etapa de modelagem. Eu disse parte integrante e não "cliente" do projeto.

Obviamente, há uma série de outros fatores que facilitam (ou dificultam) uma boa implementação. Nunca vamos esquecer, por exemplo, de controles de change management (gestão de mudanças) que vai promover o projeto junto à organização, mostrar os benefícios que a solução irá agregar ao negócio e treinar os envolvidos.

Você consegue lembrar de algum projeto que naufragou por conta de fatores alheios aos aspectos tecnológicos? Não foi difícil lembrar, foi?

Luiz Phelipe Souza

O que considerar numa suite de BPM?

Escrevi em outro post sobre o conceito principal em cima da sigla BPM e como outra sigla, SOA, complementa e facilita a implementação de soluções de gestão de processos (Leia Aqui).

Neste tópico, vou comentar sobre as principais funcionalidades exigidas pelo mercado de TI para as suítes de BPM e que já estão disponíveis pelos principais players do mercado.

MODELAGEM & SIMULAÇÃO : Espera-se com esta funcionalidade a capacidade de documentar processos de forma rápida e imediata, isto é, sem grandes conhecimentos da ferramenta, é esperado que o usuário seja capaz de começar o desenho do seu processo. Além disso, um requisito mandatório atualmente é a capacidade de simulação, ou seja, conseguir "alimentar" seu processo com informações de custos, prazos e disponibilidade de recursos para identificar, em tempo de projeto, onde podem estar os principais "gargalos" ou pontos de melhoria que justifiquem uma re-engenharia do processo. Por fim, mas não menos importante, é a possibilidade de exportar o resultado do trabalho de modelagem para uso pela equipe de TI, responsável final para colocar aquele processo automatizado e em execução. Com isso, começamos a ter o grupo de negócios e processos trabalhando efetivamente no desenvolvimento de uma solução.

AMBIENTE COLABORATIVO: Entende-se por este conceito a possibilidade de extender o seu ambiente de desenvolvimento e os produtos desenvolvidos para uma comunidade maior de usuários que podem, com isso, colaborar na solução final. Algumas funcionalidades interessantes são a definição de um repositório comum de projetos já construídos ou em desenvolvimento e foruns de discussão sobre os principais objetivos do projeto. Pensando já na execução de um processo de negócios, é natural que existam intervenções humanas ao longo do mesmo(por exemplo, aprovações). Há que se considerar, portanto, que no ambiente de desenvolvimento, as ferramentas incluam facilidades para desenhar as interfaces com o usuário e, além disso, tenham mecanismos para controles de execução de tarefas humanas, como possibilidades de "escalar" outro funcionário em caso de demora excessiva na execução da tarefa ou mesmo a possibilidade de delegações temporárias de papéis.

MONITORAÇÃO DE PROCESSOS: Já bastante comentado em outro post (Leia Aqui), esta funcionalidade tem por objetivo mostrar aos gestores dos processos como andam seus "filhos", isto é, quão bem ou quão mal os processos rodam na organização. Indicadores de desempenho (KPIs), gráficos consolidados e visões operacionais estão como os principais desejos dos gestores que, normalmente, irão patrocinar um projeto de BPM para conseguir a tão sonhada "gestão on-line e real-time".

PROCESSOS DINÂMICOS & APLICAÇÕES COMPOSTAS : Tem sido comum, em tempo de projetos, os requerimentos de dinamicidade e flexibilidade de manutenção do processo, ou seja, a capacidade de manter meu processo sem tirá-lo do ar ou, pelo menos, minimizar ao máximo o downtime. Afinal, este é um grande apelo do "BPM enabled by SOA". Soluções de mercado atuais incluem a possibilidade de se criar um processo customizado e que pode ser mantido a partir de políticas de execução do mesmo, isto é, baseado nas informações do cliente que invocou (se é um cliente preferencial ou não), de onde ele veio (se por um portal, por URA, por atendente, etc) e/ou dos dados contidos na invocação (se é um pedido de um novo produto algo já pedido) chegar a uma granularidade bastante particular do processo que inclui sistemas, grupos de atendimentos distintos e qualidades de serviços completamente distintos.

PROCESSAMENTO DE EVENTOS DE NEGÓCIOS : Não somente a monitoração dos processos está na lista de anseios de clientes de BPM. A capacidade de se identificar padrões de execução e/ou comportamento do cliente final e, com isso, tomar alguma decisão automática tem sido uma funcionalidade bastante comentada. O exemplo mais simples para ilustrar é o caso de um usuário de telefone celular que tem um registro de ligação no Rio de Janeiro e, quinze minutos depois, consta um registro de ligação a partir de Fortaleza. Bom, neste cenário, ficou bastante evidente uma fraude na conta daquele cliente. Com alguma ferramenta que permita extrair eventos de negócios do processo em execução, montar padrões de desvio e invocar ações automáticas, consegue-se implementar este tipo de requerimento, citado no exemplo.

EXECUÇÃO DO PROCESSO: Neste ponto, fala-se principalmente na capacidade de orquestrar e montar o processo (a partir de serviços automáticos ou humanos) além do próprio ambiente operacional que irá ser executado o processo. Em tempo de desenvolvimento, é extremamente importante que se consiga, antes de mais nada, importar algum artefato proveniente da etapa de modelagem (comentei isso acima na perspectiva do analista de processos). Mais: atualmente, o mercado de TI tem desenvolvido alguns padrões de linguagens e conceitos para a implementação do "BPM enabled by SOA". Considero como principais o BPEL, que é uma representação para a execução de um processo e invocações para serviços existentes (automáticos ou humanos) e o SCA (Service Component Architecture) que é uma representação dos processos e suas dependências para execução. Neste caso, temos o "SOA na prática". Vemos em diagramas o processo montado, suas interdependências e, em caso de manutenção para troca de serviços, simplesmente nos limitamos a "trocar caixinhas". Tão simples quanto isso ! Sobre o ambiente operacional... Bom, em primeiro lugar, não se espera de um ambiente que irá rodar, por exemplo, seus processos de venda algo sem grandes contingências, alta disponibilidade, segurança e tudo mais que se espera de um servidor de produção. Portanto, em suas iniciativas de BPM, não se esqueça de verificar com seu fornecedor em que sistemas operacionais o tal servidor rodará além da capacidade de escalabilidade e alta disponibilidade.

REPOSITÓRIO DE SERVIÇOS: Esse é um requerimento diretamente associado aos procedimentos de governança. Pensando num dos apelos de SOA, reuso, como é que se garante reutilização de serviços sem uma espécie de "centro de excelência SOA" em conjunto de um repositório controlado de serviços? Esse repositório deve garantir algumas coisas: Ser de uso comum a analistas de negócios e de TI, ser configurável para a definição de políticas de uso, possuir mecanismos de controle de acesso, possuir facilidades que controlem o ciclo de vida dos serviços além de outras coisas mais.

Outras funcionalidades (não ligadas diretamente a tecnologia) para a tomada de decisão de uma suite de BPM incluem frameworks de indústria que podem ajudar como "templates" para a aceleração da implementação de processos (por exemplo, a indústria de telecomunicações, cada vez mais, utiliza padrões estabelecidos mundo afora), metodologias de implementação de tais suites e também um "ecossistema" no mercado de desenvolvedores, técnicos e analistas.

Naturalmente, nenhum cliente precisa disso tudo num primeiro momento de suas iniciativas de BPM. Seria como pensar em se ter uma aperalhagem completa de cozinha para fazer ovo frito, não é verdade? O que considero como sendo um dos pontos mais importantes para avaliação de uma suite, do ponto de vista técnico, é sua modularização e facilidades de integração entre módulos. Isso me garantirá um início mais barato além de garantias para o crescimento dos meus projetos.

Luiz Phelipe Souza

Service Oriented Reference Architecture – Parte 1

"SOA não é um programa de computador a ser instalado e que vai resolver todos os problemas de TI. SOA é um estilo de arquitetura tecnológica com o objetivo de dar agilidade ao negócio das empresas. Sendo um estilo, ela tem traços marcantes: componentização para reuso, a modelagem e coreografia de processos, etc, já discutidos aqui. Mas quais são as melhores práticas para a materialização desses conceitos? O que a experiência tem mostrado como sendo o caminho mais efetivo?"

Ao fazer uma viagem de carro uma das primeiras atividades é levantar informações sobre o caminho (condições da estrada, locais de parada, etc). Isso acontece porque quando vamos encarar uma longa jornada por um caminho que não é do nosso dia-a-dia preferimos planejar para evitar surpresas.

Com a adoção de novas tecnologias não é diferente. Sempre procuramos planejar nossa jornada até sua implantação para minimizar os riscos envolvidos.

Da mesma forma de usamos mapas rodoviários e GPS em nossas viagens, alguns artefatos nos guiam na área de tecnologia da informação.

Neste primeiro artigo vamos começar a entender nosso GPS para a adoção de uma arquitetura orientada a serviços: a Service Oriented Reference Architecture ou SOA Foundation.

O primeiro modelo de referência é para a definição de um ciclo de vida para nossos componentes de negócio.

O objetivo do ciclo de vida é definir as etapas de captura das informações de negócio (processo, indicadores), a transformação dessas informações em uma especificação de tecnologia, a instalação desses componentes para a execução, o acompanhamento da saúde do processo de negócio e a realimentação dessas informações de saúde na etapa de captura das informações.

A figura 1 abaixo apresenta esse ciclo, suportado por governança e processos. Vamos detalhar mais o ciclo de vida no segundo artigo desta série.

O segundo modelo de referência é para o estabelecimento de um diagrama funcional, onde fica claro quais são as entidades necessárias para a execução do processo de negócio. Cada uma das “caixinhas” no diagrama funcional executa uma atividade tecnológica específica. Essa representação auxilia no reuso de componentes, além da escolha dos requisitos técnicos como melhor plataforma de execução e melhor nível de serviço.

Discutiremos mais sobre o diagrama funcional no terceiro artigo desta série.

O terceiro modelo de referência serve para a definição do modelo de desenvolvimento aderente ao ciclo de vida e ao diagrama funcional apresentados anteriormente.

O modelo de desenvolvimento tem como foco principal simplificar as complexidades específicas de cada ambiente e cada linguagem com o objetivo comum de produzir componentes reutilizáveis por uma arquitetura orientada a serviços, sem perder os investimentos já feitos e as capacidades e conhecimentos existentes.

No quarto artigo vamos falar mais sobre o modelo de desenvolvimento.

João Luiz Pereira Junior

Tornando a implementação o menos dolorosa possível

“Tá bom, tudo o que vimos até agora faz sentido e até parece interessante, mas como mudo a cultura da minha empresa para adotar uma solução no estilo de BPM/SOA?”

Essa é a primeira pergunta que aparece na mente de qualquer um que entenda os benefícios da arquitetura orientada a serviços. Isso porque a palavra chave dessa pergunta é cultura e, no geral, mudanças culturais não são amplamente aceitas.

Para aqueles que já têm algum tempo de TI, lembro que perguntas semelhantes apareceram quando surgiu a arquitetura cliente-servidor, quando fomos para o modelo web-based, mais uma vez na arquitetura web de três camadas, no famoso J2EE e por aí vai. Foram tempos árduos para os gerentes de projeto que implementaram essas modelos tecnológicos nas suas empresas, mas não faltaram benefícios (e até algumas promoções).

Com a arquitetura orientada a serviços não é diferente. Tudo vai depender de quão organizado o projeto de implementação vai começar.

Para aqueles que chegaram até aqui e estão querendo parar de ler porque “minha empresa nunca vai ter SOA”, eu queria só adicionar mais um ponto:

Praticamente todas as empresas vão adotar SOA de uma forma ou outra e isso se dá por um motivo simples: todos os fornecedores de tecnologia estão produzindo soluções SOA-enabled. Convido vocês a um teste: Escolha um fornecedor de tecnologia e faça a seguinte pesquisa no google:

+Nome_do_Fornecedor+SOA

As eferência para IBM e SOA já chegam a quase 3 milhões de registros.

Mas voltando à implementação, nosso objetivo é torná-la o mais consistente e o menos dolorosa possível (não necessáriamente nessa ordem!). Além de pensar em um roadmap de implementação que antecipe os benefícios.

Para que isso seja possível o segundo passo é montar um mapa de prioridades. Costumo fazer isso com um gráfico de bolhas representando benefício x complexidade x custo. Como o exemplo abaixo:

Tabela 1 - Mapa de Prioridades

Da Tabela 1 geramos os dados do Gráfico 1, de onde podemos escolher dentre dois candidados a primeiro projeto: o Portal ou a Coreografia. É importante lembrar que esse gráfico é contruído considerando o custo como tamanho das esferas no gráfico. E o que buscamos são projetos com o maior benefíco com a menor complexidade e o menor custo.

Gráfico 1 - Mapa de Prioridades

“Mas se esse é o segundo passo, qual é o primeiro?”

O primeiro passo e mais importante é o estabelecimento de um grupo multi-disciplinar (pessoas de tecnologia e pessoas de negócio) que irá ser responsável pelo sucesso da implementação.

Historicamente a implementação de novos modelos tecnológicos sempre foi liderada por tecnologia. Isso não se aplica mais: tecnologia sozinha não vai ter subsídios para escolher entre Portal ou Coreografia no nosso exemplo acima. E esse nosso primeiro passo é também a primeira mudança cultural.

Esse grupo é conhecido novos modelos de administração como Centro de Competência ou Centro de Excelência. O Centro de Excelência em SOA é responsável por alguns pontos críticos:

• Roadmap de Implantação
• Arquitetura Corporativa
• Modelo de Governança de TI
• Modelo de Governança de Negócios
• Plano de Capacitação
• Endomarketing para divulgação do novo modelo

Por último, mas não menos importante, o responsável pelo Centro de Excelência deve ser um executivo da companhia, especialmente alguém que tenha interesse direto nos resultados obtivos pelo novo modelo tecnolócio. Esse sponsor é peça chave para que a implantação tenha sucesso.

João Luiz Pereira Junior

Por Onde Começar?

Acredito que depois desse nivelamento de conceito e pensando na complexidade da sua empresa, você deva está se sentindo uma criança quando ganha um quebra-cabeças de 5000 peças.  Analogamente à situação do quebra-cabeças, não adianta pensar que você vai sair implementando um cenário de BPM na sua empresa de uma ponta a outra.  É fundamental começar por partes, não se monta um quebra cabeça querendo juntar todas as peças ao mesmo tempo. Por isso, diversos estudos mostram como começar essa “brincadeira”. No Artigo: “Innovate and optimize business operations with business process management (BPM), Part 1: Business process management enabled by SOA”, Christina Lau apresenta os seguintes pontos de entrada identificados pela IBM para uma implementação de BPM enabled by SOA:

Modelagem e Simulação de Processos
Se sua empresa tem problema de documentação de processos, ou mesmo se tem eles documentados em ferramentas mas que não conseguem realizar simulações em torno processos a ponto de identificar gargalos ou mesmo testar possíveis melhorias no processo, você é um forte candidato a começar seu cenário de BPM por esse ponto de entrada.

Monitoração dos Processos de Negócio
Se o principal problema da sua empresa é não conseguir gerenciar o andamento dos processos de negócios de tal forma que os executivos responsáveis por tomar decisões gerenciais não consigam saber, em tempo real, exatamente qual melhor decisão a tomar, o ponto de entrada para o mundo BPM é o que chamamos de BAM (Business Activity Monitoring).

Execução e Otimização de Processos
Se sua empresa enfrenta problemas em otimizar processos, devido à dificuldade de identificar serviços já existente na área de Tecnologia ou dificuldade de integrar novos serviços em processos já existentes, um bom ponto de partida é através de uma infraestrutura para execução e orquestração de processos.

Flexibilidade na Regras de Negócio
Muitas empresas possuem dificuldades de atender a demanda de mercado, porque para modificar uma regra de negócio (por exemplo, alterar uma regra de parcelamento sem juros de 12 meses para 24 meses em um tipo de compra específica) necessitam de modificações em sistemas desenvolvidos pela área de TI. Logo, se sua empresa tem esse cenário acontecendo freqüentemente, a ponto de atrapalhar o seu negócio,  o ponto de entrada de Flexibilidade na Regras de Negócio é um candidato muito forte para iniciar o seu cenário de BPM.

Conteúdo e Colaboração
Algumas empresas que necessitam gerenciar conteúdos (documentos, arquivos, formulários, imagens) e transitar com esse conteúdo durante todo o processo de negócio, possuem diversos problemas desde a criação desse documento, com relação a versionamento, aprovações e armazenamento, isso dentro do contexto do processo de negócio. Se sua empresa tem essa característica de possuir processos de negócio orientados a Documento/Conteúdo, esse é um ponto de entrada possível para você.

Caso você tenha se identificado com mais de um ponto de entrada, não se espante, isso é bem normal. Você pode até começar com mais de um ponto de entrada, mas em conseqüência o risco do seu projeto inicial se tornar bem maior além do seu custo para um investimento inicial. Logo sugiro começar pequeno, pois assim é mais fácil você convencer a todos do potencial e do retorno financeiro de uma implementação de uma arquitetura BPM/SOA. A prioridade da sua empresa vai te auxiliar a definir qual o melhor ponto de entrada entre alguns possíveis. Sempre leve em consideração fatores como custo, tempo de retorno e quais áreas serão beneficiadas diretamente por essa implementação.

Nos próximos artigos apresentaremos sugestões e dicas de soluções de como implementar os pontos de entradas descritos acima.

Rafael Osório