ALEXANDRE ROVERE CALVO

Introdução da abordagem prática da aplicação do BPM

Londrina

2008

2

Sumário 1 Introdução ................................................................................................... 7 2 Fundamentação Teórica .............................................................................. 7

2.1 Diferentes Visões de Metodologias de desenvolvimento ................... 10 2.2 Organização centrada na visão vertical x horizontal .......................... 12

2.2.1 Limitações que a visão tradicional das metodologias de desenvolvimento provoca à implantação de BPM ..................................... 12 2.2.2 Importância dos recursos humanos no sistema de gestão de negocio 14

2.3 Vantagens e desvantagens do BPM .................................................. 15 2.3.1 Interação entre desenvolvedores e analista de negócio ............. 15 2.3.2 Tipos de problemas nas implementações ................................... 16 2.3.3 Quanto à seleção da solução e com o projeto da aplicação de BPM 16 2.3.4 Quanto à aplicação de BPM ........................................................ 17 2.3.5 Quanto à utilização da aplicação de BPM ................................... 18

3 Modelagem de Processos de Negócios .................................................... 19 3.1 Processos de Negócios ...................................................................... 19

3.1.1 Processos de Governança .......................................................... 20 3.1.2 Processos de gerenciamento ...................................................... 20 3.1.3 Processos operacionais .............................................................. 20

3.2 Principais tipos de processos de negócios ......................................... 22 3.3 Princípios de modelagem para desenvolvimento de sistema ............. 22

3.3.1 Aderência .................................................................................... 22 3.3.2 Relevância .................................................................................. 23 3.3.3 Custo x Benefício ........................................................................ 23 3.3.4 Clareza ........................................................................................ 23 3.3.5 Comparabilidade ......................................................................... 23

3.4 Tipos de visão global de processos ................................................... 23 4 Ferramentas para Modelagem de Processos de Negócios ....................... 25

4.1 Soluções que geram código ............................................................... 27 4.2 Soluções Open Source ...................................................................... 27 4.3 A escolha de uma solução BPMS. ..................................................... 27 4.4 Classificação das ferramentas de TI com aplicações em BPM .......... 28 4.5 Aplicação na implantação e execução de processos ......................... 31 4.6 Aplicação no Controle monitoramento ............................................... 32

5 Conclusão ................................................................................................. 32 6 Definição de Processo ............................................................................... 33 7 Estudo de Caso ......................................................................................... 33 8 Modelagem do estudo de caso.................................................................. 35 9 Conclusões e trabalhos futuros ................................................................. 35

3

ALEXANDRE ROVERE CALVO

Introdução da abordagem prática da aplicação do BPM

Trabalho de conclusão de curso de pós-graduação. Orientador: Prof. Ms Rodolfo Mirando de Barros

4

2008

Mensagem

"O futuro dependerá daquilo que fazemos no presente." Ghandi

5

DEDICATÓRIA A Deus, minha luz, à minha esposa Juliana por todo apoio e ajuda e aos meus pais Elizeu e Edir............

6

AGRADECIMENTO Primeiramente quero agradecer a Deus por ter iluminado meu caminho mediante a circunstância de ter que viajar vários quilômetros para poder realizar um sonho. Agradeço a minha prima Alessandra que desde o primeiro dia em que cheguei a cidade me recebeu com os braços aberto e também pela hospitalidade em seu apartamento. A minha família, meu pai Elizeu, mãe Edir e irmã Juliane pelo apoio quando mais precisei para poder realizar o curso de pós-graduação. Agradeço a meu grupo de trabalho onde desde o primeiro dia em que foi definida conseguimos trabalho pontualmente e seriamente para realizar todos os projetos solicitados em aula. Aos amigos de trabalho, Ricardo Souza e Rosana onde procuraram dar apóio para realizar meu estudo de caso. Ao meu orientador Rodolfo Miranda de Barros por tudo que constei e pelo conhecimento adquirido nestes meses de convívio. Principalmente a minha alma gêmea, minha inspiração, minha esposa Juliana pela motivação, apóio e respaldo necessário neste meses onde procurei buscar e concluir o meu objetivo.

7

Gerenciamento de Processos de Negócio BPM – Business Process Management

Aplicação da Modelagem de Negócio utilizando um Estudo de Caso

1 Introdução

O BPM – Gerenciamento de Processos de Negócio - está relacionado com processo de negócio como também ao controle executivo, administrativo e supervisionário dos mesmos. Para isso desenvolve por meio de companhias ou organizações atividades específicas através de processos de negócios. Trata-se na realidade de uma teoria administrativa cuja finalidade de abordar transformação contemporânea na gestão das organizações.

A aplicação prática do BPM nas organizações, visa clareza nas operações e para isso disponibiliza-se de recursos e ferramentas capazes de inter-relacionar os processos e melhorar o desempenho das organizações.

O estudo em questão tem por objetivo fazer uma introdução da abordagem prática da aplicação do BPM na GOVBR através de um levantamento de dados a fim de facilitar na organização o agendamento de clientes da empresa para melhorar a qualidade do suporte técnico e atendendo a necessidade do cliente.

2 Fundamentação Teórica BPM (Business Process Management) é definido como uma filosofia de gestão que visa organizar uma empresa a partir de seus processos de negócios. Tal procedimento pode acarretar a adoção de softwares de gestão de processo (BMPS – Business Process Management Systems), visando eliminar a lacuna entre a definição dos processos e o modo como eles são realmente executados1. BPM trata-se de uma estratégia de gerenciamento de negócios2. Em meados da década de 90, BPM entrou para o contexto popular de estratégia de gerenciamento e processo de negócio. Assim como a teoria de gerenciamento ou estratégia, BPM pode ser caracterizado por um número de princípios. Apesar de a maior parte ter sido escrito sobre tecnologia de BPM e seus princípios, pouco tem sido escrito sobre princípios de negócios que implicitamente fundamenta tanto o êxito do uso da tecnologia como a visão do futuro2. Este princípio tem fundamentação na história de processos de negócio e nas teorias de gerenciamento2. BPM foi definida ao mesmo tempo como uma teoria e associada a métodos de grupos, tanto para perspectiva de gerenciamento de processos de negócios, relacionada à estratégia de gerenciamento de processos com as conseqüências em longo prazo, quanto para gerenciamento de processos de negócios que inclui a posição operacional2. Para David McGoveran, no gerenciamento de processo de negócio, inclui análise de processos, definição e redefinição de processos, distribuição de recursos, honorários, gerenciamento de processos, mensuração tanto da qualidade quanto da eficiência no contexto do processo e otimização do mesmo2.

8

A proposta do BPM é não forçar uma organização para conduzir-se ao caminho certo e formal, e sim de preferência para entendimento da conduta direta dos princípios e conceitos do BPM. Considerando que o conhecimento de processo requer tempo e esforço considerável2. O rápido sucesso do BPM tem motivado nos últimos anos os departamentos de marketing e venda como também a indústria de analistas2. Apesar de ser um renascimento de velhas idéias, o BPM está crescendo rapidamente nos últimos cinco anos. Muitos tipos de produtos e serviços foram incluídos nesta categoria, tanto aquelas de modelagem de processos de negócios, BPR (Business Process Reengineering), automação de processos de negócios, integração, análise e monitoramento de processo e sistemas de gerenciamento de fluxo de trabalho2. Alguns autores pensavam que BPM foi originado em BPR, mas na realidade foi referido ao pensamento coletivo associado com BPR, e em menor grau, com continuação de desenvolvimento e mudança de processo. Apesar de sua expansão, a definição de BPM ainda está focada na idéia de regerenciamento de processo de negócio2.

O BPM é a disciplina que hoje mais interesse desperta no ambiente empresarial. Todas as iniciativas modernas de administração como BSC, ISO9000, Custeio ABC, Six Sigma, SOX, ISO 14000, necessitam da visão de processos3. Portanto nota-se que BPM envolve a descoberta, projeto e entrega de processos de negócios. Além disso, inclui o controle executivo, administrativo e supervisionário mesmo4. BPM é a gerência de processos de negócios, entretanto está sujeito a eventos positivos e negativos que certamente afetarão o processo, assim como ocorre em todo negócio e em todo processo que resultam em um negócio ou em parte dele3. Um projeto de BPM não é algo que possa ser implementado como um projeto estanque, visto que demandará uma evolução da empresa rumo ao nível elevado do modelo de maturidade do processo5. BPM é despertado nos executivos de negócios os seus benefícios e melhoras práticas5. Porém a sua implementação exige executivos de alto escalão, responsável pelo macro processo com esforço, determinação e autonomia para promover as mudanças necessárias ocasionadas para evitar o dispêndio de energia e o descrédito da empresa6. A gestão por processo é uma poderosa ferramenta de apoio à empresa inovadora. O potencial de BPM vai além de fornecer ferramentas de visibilidade e gestão de processos ponta-a-ponta, supera o desafio de informação e atividades manuais, e ultrapassa a gestão da cadeia fornecedor – cliente7.

