abr 08 2015
Como SOA pode influenciar em iniciativas de BPM
Com as iniciativas de Gerenciamento por Processos de Negócio (BPM) ganhando mais espaço dentro de organizações públicas e privadas, é natural que estas organização sintam a necessidade de automatizar determinados processos de negócio com soluções BPMS quando atingem certo grau de maturidade nesta disciplina.
Para garantir o sucesso desta iniciativa, tanto a equipe de negócio quanto a equipe de TI precisam estar alinhadas quanto as expectativas sobre as ferramentas BPMS, iniciativas de SOA e como serão aproveitados os sistemas de informações legado. É preciso identificar cada uma das peças desse quebra-cabeça e saber como elas se encaixam.
O objetivo deste artigo é apresentar como a Arquitetura Orientada a Serviços, ou simplesmente SOA, pode influenciar significativamente nos resultados obtidos nas iniciativas de BPM, mais claramente percebidos na implantação de um BPMS.
A Organização e os processos Ponta a Ponta:
O modelo mais comum de uma Estrutura Organizacional é definido pelo CBOK como sendo “orientada por funções e representa tipicamente um agrupamento (departamento, divisão, área) de executores especializados para realizar tarefas relacionadas a um determinado recurso, conhecimento ou habilidade.”.
Com as iniciativas de BPM, são identificados diversos processos que permeiam pelas Áreas Funcionais desta Estrutura Organizacional de forma horizontal, chamados de processos “ponta a ponta” (Figura 01), requisitando que atividades especializadas daquela área sejam executadas. Um único processo pode chegar a ter a participação de todas essas Áreas Funcionais da empresa antes de concluir seu fluxo, assim como uma mesma atividade especializada pode ser requisitada por diversos processos diferentes.
Figura 1 – Relação entre Estrutura Organizacional com Processos
A Organização e os Sistemas de Informação
Os Sistemas de Informações existem em todo tipo de organização.
Não importa a linguagem, forma de armazenamento dos dados, o desenvolvedor responsável, se é uma planilha do Excel ou um sistema ERP, cada sistema de uma organização possui uma história e um patrocinador.
De um modo geral, a iniciativa de construção de um Sistema de Informação nasce para atender especificamente a uma determinada Área Funcional. Aos pouco, o escopo deste sistema vai aumentando para adicionar a participação de uma segunda área funcional que colabora pontualmente para a necessidade negocial daquele sistema, e com o tempo novas necessidades vão surgindo.
Quando colocados do ponto de vista da Estrutura Organizacional, os sistemas podem ser representados em uma forma transversal dentro da organização, pois não se limitam a uma única área, mas também não podem ser definidos como “ponta a ponta”
Figura 2 – Relação entre Estrutura Organizacional e Sistemas
A Organização executando seu processo.
Se pegarmos como exemplo rápido o processo “Solicitação de Empréstimo Bancário” que tenha as seguintes atividades:
• Solicitação do cliente junto à agência;
• Validação da documentação mínima;
• Análise de risco;
• E finalmente a liberação ou não do empréstimo;
Durante a execução do processo, o gerente da agência irá acessar um ou mais Sistemas de Informação para efetuar cada uma destas etapas.
• Sistema 1: realiza o cadastro e a validação da documentação mínima do cliente;
• Sistema 2: realiza a análise de risco deste cliente;
• Sistema 3: realiza a solicitação de empréstimo e possui a resposta se o empréstimo foi concedido ou não;
• Sistema 4: libera a quantia do empréstimo na conta corrente;
Os gerente da agência deve efetuar o login e utilizar 4 sistemas diferentes e realizar atividades em cada um desses sistemas para conseguir concluir um processo de concessão de empréstimo.
Figura 3 – Relação entre Processos e Sistemas
A Organização e o Quebra-Cabeça
Analisando cada uma dessas peças (A organização, os processos e os sistemas) percebemos que, individualmente, cada uma tem a seu escopo muito bem definido. Porém, quando estamos falando de uma iniciativa BPM envolvendo automação de processos com BPMS, é necessário que estas fronteiras sejam quebradas de forma que uma única ferramenta deverá
• Intermediar o fluxo de informações entre as Áreas Funcionais envolvidas;
• Gerenciar participantes das atividades;
• Disponibilizar recursos de sistemas de informação ou fonte de dados;
• Controlar informações e indicadores negociais;
• Ser flexível para permitir mudanças de forma rápida;
Com isso percebemos o quanto uma iniciativa de Automação de Processos pode ser complexa. É neste momento que os stakeholders da iniciativa precisam ficar atentos, pois o que era claro e bem definido acaba ficando confuso mesmo que pareça estar tudo “sob controle”, conforme demonstrado na Figura 4.
Figura 4 – Relação Estrutura Organizacional, Processos e Sistemas
SOA alinhado com os Sistemas de Informações.
Quanto mais complexo for o processo, maior será o número de sistemas envolvidos, e o desenho de um processo TO-BE não pode ser feito para representar as atividades baseadas em o que o sistema faz, mas sim definindo que tipo de valor que será gerado naquela atividade independente de sistema.
De acordo com o CBOK, “Ao visualizar a operação futura, a equipe deve compreender que o modelo “TO-BE” estabelece um tipo de modularização da operação. Cada atividade funciona independentemente com ligações a outras atividades por meio de entradas e saídas.”.
Diante desta visão, entende-se que é preciso fazer com que os sistemas invertam a sua perspectiva. O processo é o direcionador das melhorias da organização. Ele que vai dizer quais informações são pertinentes para aquela atividade, e não o sistema existente. Porém nem sempre é possível ou conveniente fazer uma mudança no sistema, e muito menos iniciar um novo projeto de Sistema com a fábrica de software, em função te prazos, custos e etc.
Neste momento que entra a arquitetura SOA.
SOA (Arquitetura Orientada a Serviços), é uma arquitetura de software onde se procura disponibilizar as funcionalidades das aplicações existentes em blocos especialistas e reutilizáveis chamados “Serviços”. Estes blocos são criados de forma a espelhar o resultado esperado pelo processo na execução daquela atividade.
Com SOA é possível criar uma camada intermediária entre o consumidor da informação e os sistemas, modularizando os serviços de forma a serem alinhados com os processos AS-IS ou criar novos serviços totalmente alinhados com a proposta de transformação do desenho TO-BE, independente de onde se origina essa informação.
Figura 5 – Relação entre Processos, SOA e Sistemas Transacionais
No exemplo do processo “Solicitação de Empréstimo Bancário”, ao invés de o gerente da agência utilizar quatro sistemas diferentes, agora ele apenas interage com um único sistema, que é o BPMS. Na tela do BPMS, o gerente insere somente o CPF do correntista interessado no empréstimo e o valor solicitado, e a resposta é o cadastro completo do cliente no banco, com todas as informações cadastrais pendentes de atualização, o resultado da análise de crédito com os indicadores de risco atualizados e os dados bancários a qual será feita a transferência do valor solicitado mediante o clique do botão “Ok”. Quatro atividades que eram obrigatórias em função da forma que os Sistemas de Informação foram criados foram reduzidas para uma única atividade eficiente e focada no negócio.
A flexibilidade oferecida por SOA afeta diretamente na forma que o desenho de um processo de negócio pode ser pensado, pois consegue separar a responsabilidade de cada uma das camadas envolvidas nesse processo de forma independente.
• O modelo de negócio determina o fluxo de atividades e decisões do processo de negócio;
• O BPMS coleta os indicadores e unifica o ponto de comunicação com os participantes do processo;
• A camada SOA fica a critério de executar a lógica de coleta e consolidação das informações pertinentes aquele serviço específico de forma encapsulada e desacoplada.
• Os sistemas de informação continuam do mesmo jeito, atendendo aquelas atividades negociais que ainda serão analisadas e redesenhadas pela equipe de negócio.
Conhecer as capacidades de uma Arquitetura Orientada a Serviços abre diversas possibilidades tanto para melhorias em processos de negócio como para a área de gestão de TI.
A empresa Memora Processos Inovadores, com sede em Brasília, vem colecionando casos de sucesso tanto na implantação de escritório de processos e melhorias de processos como também com a implantação e gestão de produtos como Oracle BPM Suite, Oracle SOA Suite, obtendo resultados incríveis e com reconhecimento nacional e internacional.
Repense a iniciativa de SOA na sua organização. Ela pode ser a resposta que você esta procurando.
Autores: Kiomar Oguino Junior e Pedro Aresta – Consultores da Empresa Memora Processos Inovadores
2 Responses to “Como SOA pode influenciar em iniciativas de BPM”
Leave a Reply
You must be logged in to post a comment.
Muito clara a explicação, show de artigo.
Repassarei aos autores! Obrigado Edy.