BPM / WORKFLOW

EAI APPLI CATI ON SERVER FREQUÊNCIA DE MUDANÇA COM P L E X ID A D E DE COORDEN A Ç Ã O ALTA ALTA BAIXA BAIXA

Fonte: Krafzig et al. (2005).

O custo e a complexidade de se implementar uma solução de BPM ainda são expressivos, portanto, alguns aspectos devem ser avaliados previamente (Krafzig et al., 2005):

o A equipe de TI e responsáveis pelo negócio devem trabalhar juntos, dado que a orientação por processos é base nas duas abordagens;

o Utilizar modelos pré-existentes de processos como ponto de partida, considerando que os mesmos foram obtidos das melhores práticas do mercado;

o Identificar a tecnologia mais adequada para o negócio, combinando uma análise da dinâmica envolvida (frequência de mudança) e o grau de coordenação exigida entre os processos (vide fig. 06);

o Adotar um modelo de desenvolvimento que apresente a melhor relação de custo versus benefício na evolução e adaptação da solução às necessidades do negócio.

Portanto, a complexidade de coordenação das diversas atividades e processos do negócio e, o grau de mudanças requeridas dentro da dinâmica competitiva, são ao fatores preponderantes que determinarão a maior ou menor necessidade de uma solução de BPM (vide fig. 06).

Adicionalmente, poderíamos acrescentar a necessidade de avaliarmos a aderência de uma dada solução aos objetivos de desempenho desejados para o negócio.

2.6.2–A Solução de BPM como Plataforma Tecnológica

Neste trabalho, buscamos elencar um conjunto de funcionalidades que descrevessem de um modo genérico uma solução de BPM na gestão de processos de negócios. Assim, um pacote de BPM deve contemplar (Thompson, 2003; Megard, 2002; Santos, 2002; McDaniel, 2002; Delphi Reports 2002 e 2003):

o Uma ferramenta de modelagem e/ou definição de processos; o Uma ferramenta e/ou módulo para definição de regras de negócio; o Um mecanismo e/ou ferramenta para integração com outras

soluções de sistemas e bases de dados;

o Um mecanismo e/ou módulo para interação com os usuários ou participantes do processo;

o Um módulo para o monitoramento dos processos.

• Uma ferramenta de modelagem e/ou definição de processos: Para a modelagem adequada de um processo, é necessário descobrir o real propósito do mesmo para o negócio. Geralmente, exige a participação conjunta de: Analistas de Processos, Participantes do Processo, Gerentes, Donos de Processo e, algumas vezes, de consultores treinados. É interessante que a ferramenta permita implementar a arquitetura dos processos correntes bem como visualizar e identificar melhorias através de uma notação e linguagem gráfica fácil de usar e comum a todos os envolvidos, como por exemplo a notação BPMN (Business Process Modeling Notation) desenvolvido pelo grupo de trabalho chamado BPMI (Business

Process Management Initiative). Além disso, a ferramenta deve dispor

de flexibilidade para a decomposição ou fragmentação do processo em subconjuntos menores mantendo a coesão ou coerência geral. Os fluxos dos processos podem ser em série ou em paralelo. Algumas técnicas devem estar incorporadas para facilitar o desenho do processo (Megard, 2002):

o Um conjunto de algoritmos para rearranjo dos diagramas em segundos. Eles adaptam o layout automaticamente (usando uma tecnologia chamada “graph layout”) colocando os elementos do diagrama na representação mais significativa; o Representação de processos e sub-processos com a

capacidade de quebrar um sub-processo para simplificar uma representação ou expandi-lo em detalhes menores, sem limitação de número de níveis;

o Uma janela para visualizar o processo para apresentar a seleção corrente no seu contexto e mover com rapidez e precisão de uma área para outra;

o Apresentação dos diagramas de diferentes processos compartilhando os mesmos objetos básicos (atividades e

regras) para reorganizar facilmente diferentes processos movendo partes de um para outro;

o Abrir visões múltiplas em locais diferentes dentro da mesma definição do processo para possibilitar relacionar partes do gráfico que estão muito distantes para serem mostradas em uma visão legível;

o Diferentes visões para desenvolvedores e usuários olhando para o mesmo modelo, filtrando os objetos mostrados em um diagrama para apresentar o nível de detalhe apropriado da situação atual (por exemplo: nós associados à uma regra ou não), facilitando a compreensão ou integridade;

o Capacidade de simulação em gráficos animados de “tokens” fluindo através do gráfico para simular a execução das instâncias do processo. Isto permite uma melhor visualização e rastrear um processo para identificar pontos de melhorias;

o Representação baseada no tempo no qual os nós são representados como segmentos cujo comprimento mostra seus tempos de execução e espera. Através desta visão, o caminho mais longo e o mais curto podem ser identificados, prazos e atrasos ajustados com os resultados esperados. Também, simplificações podem ser determinadas para melhorar as metas de tempo de resposta.