Em uma empresa orientada a processo, a tecnologia BPM (modelagem de processo, automação, monitoramento e análise) disponibiliza do processo, de forma que se promova inovação por instinto, experiência e observação.

Conforme Peter Drucker “nos negócios”, a maioria das inovações bem sucedidas não vem de um momento genial, mas de um esforço consciente, proposital e deliberado na busca por oportunidades. Portanto, a empresa orientada a processo tem maior capacidade de inovação7. Os benefícios do BPM são conhecidos como forma de gerir negócios de modo que tal conceito vem se difundindo intensamente nas grandes organizações. O BPM é tanto uma estratégia corporativa quanto um segmento do mercado de software, além de ser uma nova cultura de gerir negócios. O

9

foco é a gestão da eficiência dos processos de negócios. Vivenciados pela organização, proporcionando novas oportunidades profissionais em um mercado cada vez mais enxuto e instável8. Dessa forma, BPM deve ser uma preocupação primordial dos gestores da empresa, que se devem comprometer com a eficiência e com a rentabilidade do seu negócio. Guiados pela estratégia da empresa, os gestores buscam executar ciclos completos de gestão dos processos, mapear, redesenhar, implementar, monitorar e otimizar seus processos valendo-se para isso das ferramentas de BPMS1. BPM, portanto, é um conceito proveniente da necessidade gerencial, o qual pode e deve ser apoiado por ferramentas de TI para facilitar ao máximo a gestão de processos. Assim, o público-alvo de BPM deve incluir desde as pessoas ligadas à gestão de negócios até os profissionais de TI envolvidos na implantação das ferramentas de apoio1. Conforme demonstram as pesquisas, é cada vez mais necessário à área de TI das empresas possuir conhecimentos mais profundos sobre os processos de negócios, proporcionando o completo alinhamento das soluções de TI aos objetivos estratégicos do negócio8. Segundo Gartner, evidenciou-se que as organizações se encaminham para uma nova área de atuação com características específicas, seguindo-se inclusive, a mesma linha de pensamento desde o primeiro executivo da categoria de processos até a última função especializada8. A estratégia de BPM pode atribuir diversas funções aos diferentes papeis na organização. As iniciativas de BPM devem adaptar-se às exigências diversas. Antes de pensar em BPM, os usuários devem avaliar a prontidão da empresa para pensar em processos8. Para garantir a efetividade das soluções e da utilização da tecnologia BPMS, é necessária uma visão corporativa na qual se insere cada um dos fluxos de trabalho, entendendo-se a relação entre fluxo e a estratégia da empresa como forma de alinhá-los aos objetivos estratégicos. Esse tipo de visão incorpora também a cadeia de valores, de modo que possibilite entender o fluxo de atividade necessário para geração de produtos, independentemente da divisão funcional da empresa8. Sabe-se que a cadeia de valores é o conjunto de fatores responsável pela transformação dos recursos externos do negócio, em produtos e serviços percebidos como soluções pelos clientes e acionistas. É composta de processos, competências, lideranças, planejamento e estratégia, sistema de gestão e decisão e, finalmente a organização8. Observa-se que o aumento da competitividade do mercado aliado à redução dos custos de tecnologia ao longo desses anos vêm provocando uma migração do uso de recursos de TI do back-office para o front-office. Do mesmo modo o conceito de uma empresa monolítica, proprietária de todos os produtos, serviços e canais necessários para atender às necessidades dos clientes estão sendo rapidamente substituídos por parcerias estratégicas, empresas virtuais e cadeia de valores integrada8. Lembrando que a estratégia, segundo Igor Ansoff, serve justamente para moldar os processos para que eles atinjam os objetivos da organização de modo a aumentar a eficiência, mitigar e resolver os problemas operacionais7. No entanto existe uma grande distância entre estratégia operação. Até o momento a literatura mostra que é raro encontrar empresas com pessoas de

10

todos os níveis organizacionais conheçam a estratégia e os objetivos do negócio. É ainda mais raro encontrar pessoas que entendam como seu trabalho contribuiu para a estratégia da organização9. Embora seja evidente a necessidade de alta direção para acompanhar de modo eficaz a execução dos processos, com uma gestão efetiva do alinhamento estratégico8, como também alto grau de adequação dos recursos de tecnologia da informação frente às necessidades dos processos a fim de garantir a excelência e alcançar os objetivos do negócio8. Ainda há estudiosos como Hélio Pereira que conclui que não só é viável, mas recomendável executar projetos de BPM e BPMS independente do nível de maturidade estratégica da empresa. Por fim pode-se concluir que a solução completa de BPM envolve etapas como (Re)desenho, implementação, execução e monitoramento. Os projetos de BPM não necessariamente devem iniciar por uma etapa de desenho ou modelagem, pois pode acontecer situações em que o processo já está definido, implementado e executado por sistemas proprietários como, por exemplo, um ERP integrado com outros sistemas legados. Isso mostra que o problema da empresa motivo que a levou a uma solução inicial de BPM pode estar na falta de monitoramento de um processo já existente e execução10.

2.1 Diferentes Visões de Metodologias de desenvolvimento A ligação entre a gestão por processos, pensamentos sistêmicos e a teoria geral aos sistemas deverá ser o alicerce para as organizações que pretendem ou que já iniciaram suas atividades em BPM11. As organizações que ainda não trabalham com abordagem por processos tendem a conviver com problemas que dificilmente poderão ser mapeados, uma vez que permeiam as lacunas deixadas pela abordagem funcional. A abordagem funcional em uma empresa (organização) favorece a formação de feudos, desequilibra o fluxo, pois entre as atividades e contribui para uma qualidade de informação inadequada, dificultando a comunicação na empresa. De acordo com as premissas da teoria geral dos sistemas de LUDWIG NON BERTALANDFF, são de que sistemas existem dentro de sistemas, ocorrendo troca permanente com o meio que estão inseridos, influenciando e sendo influenciado por ele, uma vez que as funções de um sistema dependem de sua estrutura. BERTALANFF relata que a análise do todo é diferente da análise de cada parte, pois ao analisar cada parte não são focalizadas suas interações e para essa teoria, a natureza não está dividida em áreas, razão pela qual leva muitos princípios e conclusões de algumas ciências a também terem validade para outras11. Esse conceito também pode ser aplicado às organizações que assim como natureza, não podem ser divididas em partes isoladas nem podem isolar dentro de sim mesmas. Atualmente, ser sustentável passa por entender a si e ao ambiente externo, suas mudanças, as exigências atuais da sociedade e do meio ambiente, de modo que conduza as organizações a uma importante análise sobre interações existente entre seus subsistemas e entre ela e o meio onde está inserida11.

11

Por definição, “sistema” trata-se de um conjunto de elementos inter-relacionados que interagem no desempenho de uma função. Toda organização é em princípio um sistema, e o que relaciona os elementos de uma organização são as pessoas e os processos executados por elas11. Para Anthony Stafford Beer, grande parte dos problemas empresariais justificam-se pela incompreensão acerca do funcionamento de seus sistemas. Cada vez mais, será necessário estudar e entender o conceito de totalidade. Uma ação que produz mudança em uma das unidades pode produzir mudanças em todas as outras. As organizações que funcionam como sistema fechado segundo a termodinâmica, estão no estado final da sua evolução no ponto em que o sistema esgotou sua capacidade de mudar. Desse modo, seus subsistemas não interagem e ela não interage com o meio externo, perdendo, dessa forma, sua flexibilidade de adaptação11. Se não conhecer seus processos de negócio por meio de uma abordagem sistêmica, dificilmente uma organização terá sucesso na conquista de seus objetivos. Melhorou o “todo” significa melhorar cada parte de forma harmônica11. Abordar por processos significa derrubar as fronteiras funcionais e caminhar em busca de eficiência e eficácia, tendo sempre as necessidades do cliente como referencial absoluto. Significa desenvolver um processo sistêmico na organização, devolver visão de totalidade, abandonar o pensamento linear e trabalhar os círculos de influência11. Ao aprofundar um pouco mais na gestão por processos e na abordagem sistêmica, a organização analisa e estabelece seus objetivos estratégicos. Com base nisso, prioriza os processos críticos da sua cadeia de valor e determina os indicadores que lhe permitirão a medição de desempenho e a implantação de processos de melhora contínua11.

Figura 1: Fases de desenvolvimento de software na abordagem

12

Figura 2: Fases de desenvolvimento de software, adaptando-se a abordagem clássica para as necessidades do desenvolvimento de sistemas BPM.

