• Nenhum resultado encontrado

2.   CAPÍTULO II zREFERENCIAL TEÓRICOz

2.4.1.  A Gestão de Processos de Negócio ou BPM (Business Process Management)

2.4. A GESTÃO DE PROCESSOS DE NEGÓCIO – EM BUSCA DA MELHORIA DO GERENCIAMENTO E CONTROLE DOS PROCESSOS DE NEGÓCIO ESSENCIAIS

Contudo, o que se pode inferir é que a área de TI e o seu grupo de arquitetura percebem a vantagem de consolidar uma arquitetura de processos de negócio e afirmam também, que BPM é uma abordagem estratégica para constituir uma arquitetura de processos que se apóia em tecnologias em ampla discussão (BOTTO, 2004), combinando processos de negócio e organização para criar uma visão única e integrada de negócios representando a culminação das experiências coletivas, pensamentos e desenvolvimento profissional em gerenciamento de negócios das últimas décadas (ABPMP Brasil, 2008).

Ainda inserido nesta abordagem de tecnologia, mas, também considerando o apoio que a tecnologia dá aos processos de negócio, BOTTO (2004) considera que BPM trata de um ferramental de modelagem de processos para alinhar recursos necessários e estruturar todo o fluxo do processo numa formatação padronizada, contendo a descrição completa dos processos do negócio, através de uma abstração expressa em notação específica; comenta inclusive, que o mercado apresenta uma tendência convergente na criação de padrões únicos para estas ferramentas.

Nesse aspecto, a questão que deve ficar clara é que BPM é mais uma disciplina gerencial do que um conjunto de softwares, afirmam BALDAM et all (2007).

Visto isto, no contexto desse trabalho o que nos interessa é selecionar os principais benefícios para o uso de BPM na arquitetura de processos de negócio, ou seja:

• Propicia documentar e implementar processos de negócio atuais e facilita seu entendimento (SIMUR, 2005);

• É a ferramenta, por excelência, apta para iniciar solução de problemas de integração (BOTTO, 2004); é a ferramenta poderosa de gerenciamento para executivos de negócio e executivos de TI (FURLAN, 2008), pois, permite simular para tomada de decisão quanto aos impactos de mudanças em TI, em operações e em gerência de risco de determinados processos de negócio;

• Representa uma linguagem comum para concentrar coleta e gerência de requisitos (BOTTO, 2004);

• É uma forma de alinhar procedimentos, pessoas, tecnologia e organização em uma visão única e integrada (FURLAN, 2008), pois facilita a padronização de atividades em empresas com dispersão operacional (ALMEIDA, 2006);

• É uma forma de oferecer flexibilidade e capacidade de resposta a requisitos de negócio em constante mutação (FURLAN, 2008);

• Apresenta-se como uma forma de permitir que idéias possam ser graficamente modeladas e automaticamente convertidas para processos executáveis e assim, dar produtividade na criação de processos de negócio executáveis com gráficos e fluxos (BOTTO, 2004);

• Trata de uma possibilidade de vislumbrar a simulação e modelagem de novos negócios (BOTTO, 2004);

• É uma forma de prover identificação de fraquezas, defasagens, sobreposições, imprecisões em implementação de processos de negócio (BOTTO, 2004);

• Permite visualizar a proposta de automação de processos que mesclam processos automatizados, eventos e atividades humanas tratando complexidade e exceções com eficiência (BOTTO, 2004);

• Trata-se de uma forma de aproximar a TI e a arquitetura da TI dos usuários e induzir o trabalho colaborativo (BOTTO, 2004) proporcionando integração e colaboração (ALMEIDA, 2006);

• É uma forma de potencializar o reuso por TI no âmbito de arquitetura de processos, por conseguinte, nas outras arquiteturas pela visualização de leque de oportunidades instantaneamente apresentadas claramente pelas ferramentas de Frameworks (BOTTO, 2004); e,

• É uma forma de dar independência às arquiteturas que suportam a pirâmide de arquiteturas (ou camadas inferiores), dando espaço à abstração de soluções que serão compostas de sistemas integradores, middleware, etc., mas não fortemente acopladas a este ou aquele processo. Nas camadas (ou arquiteturas) mais baixas da pirâmide, uma tendência a comoditização poderá ser percebida (BOTTO, 2004; FURLAN, 2008).

