ALEXANDRE ROVERE CALVO

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

Londrina
2008
 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

2
 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

3
2008

Mensagem

"O futuro dependerá daquilo

que fazemos no presente."
Ghandi

4
 DEDICATÓRIA

A Deus, minha luz, à minha

esposa Juliana por todo apoio e
ajuda e aos meus pais Elizeu e
Edir............

5
 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.

6
 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.

7
 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

8
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

9
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.

10
 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

11
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,

12
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.

13
 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.

14
 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.

15
 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

16
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 é

17
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.

18
 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

19
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)

20
 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

21
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

22
 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.

23
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

24
 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

25
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.

26
 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

27
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.

28
 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.

29
 · 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.

30
 · 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.

31
 · 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

32
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 Telefone
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
2º dia Solicitação quanto à Celular
utilização de Telefone
cadastramento de
contribuinte global no
Sistema.
Solicitação quanto a um

33
 procedimento de estorno
que o sistema não
estaria realizando
corretamente.
3º dia Solicitação para Atendimento in-loco
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
4º dia Solicitação para E-mail
correção de um arquivo
vindo de uma instituição
financeira para
realização de baixa de
parcelas pagas.

5º dia Solicitação quanto à Atendimento in-loco

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

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.

34
 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.

35
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.

36