2.2 Organização centrada na visão vertical x horizontal

2.2.1 Limitações que a visão tradicional das metodologias de desenvolvimento provoca à implantação de BPM

O desenvolvimento de uma organização com visão horizontal (por

processos) valoriza o trabalho em equipe, onde todos trabalham voltados para um objetivo final que se refere ao produto do processo. Já as estruturas funcionais são rígidas e pesadas e suas atividades são controladas por níveis hierárquicos. Neste caso ao analisar isoladamente os departamentos, nota-se que a organização não examina as interação entre elas nem o impacto que cada uma exerce nas outras11. Ao abordar um tema sobre desenvolvimento de software em uma ambiente empresarial, a primeira idéia que surge e a abordagem clássica das metodológicas tradicionais e suas fases de importância já consolidadas que são levantamento de requisitos modelagem, codificação, testes, implantação e manutenção. No entanto, um projeto que envolva o desenvolvimento utilizando BPM é necessário um desdobramento na organização dessas fases devido ao fato de que o desenvolvimento se torna um pouco mais abstrato, dando origem a uma nova camada na arquitetura que corresponde ao controle de fluxo de trabalho (workflow) 12. Quando as fases de desenvolvimento são abordadas de modo tradicional, pensa-se em software tradicional, em que todas as funcionalidades,

13

sobretudo, todos os fluxos, sejam bem conhecidos, definido e imutável, diferente de um projeto que envolva um workflow parametrizável12. O problema é que a maioria das equipes desconhece essa nova necessidade, ocasionando em omissão ou até confusão quanto às informações referentes à modelagem de processos, e ainda, mais comumente, confusão da modelagem do software com a modelagem do workflow12. Quando esses problemas ocorrem, provocam um grande impacto no desenvolvimento de um sistema, pois as mudanças que envolvem requisitos são impactantes na arquitetura do software. Mudanças arquiteturais, que podem se originar tanto em decorrência das mudanças de requisitos como em decorrência das falhas de modelagem, produzem grande impacto na codificação. É preciso, portanto estar ciente de que o processo de desenvolvimento de aplicação BPM necessita de cuidados e metodologias adicionais que não constam da engenharia de software padrão, e de que esses cuidados não podem ser subestimados, tratados como meros detalhes de desenvolvimento relegados às equipes treinadas nas metodologias tradicionais12. A relação entre processos horizontais x empresa verticalizada é uma contradição interessante. Os processos horizontais colocam as pessoas em um direção, a administração vertical tradicional coloca-as em outra. Conflito e confusão que afetam diretamente o desempenho da organização. Até nas empresas onde os processos foram correta e extensamente mapeados, existem dúvidas quanto ao seu real proprietário, e mesmo quando ela existe, suas ações efetivas sobre o processo ainda esbarra na hierarquia do organograma funcional da empresa6. Apesar das pessoas estarem habituadas a enxergar a empresa através de sua estrutura organizacional, no entanto, tal visão não permite identificar claramente o modo como às diversas áreas da empresa participam da geração dos produtos e dos serviços disponibilizados para seus clientes internos e externos. Essa dificuldade liga-se diretamente à visão organizacional verticalizada ou por silos, feudos em que cada profissional tem sua tarefa definida sob total responsabilidade do departamento, setor e área competentes, até o limite da estrutura organizacional. Apesar de, atualmente grande parte das empresas possuir suas estruturas organizacionais orientadas a funções, chamadas estruturas funcionais pura. Esse tipo de visão não permite identificar com clareza o que, como, e para quem a empresa executa as atividades. Além disso, não contempla as áreas em que não estão definidas responsabilidades e justamente nestas áreas que ocorrem muitas transferências de informação8. Por outro lado, algumas organizações já aplicam a estrutura matricial, na qual se mantém a estrutura organizacional, porém, acrescenta-se uma estrutura por processos, de modo que permita analisar a contribuição de cada atividade na geração de valor do negócio. Essa análise facilita a compreensão da vantagem competitiva de uma organização, visão que permite delimitar o contexto do negócio e identificar seus fornecedores e clientes internos e externos8. Ao contrário da estrutura funcional, a estrutura matricial transcende as fronteiras organizacionais, permitindo-se uma maior integração entre as áreas, a fim de se obter resultados que atendam aos objetivos estratégicos, táticos e operacionais da empresa8.

14

Foi diante desse cenário evolutivo que começou a surgir uma nova forma de pensar processo, isto é, em BPM, que funciona como uma nova estratégia corporativa tanto quanto um segmento do mercado de software. Lembrando que o foco é a gestão da eficiência e a eficácia dos processos no negócio vivenciados pela organização8.

Figura 3: Visão Departamental Figura 4: Visão de Processo

2.2.2 Importância dos recursos humanos no sistema de gestão de negocio

Ao passar de uma abordagem analítica para uma abordagem sistêmica as empresas mudam o foco do estudo isolado de cada uma das partes, partindo para análise do todo e das interações entre essas partes. No entanto, apesar de apontar para uma melhoria de resultados, essa abordagem traz consigo uma dificuldade de implementação pelas organizações, seja pela complexidade do estudo das relações humanas, seja pela existência de tradeoffs e paradigmas que precisam ser quebrados11. É importante saber que os recursos humanos, que atuam nos diversos subsistemas de uma empresa, são os elementos responsáveis pelo nível de interação estabelecido de forma que o fluxo de informação aconteça de fora para dentro de um processo para outro e de dentro para fora da organização11. Mesmo com todos os recursos tecnológicos existentes para suportar os modelos de gestão, o sucesso ou fracasso na adoção de qualquer um deles pela organização sempre estará relacionado à eficácia ou a ineficácia do desempenho do R.H. Desse modo pode-se dizer que se o R.H. de uma organização aprendem a crescer continuamente, teremos por conseqüência uma melhoria dos resultados. Todavia, apesar de serem os principais orquestradores do desempenho organizacional, muitas vezes os responsáveis pela execução dos processos não estão em sintonia com os objetivos a serem atingidos por tais processos11. Em síntese, a grande dificuldade das organizações, quando decidem gerir por processos e não por meio da gerência funcional departamental é perceber as coisas com uma visão processual que permeia os departamentos. A tendência e ater-se ao departamento. Em gerência de risco a visão departamental é muito comprometedora. Ao analisar o risco apenas de um departamento desconhecemos seu efeito sobre a organização como um todo. Um risco bem controlado em um departamento pode causar um problema enorme em outro3.

15

2.3 Vantagens e desvantagens do BPM O desenvolvimento de projeto de BPM apresenta-se cada vez mais abrangente e o ganho de produtividade com a orquestração e monitoramento de processos e a liberdade de modificar o fluxo desses processos são vantagens bastante sedutoras12. Gartner indica que empresas podem esperar melhorias operacionais e substanciais com praticamente qualquer processo5. As abordagens práticas e econômicas produzem os melhores resultados tanto que para Gartner o BPM representa o maior ROI (Return of Investmet)4, em iniciativas de TI apresentando 78% dos projetos com têm retorno maior que 15%; 67% são implantados em menos de 6 meses e 50% são implantados em menos de 4 meses9. O mercado de BPMS estará entre os de crescimento mais rápido até 2011, apresentando uma taxa de expansão anual de 24% entre 2006 e 201110. É importante observar que apesar dos inúmeros desafios e problemas nas implementações, a viabilidade técnica e o retorno sobre o investimento de projetos BPM são reais e bem documentados9. No entanto o desenvolvimento de um sistema de BPM envolve alguns desafios como a integração dos trabalhos de analistas de negócios e da equipe técnica. Quando a visão técnica ou visão de negócio predominam uma sobre a outra as chances de fracasso podem aumentar. Desse modo para o sucesso de um projeto de implantação de BPM, a metodologia de desenvolvimento deve se adaptar de forma a permitir o intercâmbio entre duas essas duas equipes, a fim de que elas possam ser complementares12.

2.3.1 Interação entre desenvolvedores e analista de negócio Ao desenvolver aplicação de BPM, devem-se dividir de maneira clara as tarefas relacionadas à especificação e à modelagem de processos como também as tarefas relacionadas à especificação e à modelagem do sistema em si. Por esse motivo, o analista de negócio torna-se uma peça fundamental, já que é de sua responsabilidade o levantamento dos processos junto ao cliente, como também sua especificação e modelagem12. Entretanto existe um desafio que envolve a integração entre as equipes técnicas e de negócio, e isso ocorre por vários motivos. O primeiro deles, cada equipe terá uma visão diferente sobre o sistema e muito provavelmente a equipe técnica confundirá os conceito de requisitos e processo, visto que é treinada para pensar no processo tradicional de desenvolvimento de software. Já o segundo motivo e mais complexo de se resolver, reside no fato de que cada uma das equipes possui um campo de conhecimento diferente levando cada uma delas a utilizar uma linguagem diferente para se comunicar e planejar seu trabalho. A troca eficaz de informação entre as duas equipes é imprescindível. Essa verdadeira distância de comunicação entre essas duas equipes atrasa o desenvolvimento do software12. Para isso é necessária a existência de uma linguagem para especificação dos processos, que possa ser compartilhada entre elas. Essa linguagem deve ser facilmente compreendida pela equipe de negócios e deve permitir a construção dos processos de maneira simples e rápida12.