Em síntese, BPM está relacionado com integração das tarefas de identificação, mapeamento, coleta e registro de informações. Segundo ALMEIDA (2006), é essa integração que propicia ações de análise e simulação de processos de negócio com função de conhecimento e Know-how da empresa, fazendo de sua evolução um diferencial de competitividade.

Apesar disso, BALDAM et all (2007) alertam sobre a questão de que “um modelo serve como orientação valiosa para a prática, mas as pessoas que implementam ou operam o BPM fazem toda a diferença em sua aplicação” – nenhum modelo corresponde exatamente à realidade. Estes autores enfatizam ainda que cada etapa contida nesse Ciclo, ou seja: 1- Planejamento BPM; 2- Modelagem e otimização de Processos; 3- Execução de Processos; e, 4- Controle e Análise dos Dados, pode ser aplicada a um processo específico, tanto quanto a uma gestão integrada de todo o feixe de processos da organização, existentes ou futuros.

Por fim, estudiosos do BPM consideram que esta série de ações gerenciais se repete num contínuo, e dessa forma, originaram-se representações cíclicas de modelos denominados Ciclos de BPM (BALDAM et all, 2007).

O Ciclo de BPM adotado para este trabalho (Figura 19, página 71) é o mesmo proposto por BALDAM et all (2007) e cujo modelo segue a orientação básica da notação utilizada por KIRCHMER (2006) e por JOST & SCHEER (2002), incorporando a representação de MUEHLEN

& HO (2005) somando-se às pesquisas e experiência prática desses autores em implantações e projetos de BPM.

Figura 19: O Ciclo de BPM proposto por BALDAM et all (2007)

Fonte: BALDAM et all (2007) p.56

Nota do autor: O trecho assinalado é representativo das etapas e objetos de aplicação específicos para este estudo de caso, conforme objetivos específicos propostos e métodos e ferramentas utilizados para este trabalho .

71

A questão que se coloca agora é quanto à implantação do BPM.

De acordo com BALDAM et all (2007) é necessário que a organização prepare uma infra-estrutura mínima, ainda que informal, para executar o BPM tais como: sala para reuniões, computadores e ambiente de publicação dos resultados. Alerta, porém, sobre o fato de que as pessoas que possuem papéis definidos no trabalho precisam ter um reconhecimento formal por todos da organização.

A equipe do BPM (Gerente, Líderes de Processo, Auditor do Processo, Dono do Processo, Gestor do Processo, Líder do Processo, Gerentes de Departamentos, Especialistas no Tema, Equipe de TI e Equipe de Contato e Avaliação) pode variar em função da política organizacional, mas, segundo os autores é comum o BPM ser considerado atividade de suporte que cruza toda a Cadeia de Valor da organização, associado às atividades correlacionadas com o Desenvolvimento Institucional, Gerenciamento do Conhecimento, etc. As atividades desenvolvidas por essa equipe podem estar estruturadas de forma matricial (relacionadas de forma pontual com envolvimento de pessoas de diversos departamentos) – “o importante é que a equipe tenha e desenvolva competências para atuar segundo esta abordagem”, confirmam BALDAM et all (2007).

Estes autores alertam, inclusive, sobre o início dos trabalhos do BPM. A questão fundamental trata da elaboração de um Manual do Modelo de Gestão do BPM, o qual marcará sua implantação.

Dessa forma, um manual poderá conter os procedimentos de “como” será executado o BPM na organização, “como” os processos serão escolhidos, “como” será modelado e otimizado, “como"

será implantado um novo processo, “como” os processos em andamento serão monitorados, e,

“como” será feito o controle dos diversos tipos de processos. Segundo BALDAM et all (2007), este manual tem o objetivo de garantir o foco e o alinhamento com a estratégia da organização – “é um documento do processo de gerir processos”, afirmam estes autores.

2.4.2. As ferramentas de TI aplicadas ao BPM – Ênfase para as ferramentas de Modelagem