jun 30 2015
A Engenharia de Software com BPMS Par. 3
Parte 3 Sistemas de informação concebidos com ferramentas BPMS
Antes de continuar, vamos definir o que é um BPMS. BPMS (Business Process Management Suite) é um conjunto de ferramentas automatizadas que proveem suporte a BPM. Possibilita a modelagem, execução, controle e monitoramento dos processos de forma automatizada. Define a arquitetura e infraestrutura tecnológica necessária para a modelagem do negócio, a execução em produção dos fluxos de trabalho, a aplicação de regras de negócio, utilização de dados corporativos, a simulação de cenários e operação de outras aplicações do ambiente BPMS. (ABPMP – Association of Business Process Professionals, 2013)
Como as capacidades de BPMS mudam constantemente na medida em que fornecedores adicionam novas funcionalidades em um esforço competitivo, algumas versões do conjunto de funcionalidades podem incluir:
- Modelagem de processos
- Simulação de novos desenhos
- Definição e gerenciamento de regras
- Reportes de desempenho
- Geração de aplicações
- SOA /EAI
- ESB
Figura 3 Ferramentas BPMS
BPMS cobre o ciclo de vida completo de gerenciamento de processos: modelagem e desenho de processos, implementação e execução, monitoramento e controle, análise e avaliação de desempenho de processos. Ele pode incluir capacidades de tecnologias previamente concebidas para necessidades específicas, tais como imagens, gerenciamento de documentos e conteúdo, colaboração, fluxo de trabalho, roteamento e atribuição de trabalho, gerenciamento e execução de regras, gerenciamento de metadados, Data Warehousing – DW, BI, integração de aplicação e gerenciamento de comunicação.
A automação de processos com o uso de BPMS cria um tipo diferente de solução se comparada às tradicionais linguagens de programação. Na automação, cada atividade do processo se transforma em uma pequena aplicação que é disponibilizada ao ator responsável pela sua execução. O ator recebe um contexto de trabalho com as informações que necessita para realizar a sua atividade e com as respectivas regras de negócio implementadas. A sequência do processo é controlada pelo fluxo desenhado no BPMS. O controle sobre a interação humana é definido por meio de formulários que informam ao BPMS como construir a tela de cada atividade e através de regras que determinam como os dados devem ser tratados e quais as opções que o ator possui para concluir a atividade. (ABPMP – Association of Business Process Professionals, 2013)
Modelos de processos e modelos de regras juntamente com a definição de telas e formulários no BPMS fornecem as especificações necessárias para gerar aplicações. As formas como eles são executadas pelos BPMS permitem uma abordagem diferente de negócio e da área de Tecnologia da Informação. Usando ferramentas de banco de dados externo, a geração de aplicação em BPMS também pode prover suporte a alto volume de uso e armazenamento de dados. (ABPMP – Association of Business Process Professionals, 2013)
O uso de um BPMS também representa um paradigma para o desenvolvimento e geração tradicional de aplicações dentro das áreas de Tecnologia da Informação. Historicamente, a criação de aplicações usando métodos e ferramentas tradicionais tem seu desenvolvimento iniciado pela análise e modelagem de dados, geralmente vinculado ao modo como os dados serão armazenados em um banco de dados. Com o BPMS, o desenvolvimento ocorre em um novo paradigma chamado de modelagem de sistemas orientada a processos, que considera a definição de requisitos de software a partir do levantamento das necessidades de processos. (ABPMP – Association of Business Process Professionals, 2013)
BPMS fornece um novo tipo de ambiente de negócio que integra negócio e tecnologia da informação. O termo “ambiente” é empregado para descrever a operação resultante da utilização de BPMS, pois gera aplicações e fornecem o suporte às operações de negócio na sua execução. Por meio de modelos de negócio, o contexto para a operação em BPMS é definido como uma estrutura passo a passo. A partir desses modelos são definidos requisitos para utilização de dados e sistemas legados. Interfaces fornecem pontos de integração e requisitos de dados a serem utilizados. Regras definidas e adicionadas ao desenho fornecem a lógica ou “a inteligência” para execução das operações. O BPMS pode, então, simular cenários possíveis e avaliar resultados com base em testes que espelham a situação real na qual a aplicação será usada.
Um BPMS permite considerar aplicações transacionais e também trabalhar aplicações de gerenciamento, aplicações que controlam o fluxo de trabalho e como esse trabalho é feito ou deveria ser feito. Isso inclui a atribuição, acompanhamento, balanceamento da carga de trabalho, identificação de erros, gerenciamento de desempenho, reportes, entre outros.
Interfaces dos modelos de processos para sistemas legados podem ser introduzidas para “chamar” outras aplicações e formar uma série de tarefas automatizadas. Embora um tipo de interface seja necessário, o uso de arquitetura orientada a serviço (SOA) com adaptadores e aceleradores de integração corporativa de aplicação (EAI) torna a interface nesse ambiente mais fácil e, consequentemente, reduzem tempo e risco. Controles especiais de gerenciamento também podem ser adicionados aos modelos para controlar o volume do fluxo de trabalho, roteamento de trabalho e aviso de atraso. Esses devem ser baseados em padrões, mas o BPMS pode prover suporte aos diversos padrões da organização.
Arquitetura Orientada a Serviços (SOA – Service Oriented Architecture) é um conjunto flexível de princípios de desenho de infraestrutura usados no desenvolvimento de aplicações e integração de sistemas. Ela é uma abordagem de arquitetura corporativa para vincular recursos sob demanda, permitindo a criação de serviços de negócio interoperáveis que podem ser reutilizados e compartilhados entre aplicativos.
Por meio do uso de serviços, funcionalidades próprias de cada aplicação legada são disponibilizadas para uso por outras aplicações, processos ou serviços. “Chamadas” SOA para dados em sistemas legados ou outros aplicativos são passadas para adaptadores EAI (Enterprise Application Integration) e traduzidas para chamada ou atualização de dados em linguagens de programação mais tradicionais que operam dentro do ambiente técnico dos aplicativos.
Figura 4 SOA e o processo de negócio
Isso permite que as chamadas e atualizações de dados sejam construídas seguindo um formato único e depois entregues (muitas vezes usando um ESB – Enterprise Service Bus – que fornece uma camada de abstração ou “barramento” entre diferentes padrões) para uma aplicação em um formato padrão, o que facilita a conexão entre as aplicações. Entretanto, esse não é um processo simples e embora o uso de SOA, EAI e ESB simplifiquem a necessidade de obter, mover, entregar e formatar dados, ainda demanda um trabalho especializado. Isso fornece um grupo integrado de módulos com baixo acoplamento que são disponibilizados em um repositório de serviços para serem utilizados. Além de criar esse tipo de objeto e serviço de biblioteca, SOA fornece um formato e fundação para notificar clientes desses serviços sobre sua disponibilidade.
Para implementar SOA é necessário definir seus objetivos, uso e padrões internos. Ao criar estratégias SOA é importante identificar os benefícios que são necessários e adotar padrões, técnicas, métodos e conceitos necessários para oferecer esses benefícios. É também necessário se certificar que a área de Tecnologia da Informação e o negócio possuem um roteiro claro de como a estratégia SOA será implementada e qual o papel de cada um dos participantes. No entanto, mesmo com uma visão clara, uma estratégia e um plano, o gerenciamento da implementação irá demandar financiamento e supervisão constante para assegurar que a nova abordagem está no caminho certo.
SOA requer que a organização considere e explicitamente documente quais recursos serão acionados por demanda, por exemplo, processos, mensagens, entidades e visões de dados, armazenamento de dados, regras e eventos. O maior desafio da governança para SOA é gerenciar o ciclo de vida de serviços, incluindo concepção, especificação, desenvolvimento, testes, implementação, direito de uso e alteração, controle de acesso, operação e, finalmente, desativação do serviço.
Embora BPMS possa produzir vantagens, também existem riscos associados a qualquer esforço de automação. O risco mais significativo é que se pode desenvolver um falso sentimento de segurança ao supor que só porque se está automatizando um processo, ele é melhor. Como em qualquer adoção de sistemas, automatizar processos mal feitos não resultará em melhores práticas de negócio. A forma como a ferramenta ou conjunto de ferramentas será utilizada será impulsionada pela visão de negócio e a capacidade de mudança da organização. (ABPMP – Association of Business Process Professionals, 2013)
Assine nossa Newsletter para receber por e-avisos sobre novas publicações na página e aguarde as outras duas partes deste artigo e compartilhe nas redes sociais para divulgação da página.