16

Nota-se, portanto que o atual desenvolvimento de sistemas BPM apresenta não apenas desafios de metodologia, mas também técnicos inerentes à tecnologia. A abordagem BPM é mais que escrever um sistema convencional e envolve cuidados e metodologias específicas. Mais do que isso, é necessário uma engenharia de software adequado ao desenvolvimento de sistema que envolvem processos. Não basta uma equipe de negócio envolvida no projeto. Mais do que isso é necessário um meio de integrar a equipe aos desenvolvedores12.

2.3.2 Tipos de problemas nas implementações

Os principais fatores que podem levar ao fracasso um projeto BPM estão classificados em três etapas básicas de um projeto padrão envolvendo a seleção/projeto o desenvolvimento e a utilização da solução de BPMS6.

2.3.3 Quanto à seleção da solução e com o projeto da aplicação de BPM

2.3.3.1 Pouca atuação ou exclusão da área de TI

Toda compra de produtos de software deveria ser uma iniciativa da área de TI. No entanto, nem todas as empresas possuem essa conduta definida, concedendo a uma diretoria de negócio o poder de definir e comprar uma solução. Colocando a área de TI numa posição coadjuvante num tipo de projeto em que ela deveria ser a protagonista. Essa abordagem gera tensão interna e expectativas excessivas por parte do cliente, sendo que é mais um elemento que a TI necessita lidar no seu dia-a-dia. Além, disso no processo de pré-venda e apresentação dos produtos, os fornecedores insistem na idéia de completa autonomia da solução em relação ao envolvimento da equipe de TI da empresa. Infelizmente o projeto real se apresenta bem mais complexo do que gostariam. Projetos patrocinados por uma diretoria de negócios mal sintonizados com a área de TI darão origem a uma relação de dificuldades técnicas intermináveis. Quando não há apoio e comprometimento da área de TI no projeto, os consultores externos pouco ou nada podem fazer para construir a necessária integração da aplicação de BPMS com aplicativos do cliente6.

Por outro lado, os projetos vencedores são geralmente conduzidos pela área de TI e se desenvolvem com total comprometimento do CIO (Chief of Information Office). Trata-se de um CIO com atitude visionária que não vê nesse tipo de projeto uma perda de poder ou de responsabilidade sobre os processos, mas sim uma tecnologia capaz de oferecer efetivas melhorias para o negócio6.

2.3.3.2 Enfoque no produto

Quanto maior a distância da área de TI ao processo de seleção maior a tendência da análise se tornar superficial, com o enfoque direcionado para as questões de negócios. Enfim, avaliar exaustivamente o componente de serviços desconsiderando aspectos técnicos da consultoria de implementação, seu histórico de sucesso e insucesso, sua equipe técnica, sua capacidade de entrega, é uma grande fonte de problemas para o projeto. Mesmo o melhor dos

17

produtos pode não ser bem implementado, resultando num projeto fracassado. Em geral todos os produtos possuem suas peculiaridades e exige curva de aprendizado que deve ser considerada. Isso se refere aos produtos em desenvolvimento com lançamento de novas versões, com acréscimo de funcionalidade e complexidade crescente e que o clientes não possuem internamente pessoal qualificado para resolver as questões de ambiente de desenvolvimento ou que não foram devidamente informados pelos fornecedores. Desse modo, o projeto fica comprometido e seus objetivos não são alcançados6.

2.3.3.3 Indefinição quanto ao efetivo proprietário do processo

Quase todas as apresentações de BPM fazem referência à mudança promovida pela troca da visão de cilos de informações para a visão dos fluxos de informação horizontal. Apesar de essa mudança ser real, poucas empresas avançaram para dar a efetiva importância aos seus macro-processos em função da estrutura hierárquica tradicional. Isto significa que não são realizadas as mudanças fundamentais no gerenciamento das suas organizações. Na maior parte das empresas, o poder ainda reside nas suas unidades verticais, estruturadas em regiões, em produtos ou em funções. E esses feudos guardam de modo ferrenho seus territórios, seus recursos, suas pessoas e seu conhecimento6.

2.3.3.4 Seleção dos processos a serem implementados

Nem todos os processos da organização são elegíveis para o projeto de BPM. Essa decisão irá influenciar na análise do custo-benefício do projeto, podendo neste sentido pecar por falta ou por excesso. Selecionando processo administrativo excessivamente simples, a empresa poderá adquirir know-how para projetos de maior visibilidade e de retorno efetivo para o negócio. Por outro lado, ao selecionar um macro projeto para o primeiro projeto também pode ser demasiado, ambicioso e desafiador. Em geral, a empresa deve considerar o primeiro projeto um aprendizado. Além disso, é saudável para a consultoria externa ser posta à prova em um processo menor. Sendo assim, minimizam-se os riscos da implantação imediata, em uma nova tecnologia, do processo mais importante para o negócio e dentro de um conceito ainda não totalmente entendido e absorvido pela empresa6.

2.3.4 Quanto à aplicação de BPM

2.3.4.1 Definição do escopo do projeto

Algumas empresas nem fazem idéia do conhecimento técnico necessário para se desenhar os processos. Outras acreditam que com a contratação de um ou dois estagiários é possível realizar tal atividade sem prejuízo algum. Diversas outras contrataram, em algum momento, uma consultoria de mapeamento do processo a qual entregou ao final dos trabalhos diversos processos muito bem desenhados. Tudo parece muito simples aos diante da alta gestão. Infelizmente, tomando-se por base essa documentação já existente para o projeto de BPM, o capricho na documentação encontrada é

18

muitas vezes inversamente proporcional ao grau assertividade desses processos. Mas não por que o trabalho foi mal feito pela empresa de consultoria e sim por que foram desenhados com foco na regra principal do processo e sem um completo detalhamento das exceções, sendo que os projetos evoluem e se modificam e seus desenhos ficam desatualizados e assim a medida que desenvolvimento vai se desenrolando, fica evidente um desencontro entre a teoria e a prática e como projeto já está em funcionamento, a equipe de desenvolvimento faz modificações enorme, aumentando a complexidade do desenho do projeto e incrementando a lista de exceções, prejudicando a validação dos processos desenvolvidos no projeto. Outros pontos muitas vezes negligenciados diz respeito à escolha da notação a ser utilizada no mapeamento dos processos. A importância dos padrões escolhidos para realização de um bom trabalho, se faz necessário para não ter que tentar implementar, através de uma solução que não oferece suporte, acarretando atrasos pelas alterações nos desenhos e codificações de elementos não previstos6.

Percebe-se que as empresas que iniciam um projeto de BPM por uma revisão efetiva dos processos, desenvolvidos por profissionais experientes, independentes e conscientes das demandas desse tipo de projeto, diminui drasticamente os problemas do desenvolvimento e o risco geral do projeto6.

2.3.4.2 Complexidade do ambiente de desenvolvimento da aplicação

Na prática, cada solução demanda um ambiente particular para o

desenvolvimento da aplicação de BPM. Alguns desses ambientes apresentam-se extremamente complexo, e mesmo os projetos conduzidos por fornecedores e consultores experientes não conseguem simplificar o ambiente que será futuramente administrado pela empresa-cliente. É na prática que serão expostos todos os detalhes pertinentes ao ambiente, sua infra-estrutura, controle de versão e manipulação dos objetos e bibliotecas do projeto. Por isso é importante a integração entre os sistemas do cliente e a aplicação de BPM6.

2.3.5 Quanto à utilização da aplicação de BPM

2.3.5.1 Desinteresse das pessoas

Refere-se ao engajamento das pessoas no processo. Essa atitude não está associada ao patrocínio da alta gestão ao projeto, mas decorre principalmente da forma como o projeto foi conduzido e implementado pela equipe que o desenvolveu. Se existe uma expectativa de mudança cultural e conseqüente melhoria nos processos que serão atendidos pelo projeto de BPM, é importante que se tenha também a expectativa de que haverá uma mudança envolvendo as pessoas e as maneiras como elas atuam na empresa.

Um bom projeto de BPM, deverá ao seu final, obter naturalmente um forte comprometimento das pessoas envolvidas desde o primeiro dia do projeto6.