Dependendo da arquitetura desenhada, ou seja, do local onde se coloque uma determinada atividade, podemos ter um impacto diferente em termos de eficiência e custo. Aqui vale ressaltar que uma determinada atividade pode ser interpretada como um processo menor ou até mesmo um componente reutilizável em outros processos.

• Uma ferramenta e/ou módulo para definição de regras de

negócio:

O desenvolvimento baseado em componentes é uma tecnologia que pode ser genericamente definida em três camadas: serviços comuns, a lógica do negócio e apresentação. Assim, a visão tradicional em camadas: dados, aplicação e apresentação é reformulada numa

solução BPM com a inclusão da camada de processos, onde a lógica do negócio é considerada na definição dos fluxos e no interrelacionamento das atividades, além de uma camada de regras para a definição da interação com os participantes e no tratamento dos eventos e objetos relacionados. A definição das regras do negócio demandam um módulo que avalie automaticamente o estado de cada objeto e execute o método correto baseado neste estado e nas regras associadas, além do gerenciamento por exceções (vide fig.07).

Os objetos ou itens de trabalho (ex.: pedido, ordem de serviço, reclamação, etc.) podem ser obtidos de sistemas e bases legadas e/ou variáveis constituídas por meio de formulários criados e transformados ao longo do processo. Portanto, a lógica de tratamento para questões do tipo: enfileiramento de tarefas, agendamento, priorização, aprovação, tratamento de exceção e direcionamento, são implementadas como regras de negócio. Este tipo de implementação requer, muitas vezes, algum desenvolvimento específico de componentes com o uso de linguagens script, ou seja, a construção de blocos de códigos por um especialista.

A infraestrutura tecnológica requer que todas as definições e regras inerentes atendam aos requisitos básicos de qualquer aplicação baseada em servidores: escalabilidade, confiabilidade e disponibilidade e, seja capaz de administrar os requisitos dos processos de negócio independentemente das considerações sobre a rede de comunicação instalada.

• Um mecanismo e/ou ferramenta para integração com outras

soluções de sistemas e bases de dados:

Ferramentas de Integração das diversas soluções, plataformas de sistemas, bancos de dados, estruturas interna e externa. O acesso à dados externos por meio de conectores padrões permitem a

integração com banco de dados e/ou aplicações externas, tais como: soluções de ERP, CRM, SCM, etc.. É recomendável que este tipo de implementação seja realizada com a ajuda de um especialista. Tal integração deve prever a população (obtenção dos dados externos e suas estruturas) das bases da solução BPM, além de permitir a atualização em ambas as direções. Com o uso de uma camada de

middleware, é possível a utilização de recursos para a gestão da

integração, com o uso de sinalizadores, gerenciamento de filas, alarmes, sincronização de bases de dados, etc., facilitando o uso e manutenção.

• Um mecanismo para a Execução do processo modelado:

Um modulo de execução (Execution Engine) onde o desenho do processo e as regras do negócio podem ser ativadas e coordenadas, inclusive possibilitando intervenções em tempo real. A execução pode ser instanciada para verificação do fluxo definido e identificação de eventuais gargalos. Processos síncronos e assíncronos podem ser disparados em série ou em paralelo. Este mecanismo requer uma avaliação cuidadosa da arquitetura tecnológica disponível para garantir o desempenho e a escalabilidade desejados. Além disso, existe a possibilidade de registro de todos os eventos ou por meio de parametrizações, de modo a permitir a rastreabilidade e a auditoria do que foi executado.

• Um mecanismo e/ou módulo para interação com os usuários

ou participantes do processo:

Um módulo para a interação com os usuários, notificando as tarefas a serem realizadas e possibilitando a visualização e priorização dos itens de trabalho. A flexibilidade na visualização e tratamento dos itens de trabalho está relacionado com a configuração do acesso dos

participantes e regras estabelecidas na modelagem do processo. Em geral, as soluções devem permitir a utilização de meta definições, tais como: grupos, sub-grupos, funções, além do próprio usuário com recurso de login e senha. Este módulo deve ser acessível também via Web e requer um cuidado no dimensionamento da arquitetura de comunicação e disponibilidade dos servidores. A consideração mais importante é identificar como os usuários se encaixam no desenho geral da solução. Melhorias podem ser introduzidas mostrando as atividades precedentes, consequentes e os seus participantes.

Figura 07 - Modelo conceitual de uma Solução BPM

Fonte: Delphi Report (2003)

• Um módulo para o monitoramento dos processos:

Módulo que permite o monitoramento visual dos processos/atividades, a auditoria, obtenção de indicadores ou métricas e um histórico de

logs12 que permitem inclusive a otimização. Durante o monitoramento

12 _{log são registros de atividades ocorridas em um computador e/ou sistema informatizado.}

AMBIENTE DO USUÁRIO LISTA DE TAREFAS APLICAÇÕES DE TERCEIROS E ATIVIDADES AUTOMATIZADAS