19

2.3.5.2 Dificuldades para implementação das mudanças

De acordo com os princípios de BPM a evolução do processo deve ser progressiva e positiva. A evolução do processo implementado será dificultada se o processo a ser implementado for excessivamente rígido, mal documentado ou que seu ambiente de desenvolvimento for complexo6.

É de extrema importância avaliar o quanto à empresa será dependente de recursos externos para o pós-projeto. A falta de disponibilidade ou de capacidade de recursos internos para implementar as mudanças é um problema que vai provocar a morte do projeto tão logo as pessoas encontrem maneiras de contornar suas dificuldades e implementar as mudanças por meios próprios. As pessoas sempre descobrem meios de realizar o trabalho. Uma vez que o processo implementado esteja condenado, dificilmente será recuperado6.

2.3.5.3 Performance da aplicação

Se não levar em consideração a complexidade do processo bem como a capacidade do ambiente o qual será implementado, o uso contínuo da solução em vigor poderá resultar numa degradação da aplicação, que vai determinar seu fim precoce ou onerar a empresa com maiores investimentos não previstos na infra-estrutura do ambiente de produção. Não adianta chegar ao final do projeto com uma aplicação que apresente problemas de performance, não importa se a responsabilidade possa ser atribuída ou dividida com seu fornecedor. Um mau desempenho é um forte indício de um mau projeto. Um desenvolvimento mal conduzido por desconhecimento da solução ou das melhores técnicas de BPM pode ser a fonte da má performance6.

Apesar dos problemas citados, os casos de sucesso com BPM demonstram ganhos de conformidade, controle e agilidade tanto que Gartner descreve que o fato de tornar explícitas as entregas, tempos e responsabilidade de um processo, aumentos de produtividade de 12% são normalmente alcançados. Essas vantagens, Hélio Pereira, confirma que já justificam os investimentos em projetos de BPM e ainda ressalta que quando bem-projetados e implementados, resultam em maior lucratividade7.

3 Modelagem de Processos de Negócios

3.1 Processos de Negócios

Por definição processo refere-se a um encadeamento de atividades inter-relacionadas e executadas dentro de uma companhia ou organização que transformam entradas em saídas4. É importante saber, que o processo por sua vez, para atingir um objetivo, utiliza o tratamento da informação definida nos requisitos, em uma determinada seqüência. A organização de um processo pode mudar com uma freqüência muito maior do que tratamento da informação definida em cada requisito e isso ocasiona em dois problemas como a possibilidade de se considerar um processo ou parte de um processo como requisito de sistema e

20

programá-lo de maneira que ele não possa ser alterado, ou a possibilidade de flexibilizar e permitir alterações em um requisito do sistema que não deveria obter mudanças12. O modelo proposto por Shur(2006), divide os processos em três categorias:

3.1.1 Processos de Governança Os quais estão envolvidos os processos de gerenciamentos, processos

de BPM, Business Intelligence, desenvolvimento de estratégia de negócios e arquitetura empresarial4.

3.1.2 Processos de gerenciamento

Correspondem ao gerenciamento financeiro, controladoria, gerenciamento de informação, o BPM propriamente dito, gerenciamento da qualidade, gerenciamento de recursos humano, gerenciamento de ativos4.

3.1.3 Processos operacionais

Destinados a desenvolver atividade fim da empresa como CRM, logística, desenvolvimento de produto, PCP, gestão de material4.

Apesar de nenhum modelo apresentar todos os inúmeros processos de negócio existentes nas organizações do mundo inteiro a uma excelente estrutura de trabalho para classificação de processos, que é a American Productivity & Quality Center (APQC 2006). Como mostra a figura 54.

Figura 5: Modelo de Estrutura de Trabalho para Classificação de Processo.

Fonte: APQC(2006)

21

A visão por processo nas organizações pode se apresentar de diferentes maneiras e a medida que isso se difundi as formas contemporâneas de racionalização tendem a ver as organizações como um feixe de processos, sendo que alguns deles pertencem a um departamento denominado intra-funcionais, enquanto que outros são trans-funcionais pois, atravessam departamentos como mostra as Figuras 3 e 4, lembrando que a visão por processo procura entender o que precisa ser feito e como fazê-lo onde as tarefas não são definidas exclusivamente em função dos departamentos da organização. Observe que na Figura 4 um processo pode cruzar departamentos e solicitar serviços de cada um deles, dependendo da atividade a ser executada4. Apesar dos processos nem sempre correrem de acordo com o modo previsto, as técnicas contemporânea buscam esclarecer a contribuição de cada processo para agregação de valor, como também para geração de saídas indesejadas (ISO 14000) e para o controle do desempenho e ainda para a responsabilidade social da empresa. Considerando sobretudo que o modo como os processos ocorrem de fato dependem muito de seu contexto e de seu conhecimento disponível4. Dificilmente os departamentos deixariam de existir por conta da visão por processo, uma vez que as inovações não abolem a visão funcional que continuar sendo útil em muitas as situações gerenciais. Sendo assim a quantidade de departamentos pode até diminuir, alterar as responsabilidades, descentralizar, usar estrutura e matriz, mas isso não diz que deixará de existir a estrutura hierárquica na forma de organograma como é de costume4.

Os objetivos da modelagem de processos de negócio é obter entendimentos de como a empresa funciona internamente4. Os artefatos como organogramas, diagramas de posicionamento, fluxos de processos são formas visuais de compreender o que as pessoas fazem no dia a dia de suas atividades, e servem como ponto de partida para outros estudos, como melhorias nos processos e estimativa de custos por atividades, como também propicia a forma correta de compreender os processos corporativos13. A modelagem de processos de negócios é importante pois nos faz compreender a empresa e os mecanismos que foram utilizados para que funcione. É fundamental não apenas como etapa pré-desenvolvimento de um sistema, como também para adequação de uma solução de mercado, como um ERP, CRM, etc13. Sabe que as disciplinas de modelagem de processos tiveram destaque no final da década de 80 e início da década de 90 através de estudos de cientistas como Michael Porter. Neste período os estudos matinha o foco em administração de empresas centrando esforços em como as empresas poderiam ser melhoradas em termos de estrutura organizacional. Foi observado que os processos de construção das empresas eram feitas de forma desestruturada, onde os novos departamentos e processos eram criados conforme a demanda. Talvez até não comprometessem a saúde da empresa se o mundo não fosse globalizado. No entanto diante do uso da internet e conseqüente globalização, as empresa grande começaram a competir com as empresas pequenas, de igual para igual, e a necessidade por uma redução de custos e melhorias de processos junto ao cliente se tornou necessária para garantir a sobrevivência num ambiente competitivo. Nessa época o foco dos

22

estudos era como melhorar os processos, embora a equipe se esforçasse de modo isolado para resolver tais problemas estes esforços ainda não estavam integrados para formar o conceito conhecido com hoje solução BPMS13.

3.2 Principais tipos de processos de negócios BPMS: Funciona também como broker, um intermediário, o link que faltava entre estratégia e operação.

BPMS pode servir como a liga entre movimentos estratégicos e práticas operacionais (como por exemplo: ERP, CRM, SCM, SFA) pois a capacidade de a organização mudar os processos sob demanda.

Cada processo colocado dentro da gestão BPMS gerará subsídios para o alinhamento estratégico e contribuirá para o refinamento da estratégia, da tática e das operações. É o conceito de melhoria contínua sendo adotado gradualmente9.

“Uma solução BPMS permite a geração e controle dos processos de negócio da empresa, proporcionando rápida tomada de decisão e realinhamento dos processos de negócios de forma agilizada”13.

BPEL ou (PPL4WS): trata-se atualmente de uma notação padronizada,

mais próxima do BPMN, para execução de processos. A sigla é o anagrama de Business Process Execution Languange e foi criada como uma forma de permitir a orquestração de serviços web (Web Services). Como uma linguagem para execução de serviços, ela é formal e não permite ambigüidade. Uma das idéias no mercado é que seja utilizada na execução de fluxos de atividades. Em essência, o BPEL é um arquivo XML13.

BPMN: para o analista de negócio, o BPMN será o padrão dominante

para desenho nos próximos anos, já que vem sendo uma notação de destaque na atualidade. (Business Process Modeling Notation), além de mais moderna que notações com IDEF e UML, também possui um rico set de elementos gráficos para representação de uma série de situações que acontecem nos fluxos de processos. Porém, felizmente o BPMN é uma notação gráfica para desenho de processos que não está associado a nenhum formato de armazenamento específico13.

SOA: (Service Oriented Architecture) – Arquitetura Orientada para Serviço trata-se de uma maneira de organizar as unidades de construção de uma empresa em componentes com fraco acoplamento, reutilizáveis e localizáveis13.

3.3 Princípios de modelagem para desenvolvimento de sistema Independente da linguagem utilizada a modelagem de processo segue alguns princípios:

3.3.1 Aderência

23

Utiliza-se de técnicas de levantamentos de validação de modelos e simulações a fim de aproximar o modelo o mais próximo da realidade da empresa14.

3.3.2 Relevância

Os objetos a ser modelado deve ser analisado para o desenvolvimento do sistema de software e assim evitar equívocos14.

3.3.3 Custo x Benefício Deve ser avaliado o custo que terá o objeto do desenvolvimento de sua utilidade14.

3.3.4 Clareza Este princípio se refere as linguagem visuais pois o modelo serve como base de entendimento para a equipe de desenvolvimento14.

3.3.5 Comparabilidade

Refere-se a necessidade de comparação entre os diferenças processos. Para concluir, modelar sistemas é uma tarefa importante para o desenvolvimento dos sistemas e existem vários métodos, linguagem e aplicativos para realizar com eficiência e eficácia a modelagem. O melhor método e a melhor linguagem é sempre aquele que atende à necessidade do sistema de software a ser desenvolvido. Assim como o melhor negócio e aquele no qual todo mundo ganha. A melhor modelagem é aquela que satisfaz da melhor maneira possível o programador, analista de processos, analista de sistema e principalmente consiga trazer o processo correto a ser desenvolvido para satisfação do demandante14.

3.4 Tipos de visão global de processos

A metodologia comentado por Harrington, Esseling e Ninwegen prove uma visão global de processos que permite inclusive um indexação sobre processo que criar referencias para posterior demonstração como mostra a. Figura 6 abaixo4.

24

Figura 6: Visão Global de Processos segundo modelo de Harrington, Esseling e Ninwegen.

Fonte adaptado de Harrington, Esseling & Ninwegen (1997). A metodologia adotada por Jacka & keller de 2002 que cria uma estrutura que permite aos envolvidos perceber, de imediato uma série de diagramas globais de processo e que fornece uma visão simplificada do tempo de execução dos sub-processos e suas respectivas seqüências de execução conforme figura 7 abaixo4.

Figura 7: Visão Global de Processo segunda Jacka & Keller.

Fonte: Adaptado de Jacka & Keller

25

Lembrando evidentemente que a visão global de processo não é o único recurso para alinhar os processos à visão e à missão da organização. Porém em virtude da simplicidade de construção, é um recurso útil de visualização, compreensão e discussão4.

4 Ferramentas para Modelagem de Processos de Negócios Hoje o mercado possui um gama de soluções BPMS, desde as de códigos aberto até as comerciais. Cada uma delas adotou, no desenvolvimento, decisões que afetam não só sua forma de utilização como também sua integração com outras ferramentas corporativas. No mercado, tem-se a impressão de que, se a ferramenta suportar algumas siglas definidas por certos padrões, haverá compatibilidade total e, no momento da implementação, estaremos totalmente livres de decisão(Glauco Reis). Muitas áreas empresarias, de negócio dão início à documentação dos processos de negócios, uma vez que se conscientizaram da necessidade de se ter maior domínio sobre esses procedimentos. No entanto, uma parte delas ainda está reticente quanto aos investimentos na área, já que, neste momento, não se deseja investir sem uma clara visão de futuro. Algumas empresas ainda se envolvem profundamente nesse processo de modelagem, documentando-se praticamente todos os macros processos até seu nível mais baixo de detalhamento12. Se a empresa pretende apenas desenhar os fluxos de processos, sem a prerrogativa de execução futura em uma solução BPMS, mas somente com a Intenção de entender o negócio, qualquer ferramenta de boa qualidade poderia ser utilizada12. Entretanto, mesmo nesse caso quando os gestores começarem a perceber as vantagens de se ter um processo em execução, com controle, capacidade para realinhamento rápido do negócio, possibilidade de tomada de decisão através de Dashboards, mesmo os gestores mais céticos em relação a todas essas tecnologias sentirão uma imensa vontade ou necessidade de operacionalizar os processos12. Nesse momento, dependendo das escolhas anteriores, pode ser tarde demais ou pode-se forçar a empresa a ter imensos gastos na migração dos desenhos e modelos, causando-se uma decepção com relação à tecnologia12. Umas das formas de se desenhar o processo é por meio da escolha de uma ferramenta genérica para desenho, fornecida gratuitamente pela maioria dos fabricantes, visto que o grande “ovo de Colombo” está na ferramenta que executará esse processo. Como na maioria das vezes o formato de armazenamento é proprietário, concluída a tarefa de documentação dos processos, o próprio analista de processo acaba por influenciar na decisão da escolha da ferramenta de operacionalização do processo como sendo a do próprio fabricante da ferramenta de desenho. Isso por que tal atitude minimiza o impacto e a necessidade de se refazerem trabalhos nos desenhos criados12. Quando for utilizada alguma ferramenta visual como notação BPMN, alguns elementos gráficos como eventos gerados por dados não terão mapeamento direto para o BPEL, sendo normalmente disponibilizados por serviços de execução. O início de uma atividade causada pela alteração no valor de uma cotação, por exemplo, precisa ser codificada como elemento

26

programático e disponibilizada como Web Service. É fundamental esclarecer que o BPEL orquestra “apenas” Web Services. Mesmo empresas que adotaram unicamente o SOA, se o mecanismo de comunicação entre os serviços não for Web Services, o BPEL é inaplicável12. O BPEL ainda não define nada relacionado às telas de interação com o usuário. Isso significa que, se a ferramenta de desenho estiver gerando BPEL, serão necessários outros artefatos para que a TI tenha condições de operacionalizar o processo da forma esperada12. Existem no mercado soluções BPMS que integram com diversas tecnologias, como EJB, Corba, DCOM, entre outras, Passar a adotar Web Service simplesmente porque a ferramenta de desenha geral BPEL é limitar o rol disponível de possibilidades tecnológicas, e nem sempre é desejável utilizar Web Services. Algumas vezes, questões de segurança e velocidade obrigam a adotar outros mecanismos de comunicação. Talvez um dia tenhamos empresas com todas as funcionalidades disponibilizadas como Web Services, mas não é essa a realidade atual. Pelo grau de maturidade de algumas soluções BPMS, atualmente o BPEL parece ser mais um empecilho do que uma ajuda na operacionalização dos processos, mas sem dúvida é um ponto de decisão e a escolha deve ser consciente12. Por um lado o BPEL é fantástico, visto que uniformiza a TI em um único jargão: os Web Services. Por outro lado, ele não é valido para aplicações que demandam troca de documentos, por exemplo, como também não é muito adequado a aplicações com interações humana intensa. Uma aplicação do tipo GED ficaria deficiente quando implementada por intermédio do BPEL12. Atualmente a melhor forma de se desenhar um processo é por meio da notação BPMN, que é muito completa. No entanto, sua especificação preocupou-se apenas com a definição dos elementos visuais, desconsiderando-se o formato de armazenamento. Algumas ferramentas de desenho armazenam em formato XML, mas é ilusório acreditar que sejam compatíveis entre si duas ferramentas que suportam formatos XML para armazenamento de notações BPMN. O formato XML é absolutamente genérico e seria o mesmo que conceber dois arquivos TXT com compatíveis entre si. Neste momento, é possível relatar um caso recente de uma empresa cujos desenhos forma feitos com o Provision (que suporta notação BPMN), e o momento da operacionalização para o Aqualogic/Fuego (que também suporta o BPMN), todos os desenhos de processo tiveram que ser reescritos, já que não havia ferramentas de migração dos desenhos criados entre as ferramentas de desenho12. Sendo assim, parece que a melhor alternativa é utilizar uma ferramenta que empregue a notação BPMN para desenho e a notação BPEL para armazenamento. Se a portabilidade é primordial na implantação de um projeto em uma empresa, essa parece ser a solução mais adequada. Mas isso é errado em dizer, percebe-se que ainda há uma série de deficiências nesse mapeamento. Enquanto os fluxos básicos, condicionais e exceções podem ser mapeados sem problemas, pools e lanes não tem mapeamento direto para o BPEL4WS. Portanto, se o processo desenhado for do tipo colaborativo (pessoa interagindo com parte de um processo), toda a determinação dos perfis definidos para os acessos deverá ser simulada programaticamente12.

27

4.1 Soluções que geram código Algumas soluções BPMS geram, como produto final, arquivos de configuração que executam em um engine proprietário. É o caso do Aqualogic/Fuego, que gera como produto final diversos arquivos XML e alguns códigos empacotados dentro de um ZIP. O engine de execução trata esses arquivos, apresentando o resultado esperado por estes. Funciona mais ou menos como se fosse um interpretador em uma linguagem de programação12. Outras soluções, como a IBM, geram códigos verdadeiros por trás do processo de geração. Esses códigos executam nativamente como aplicações J2EE. As duas abordagens precisam ser avaliadas de acordo com as necessidades da empresa. Por um lado, a manutenção de soluções como as da IBM tende a ser mais difícil por se tratar de aplicativos reais J2EE. Por outro lado, são muito mais rápidas e podem ser otimizadas em termos de código, pode-se utilizar depuradores de códigos J2EE e depuradores, gerando-se um resultado muito satisfatório12. As ferramentas interpretadas, como o Aqualogi/Fuego exigem menor esforço em manutenção e permitem a execução de diversos processos, já que eles envolvem arquivos versões. A desvantagem é que como a interpretação é interna ao engine, dificilmente se consegue depurar a execução de uma instância de processo, e as otimizações somente são possíveis com ferramentas fornecidas pelo próprio fabricante12.

4.2 Soluções Open Source Nem sempre uma solução BPMS open source é garantida de padronização. Ela vai facilitar a correção bem mais rápido pela comunidade. Porém existe uma tendência de adoção mais veloz dos padrões que vão aparecendo durante o ciclo de vida do produto, mas a principal vantagem do open source é o fato de a empresa não ficar sujeita às mudanças comerciais de um fabricante. Uma solução BPMS, se bem implementada, torna-se rapidamente a “espinha dorsal” de uma empresa, criando-se um barramento padrão em que todos os processos se comunicam, conhecido com ESB (Enterprise Service Bus). A troca dessa “espinha dorsal” pode ser um tanto custosa, já que é o local onde acontece toda comunicação entre os elementos dos processos12. Normalmente, as soluções open source tendem a gerar mais esforço de programação, mesmo por que, em um produto comercial, os fornecedores se esmeram em proporcionar ferramentas visuais e “wizards” que facilitam a geração final. Normalmente, as iniciativas open source preocupam-se mais com a parte de infra-estrutura, deixando para o programador a tarefa de conexão entre os elementos12.

4.3 A escolha de uma solução BPMS. Esta escolha dever ser feita com muito critério, visto que há divergências diametrais entre uma e outra. Soluções open source, por exemplo, assim com o jBPM, são totalmente programáticas. Isso significa que, para cada atividade do processo, deverá ser criado um código para executar a tarefa. Por outro lado, algumas soluções BPMS são tão completas que permitem, de forma

28

totalmente visual, a criação das telas, objetos de negócios e conexão dos mesmos aos fluxos. A escolha de uma ferramenta de desenho inadequada pode tornar toda a operacionalização dos processos uma tarefa muito difícil e dispendiosa. As melhores alternativas parecem recair sobre ferramentas de desenho que já estão integradas com alguma ferramenta de execução. Deve-se estar consenti de que a documentação dos processos em uma empresa é apenas uma etapa de um conjunto maior, que irá permitir a execução, o acompanhamento e o realinhamento contínuo. Sem ferramentas que dêem suporte adequado a todos esses itens, acaba-se com um bonito desenho em mãos, sem muita utilidade prática12.

4.4 Classificação das ferramentas de TI com aplicações em BPM Para facilitar a visão do uso das ferramentas de TI no âmbito do BPM, torna-se mais prático se o fizermos de acordo com as atividades que precisamos desenvolver, ou seja, devemos relacionar essas ferramentas ao Ciclo de BPM, o que envolve quatro atividades básica, conforme figura abaixo4.

Figura 7: Ciclo de BPM

§ Planejamento do BPM; § Modelagem e otimização de processos; § Execução de processos; § Controle e análise de dados.

29

Ao analisar as ferramentas de TI sob este prisma, provavelmente não haverá ferramenta de TI que não se aplique a alguma fase do ciclo de processo de negócio. Qualquer uma delas pode encontrar sua utilidade em pelo menos uma das fases do BPM, dependendo do processo em execução, ou ao menos ser utilizada na infra-estrutura4.

O Termo geral inicialmente usado para as ferramentas de TI aplicáveis

diretamente ao BPM foi denominado BPMS – Business Process Management System. Alguns estudiosos do assunto, como McGoveran (2006), afirmam que um BPMS é uma suíte de produtos de software integrados e com a finalidade de habilitar o BPM. Porém uma análise mais detalhada das suítes disponíveis no mercado não confirma tal forma de enxergar o BPMS, pois uma única suíte não teria condições de solucionar todos os problemas de BPM das organizações4.

Com isso existe um questionamento clássico sobre a melhor ferramenta para BPM. Podemos afirmar com total segurança que a resposta mais óbvia seria então uma outra pergunta: ferramentas para fazer o que no BPM?

Figura 8: Referência de arquitetura para ferramentas de TI aplicáveis ao BPM4

Esta figura mostra a classificação das ferramentas de TI, aplicadas no

âmbito do BPM, de acordo com seu uso em processos. Podemos observar de imediato uma clara divisão:

· Camada de ferramentas diretamente aplicáveis ao BPM: que constitui as normalmente procuradas pelos profissionais como sendo ferramentas de BPMS.

30

· Camada de infra-estrutura: vão servir de apoio às ferramentas de BPMS, bem como a outras ferramentas e sistemas dentro da organização.

A figura 8 foi bem clara em dizer que para compor uma solução total de

BPM são necessárias várias ferramentas e que também não precisa ter um pacote de ferramentas de um único fabricante.4

Certas ferramentas se propuseram a implantar BPM com soluções

integradas para tratar o planejamento estratégico, modelar, simular, implementar processos e fazer o controle dos indicadores associados, bem com de outras funcionalidade e características relacionadas4.

Estas ferramentas ficaram conhecidas no mercado com purê-play, ou seja, dedicadas exclusivamente a BPM. Porém, uma análise das pesquisas efetuadas pelo Gartner, em 2004 e 2006 (Gartner, 2006a e 2006c), indica que não ocorreu evolução dessas ferramentas conforme esperado. Nesta pesquisa podemos constatar que ocorreu uma grande redução da quantidade de ferramentas no mercado, e também um aperfeiçoamento das funcionalidades aplicadas em BPM4.

Em Gartner (2006b) podemos observar que ferramentas de modelagem isoladas possuem características muito melhores do que as similares embutidas em suítes.

Desta forma não haveria necessidade de falar sobre uma ferramenta única que pudesse contemplar todas as etapas do BPM. Algumas características deveriam estar presentes em uma segunda geração de ferramentas de BPMS, que integram de forma direta as seguintes tecnologias, e que muitas delas também se encontram disponíveis em produtos independentes.4

· Modelagem gráfica do processo não criar representação visual do

processo de trabalho. Deve refletir, pelo menos duas perspectivas: funcional (para os profissionais que usam o processo) e informacional (para as equipes de TI).

· Motor de orquestração (Orchestration engine, por exemplo BPEL) para

coordenar a seqüência de passos e tarefas, de acordo com o fluxo do processo e as regras do negócio (BR).

· Ferramentas de análise do processo (business intelligence, e

business activity monitoring [BAM]) para apoiar a análise dos dados produzidos durante a execução, criar relatórios analíticos on-line para os dados com apresentação em painéis de controle visuais (dashboard), gerar alertas em tempo real, entre outras funcionalidades.

· Motor de regras de negócio (business rules engine) facilmente

acessível aos responsáveis pelo processo e não apenas a programadores.

31

· Repositório de metadados (metadata repository) que contenha os modelos de processos, as regras de negócio e outros metadados comuns aos vários processos.

· Simulação e otimização:(simulation/optimization) que permitem a

comparação dos processos atuais com os modelos futuros, além de fazer a análise de risco.

· Integração: para permitir conexão com outros sistemas.

· Repositório de documentos e conteúdos: para os dados estruturados

e não-estruturados que não façam parte dos metadados dos processos, mas que façam parte da documentação deles.

Podemos notar que ocorreu um melhoramento nas limitações dessas

ferramentas, separando funcionalidades estratégicas, de execução e monitoramento global dos processos, em que ferramentas isoladas de BSC, BI, ERP, Workflow, ECM, CRM pode ser amplamente aplicadas e integradas para obter melhores resultados. Vales destacar agora que os grandes fornecedores do mercado tendem a padronização do uso de suas ferramentas para plataforma que rodam sob o modelo SOA (Service-Oriented Architecture), o que facilita muito a integração dos processos envolvidos4.

4.5 Aplicação na implantação e execução de processos

Devido a grande diversidade de tipos de processos, variadas ferramentas de TI são empregadas na sua execução ou como item da infra-estrutura. Entre aquelas que controlam a execução de processos, podemos destacar:

· ERP: uma ferramenta que usa bancos de dados e processos integrados, uma ferramenta de maior foco para automação e integração de processos relativamente estáveis e com informação estruturada4.

· Workflow: possui uma característica que corresponde à flexibilidade.

Não encontrado em sistemas prontos e pacotes fechados, melhora a visibilidade dos processos através de sistemas gráficos, alteração rápida de um processo e locais onde se pretende implantação rápida e versátil de processo de automação4.

· CRM: ferramenta usada nos processos de relacionamentos com

clientes4.

· Agentes Inteligentes: são sistemas computacionais residentes em ambientes dinâmicos complexos, que percebem e atuam autonomamente e, ao fazê-lo, cumprem um conjunto de objetos para os quais forma programados4.

32

· Sistemas especialistas: sistemas que são capazes de realizar trabalhos que merecer ser considerados inteligentes, mas um sistema que nunca atingirá a capacidade cognitivas do especialista humano.

· Ferramentas especialmente construída para processos particulares

(aplicação para B2B, SOX, softwares contábeis, etc.): softwares desenvolvido para realizar uma tarefa específica de um processo4.

4.6 Aplicação no Controle monitoramento

Estas são ferramentas que possibilitam um gerenciamento do desempenho do processo que estão em uso. Além de relatórios de dados associados aos KPI´s e outros indicadores operacionais o que mais tem destaque com os usuários é a possibilidade de criação de painéis de visualização do andamento dos processos (dashboards ou cockpits).

Além de ferramentas de infra-estrutura para controle de desempenho (Data Warehouse e Data Maning) que trabalham com os bancos de dados, existe outras ferramentas que são diretamente ligadas ao controle e monitoramento deles4.

· BSC – Balanced Scorecard onde ele pareça ser mais uma metodologia

do que um software, várias empresas desenvolveram produtos que apóiam a suam implantação. O propósito do BSC é a criação utilizando fortemente indicadores para maximização dos resultados baseados em quatro perspectivas (financeira, clientes, aprendizado e crescimento e os processos internos) que refletem a visão e estratégia da organização4.

· BI – Business Intelligence que permite às empresas fazer uma

acompanhamento geral contidas em um Data Warehouse ou Data Mart, no sentido de desenvolvimento de percepções e entendimento a seu respeito permitindo melhor tomada de decisão4.

· Ferramentas de CEP – Controle Estatístico de Processo: já usada no

controle de processos indústrias de manufaturados4.

· BAM – Business Activity Monitoring: das ferramentas relacionadas anteriormente, o BAM surgiu com a intensificação do uso do BPM por volta de 2002/2003, o qual tornou possível o relacionamento mais claro entre as operações em tempo real da TI e as atividades empresariais4.

5 Conclusão Antes mesmo de iniciar uma documentação dos processos em uma

empresa é fundamental analisar os tipos de ferramentas que será adotada para fazer as modelagens de negócio. Analisar caso a caso todas as ferramentas e verificar se estas ferramentas adotam ou não padrões abertos, ou seja, open source, visto que estes padrões ainda estão em evolução ou não existem uma opção para migração4.

Por isso a escolha da ferramenta adequada e inevitável senão todos os investimentos que foram feito não sairão do papel por que está é apenas uma

33

etapa de um conjunto maior que permitir o acompanhamento e o realinhamento contínuo4.

6 Definição de Processo Um processo por sua vez, para atingir um objetivo, utiliza o tratamento da informação definida nos requisitos, em uma determinada seqüência. Note que a organização de um processo pode mudar com uma freqüência muito maior do que o tratamento da informação definido em cada requisito e isso ocasiona dois problemas:

· A possibilidade de se considerar um processo ou parte de um processo como requisito de sistema e programá-lo de maneira que ele não possa ser alterado.

· A possível flexibilização e permitir alteração em um requisito do sistema que não deveria contemplar mudanças.

7 Estudo de Caso

O trabalho foi realizado no período de uma semana tendo como via de atendimento, telefone fixo, celular, e-mail e atendimento in-loco. Durante o período das 8 às 18 horas foram realizadas várias solicitações de clientes do setor tributário como segue abaixo:

Período Assunto da Solicitação Meio de comunicação 1º dia Solicitação quanto ao

cadastramento de um contribuinte via sistema Web. Solicitação quanto a um problema de emissão de documento. Solicitação quanto a um agendamento técnico in-loco Solicitação quanto à forma de cadastramento de valores de moedas no sistema. Solicitação quanto à liberação de permissões de usuários. Desloquei um chamado para atendimento in-loco

Telefone

2º dia Solicitação quanto à utilização de cadastramento de contribuinte global no Sistema. Solicitação quanto a um

Celular Telefone

34

procedimento de estorno que o sistema não estaria realizando corretamente.

3º dia Solicitação para atualização de um sistema web. Solicitação para correção de datas de vencimento importadas por engano via banco de dados. Desloquei um Técnico para atendimento in-loco

Atendimento in-loco

4º dia Solicitação para correção de um arquivo vindo de uma instituição financeira para realização de baixa de parcelas pagas.

E-mail

5º dia Solicitação quanto à configuração de um leitor de códigos de barras. Solicitação quanto a problemas no setor de dívida ativa que não estavam gerando os relatórios corretamente. Desloquei um técnico para atendimento in-loco

Atendimento in-loco

Estes atendimentos tiveram um grau de urgência que variou entre

altíssimo e alto com um maior fluxo no período da manhã. Posso destacar que os atendimentos in-loco poderia ter sido resolvido por um atendimento remoto, mas que devido problema internos não foi possível realizar.

Quanto a erros de sistema neste período não ocorreu nenhum chamado.

35

8 Modelagem do estudo de caso

9 Conclusões e trabalhos futuros

Neste trabalho procurei apresentar diferentes visões em um projeto BPM onde além das desvantagens apresentei vantagens na implantação. Hoje se uma empresa não conhece seus processos de negócio dificilmente a empresa terá sucesso.

Outro tema comentado foi organizações centradas na visão vertical x

horizontal. Com isso todos trabalham voltados para um objetivo final que se refere ao produto do processo.

Falamos da importância do recursos humanos no sistema de gestão de

negócio onde mesmo com todo recursos tecnológicos tudo vai depender da eficiência ou a eficácia para obter o sucesso ou fracasso.

Apesar do grande crescimento na área de TI procuramos falar um pouco

das ferramentas e seus possíveis problemas. Finalizando sugiro que este trabalho poderá ser usado como projeto na

implantação de processo de negócio em qualquer empresa e para isso deverá seguir todos as regras aplicáveis em BPM.

36

Referência Bibliográfica

1. Amaral V.; Viero. D: BPM e SOA: um é bem, dois é muito melhor. In: Portal BPM. Nov/Dez 3ª Edição BPM 2007.

2. Mc Goveran D.: na Introduciton to BPM e BPMS. Disponível: www.bijonline.com – Acesso em Julho 2008.

3. Veríssimo R.; BPM requer Risk Management In: Portal BPM 3ª Edição. Ed: BPM. Nov/Dez. 2007

4. Baldan, Roquemar: Gerencimento de Processos de Negócio. 1ª Edição. Ed. Érica. São Paulo 2007.

5. Dutra, Antônio.: Metodologia de BPM e suas influências no desenvolvimento In: Portal BPM. Ed nº 2. Edição nº 1 2007.

6. Dutra. A.: Principais problemas nas implementações. In Portal PM. Edição nº 1. Editora BPM.

7. Pereira. H.: Inovação baseada em processo (process driven innovation). In.: Portal BPM, nº 3, ano1, Ed. BPM, Nov/Dez 2007.

8. Cunha. J. C.: A projeção de BPM nas organizações: uma nova forma de gerir negócios. In: Portal BPM. nº 3 ano 1º Ed. BPM. 2007.

9. Maria José: Abordagem sistêmica e gestão por processos. In: Portal BPM. Edição nº 2 ano 1º Editora BPM. 2007.

10. Barcelos T.; André. G.: Desafios ao desenvolvimento e à implantação de sistemas de BPM. In: Portal BPM nº 2. Ed. BPM. 2007.

11. Souza,L,F.: Monitoramento de processos, quem não precisa disto? In: Portal BPM, Edição nº 4 ano 1º Editora BPM 2008.

12. Reis, G.: Modelagem de Processos de negóciso com BPMN – Curso Completo. São Paulo. Editora Portal BPM Ltda. 2008.

13. Veríssimo, R.: UML x BPM – Modelar sistemas e mapear processos de negócios são a mesma coisa? In: Portal BPM, Edição nº 4, Ed. BPM. 2008.

14. Pereira, H.: O “Lado B” de BPM: não deixe a estratégia atrapalhar a gestão por processo. In: Portal BPM. Edição nº 2 Ed. BPM. 2008.