RAFAEL DE TOLEDO RIBAS

MODELAGEM DE PROCESSOS, DEFINIO DE REQUISITOS E

PLANEJAMENTO DA IMPLANTAO DE UM SISTEMA DE BPM EM
EMPRESA TXTIL

Trabalho de Formatura apresentado

Escola Politcnica da Universidade de
So Paulo para a obteno do Diploma de
Engenheiro de Produo.

SO PAULO
2007

RAFAEL DE TOLEDO RIBAS

MODELAGEM DE PROCESSOS, DEFINIO DE REQUISITOS E

PLANEJAMENTO DA IMPLANTAO DE UM SISTEMA DE BPM EM
EMPRESA TXTIL

Trabalho de Formatura apresentado

Escola Politcnica da Universidade de
So Paulo para a obteno do Diploma de
Engenheiro de Produo.
rea de Concentrao:
Engenharia de Produo
Orientador: Prof. Doutor
Mauro de Mesquita Spnola

SO PAULO
2007

FICHA CATALOGRFICA

Ribas, Rafael de Toledo

Modelagem de processos, definio de requisitos e planejamento da implantao de um sistema de BPM em empresa txtil
/ R.T. Ribas. -- So Paulo, 2007.
p.
Trabalho de Formatura - Escola Politcnica da Universidade
de So Paulo. Departamento de Engenharia de Produo.
1.Tecnologia da informao 2.Integrao de tecnologias
I.Universidade de So Paulo. Escola Politcnica. Departamento
de Engenharia de Produo II.t.

DEDICATRIA

Dedico este trabalho a meus pais,

que me deram todo o apoio de que precisei.

AGRADECIMENTOS

Ao professor Mauro, cuja orientao extremamente dedicada permitiu que este

trabalho adquirisse sua riqueza final.

Aos meus amigos, pelos momentos de descontrao, pela fora, e pelo nimo para
continuar este projeto.

minha famlia, pelo apoio incondicional e pela pacincia, mesmo nos dias de mauhumor e problemas.

E a todos que colaboraram direta ou indiretamente na execuo deste trabalho.

RESUMO

Este trabalho trata da implantao de sistemas de BPM em organizaes que

adotam a Gesto por Processos. Relata e discute um estudo realizado em uma
empresa de porte mdio do setor txtil, cuja alta gerncia determinou a transio de
uma estrutura de gesto fortemente funcional para uma estrutura por processos.
Desta transio surgiu a necessidade de um sistema de suporte para gerenciamento
de processos o BPMS. Este trabalho compreende trs atividades necessrias
adoo deste sistema: a seleo e modelagem dos processos gerenciados, o
estabelecimento dos requisitos do software a ser adquirido, e a criao de um plano
de implantao para o mesmo. O resultado um panorama detalhado dos aspectos
a serem considerados na implantao dos BPMS. Alm da aplicabilidade prtica
para a empresa em questo, o presente estudo elucida o potencial desta ferramenta
de surgimento recente na transformao organizacional, propondo ainda meios
concretos de explorar este potencial.

Palavras-chave: BPMS, Gesto por Processos, Modelagem de Processos,

Definio de Requisitos, Implantao, TI

ABSTRACT

This paper deals with the implementation of BPM systems in organizations adopting
Business Process Management techniques. It reports and discusses a study
conducted in a medium-sized company of the textile industry, whose top
management settled the shift from a strongly function-oriented management structure
to a process-oriented one. This created demand for a system to support the
management of business processes the BPMS. This paper includes three activities
necessary for this systems adoption: process selection and modeling, software
requirements definition, and creation of an implementation plan. The result is a
detailed view of the aspects to be considered in a BPMS implementation. Besides its
practical applicability for the company, this study unveils the whole potential of this
recently released tool to transform organizations, proposing also concrete means to
explore this potential.

Keywords: BPMS, Business Process Management, Process Modeling, Requirements

Definition, Implementation, IT

LISTA DE ILUSTRAES
Figura 1: Exemplo de produtos da marca A..................................................................... 21
Figura 2: Principais mdulos de um sistema ERP .......................................................... 29
Figura 3: Modelo de ciclo de vida de sistemas ERP ....................................................... 34
Figura 4: Estrutura funcional comparada estrutura por processos. .......................... 42
Figura 5: Uma estrutura de Gesto por Processos (BPM). ........................................... 44
Figura 6: Exemplo de interface de modelagem grfica de processos de um BPMS. 56
Figura 7: Exemplo de caixa de entrada de usurio de um BPMS, com suas tarefas,
gerenciador de documentos e ferramentas colaborativas. ....................... 57
Figura 8: Relatrios de monitoramento do desempenho de processos. ..................... 59
Figura 9: Estrutura do BPMS da Appian Solutions, segundo o prprio fornecedor... 60
Figura 10: Papel da BPMN na modelagem e execuo de processos em um
ambiente de negcios. .................................................................................... 64
Figura 11: Diagrama de risco da fase de seleo do BPMS.......................................106
Figura 12: Diagrama do risco de dificuldades de integrao, relativo fase de
implantao.....................................................................................................108
Figura 13: Diagrama do risco de enfrentamento de resistncias internas, relativo
fase de implantao.......................................................................................109
Figura 14: Diagrama de risco de perda do apoio da alta gerncia, relativo fase de
utilizao..........................................................................................................111
Figura 15: Diagrama de risco de utilizao inadequada pelo usurio final, relativo a
fase de utilizao............................................................................................112

LISTA DE TABELAS
Tabela 1: Benefcios e problemas dos sistemas ERP ....................................................30
Tabela 2: Vantagens e desvantagens de uma organizao hierrquica (vertical). ...40
Tabela 3: Categorias de impacto do uso da TI para a Gesto por Processos. ..........47
Tabela 4: Critrios e pesos utilizados na escolha dos processos para modelagem. 68
Tabela 5: Matriz de deciso para escolha de processo de complexidade baixa. ......69
Tabela 6: Matriz de deciso para escolha de dois processos de complexidade mdia.
.............................................................................................................................70
Tabela 7: Matriz de deciso para escolha de dois processos de complexidade alta.71
Tabela 8: Descrio sucinta dos processos escolhidos. ................................................72
Tabela 9: Requisitos de desempenho do sistema ...........................................................93
Tabela 10: Requisitos de funcionalidade do sistema ......................................................93
Tabela 11: Requisitos de confiabilidade do sistema .......................................................94
Tabela 12: Requisitos de usabilidade do sistema............................................................95
Tabela 13: Requisitos de manutenibilidade do sistema..................................................96
Tabela 14: Requisitos de portabilidade do sistema .........................................................97
Tabela 15: Etapas referentes ao processo de deciso.................................................104
Tabela 16: Etapas referentes seleo da ferramenta ................................................104
Tabela 17: Etapas referentes implantao ..................................................................106
Tabela 18: Etapas referentes Utilizao ......................................................................109

LISTA DE ABREVIATURAS E SIGLAS

BI

Business Intelligence

BP

Business Process

BPEL

Business Process Execution Language

BPM

Business Process Management

BPML

Business Process Modeling Language

BPMN

Business Process Modeling Notation

BPMS

Business Process Management System

BPR

Business Process Reengineering

CAD

Computer-Aided Design

CCA

Collaborative Commerce Arrangements

CEO

Chief Executive Officer

CMMI

Capability Maturity Model Integration

COTS

Comercial Of-the-shelf Product

CRM

Customer Relationship Management

EAI

Enterprise Application Integration

ECM

Enterprise Content Management

EDMS

Engineering Document Management Systems

ERP

Enterprise Resource Planning

EVP

Executive Vice President

FQ

Filosofia da Qualidade

GED

Gesto Eletrnica de Documentos

MRP

Material Requirement Planning

NF

Nota Fiscal

O&M

Organizao e Mtodos

OP

Ordem de Produo

OMG

Object Management Group

PPCP

Planejamento, Programao e Controle da Produo

PTE

Potencializao e Trabalho em Equipe

Q&P

Qualidade e Produtividade

RH

Recursos Humanos

SAM

Supplier Agreement Managament

SOA

Service Oriented Architecture

SOX

Sarbanes-Oxley

TI

Tecnologia de Informao

TQM

Total Quality Management

WfMC

Workflow Management Coalition

WMS

Warehouse Management System

XML

Extended Markup Language

SUMRIO
I

INTRODUO .......................................................................................................... 15
I.1

PROBLEMA ........................................................................................................... 15

I.2

CONTEXTO DA EMPRESA................................................................................ 17

I.3

JUSTIFICATIVA .................................................................................................... 21

I.4

ESTRUTURA DO TRABALHO E METODOLOGIA ........................................ 22

II

FUNDAMENTAO TERICA ............................................................................. 25

II.1

SISTEMAS ERP .................................................................................................... 25

II.1.1

Introduo ...................................................................................................... 25

II.1.2

Caractersticas dos sistemas ERP ............................................................. 26

II.1.3

Benefcios e dificuldades associadas aos sistemas ERP ...................... 29

II.1.4

Ciclo de vida de sistemas ERP ................................................................... 33

II.2

GESTO POR PROCESSOS E TI.................................................................... 36

II.2.1

Introduo ...................................................................................................... 36

II.2.2

Gesto por processos: definio ................................................................ 39

II.2.3

Importncia da TI na Gesto por Processos ............................................ 46

II.3

SISTEMAS DE BPM (BPMS).............................................................................. 51

II.3.1

Introduo ...................................................................................................... 51

II.3.2

Definio do BPMS....................................................................................... 52

II.3.3

Caractersticas fundamentais de um sistema de BPM........................... 54

II.3.4

Tendncias futuras ....................................................................................... 61

II.3.5

BPMN.............................................................................................................. 63

II.4

REQUISITOS DE SOFTWARE .......................................................................... 64

II.4.1

Definio de Requisito ................................................................................. 64

II.4.2

Requisitos funcionais.................................................................................... 65

II.4.3

Requisitos no funcionais............................................................................ 66

III

PROPOSTA............................................................................................................... 67
III.1

MODELAGEM DE PROCESSOS DE NEGCIO ............................................ 67

III.1.1

Seleo dos processos para modelagem .................................................67

III.1.2

Modelagem dos processos..........................................................................72

III.2

IV

REQUISITOS DO SOFTWARE BPMS..............................................................84

III.2.1

Requisitos funcionais....................................................................................84

III.2.2

Requisitos no-funcionais............................................................................92

III.2.3

Requisitos contratuais ..................................................................................98

III.3

PLANO DE IMPLANTAO..............................................................................102

III.4

RESUMO DOS RESULTADOS ........................................................................113

CONCLUSO..........................................................................................................115

REFERNCIAS BIBLIOGRAFICAS ...............................................................................118

APNDICE A DESCRIO DA NOTAO UTILIZADA PARA MODELAGEM DE
PROCESSOS ..........................................................................................................121

15

INTRODUO

Este captulo consiste na introduo do estudo realizado, incluindo a definio do

problema abordado, do contexto onde o trabalho foi desenvolvido, de sua estrutura e
da metodologia empregada. A introduo inclui ainda a justificativa para a escolha
do tema do estudo.

I.1

PROBLEMA

O trabalho tem como foco a soluo do seguinte problema:

Modelagem de processos, critrios de seleo e planejamento da implantao de
uma ferramenta BPMS em empresa txtil.

O trabalho foi desenvolvido a partir do estgio realizado no Departamento de

Projetos da empresa. As atividades do estagirio deste departamento envolvem
mapeamento, estruturao e anlise estratgica de processos. Outras atribuies
so a elaborao, execuo e gesto de projetos de melhoria. O Departamento de
Projetos atua como uma consultoria interna, com total autonomia para executar os
projetos identificados como necessrios.

Desta forma, a soluo proposta neste estudo foi inteiramente desenvolvida pelo
autor deste trabalho, como estagirio do departamento, contando com informaes
disponibilizadas por outras reas e colaboraes do Departamento de TI. O projeto
foi liderado e executado pelo estagirio. Os resultados obtidos foram submetidos
validao por parte do gerente de projetos e do diretor do Departamento de TI. O
projeto de implantao da ferramenta, entretanto, originou-se de proposta do
Departamento de TI em conjunto com a Alta Gerncia.

A organizao onde o trabalho foi desenvolvido uma empresa de porte mdio, do

ramo de varejo txtil, que pretende implantar um sistema de BPM (Business Process
Management Gesto de Processos de Negcio) em mdio prazo, assim que
estiver concluda a atual implantao do sistema ERP (Enterprise Resource
Planning) em sua estrutura organizacional. O objetivo principal da aplicao desta
ferramenta reestruturar as operaes da empresa para uma Gesto por

16
Processos, de modo a aumentar a produtividade e eficincia dos mesmos, alm de
eliminar problemas associados departamentalizao excessiva inerente ao atual
modelo de gesto.

O BPMS uma ferramenta de TI que permite empresa modelar, simular, monitorar

e integrar seus processos de negcio. A implantao deste sistema tem seu sucesso
condicionado a uma srie de fatores: fatores organizacionais, de gesto, treinamento
de usurios, escolha da ferramenta, mapeamento dos processos, implantao
gradual ou completa, etc. Os processos de negcio de uma empresa podem
apresentar bastante variabilidade entre si, e alguns processos podem ser mais
propensos integrao pelo BPMS do que outros. De maneira anloga, existem
diversos fornecedores que oferecem diferentes pacotes comerciais de sistemas de
BPM, cada um com suas especificidades.

Assim, este trabalho possui trs partes. O primeiro objetivo selecionar e mapear
detalhadamente um grupo de processos de negcio da empresa, j utilizando a
linguagem padro dos pacotes comerciais disponveis (BPMN Business Process
Modeling Notation). Este mapeamento serve como base para a implantao por
fases do BPMS, que consiste em contemplar um nmero reduzido de processos em
um momento inicial e, se o resultado for satisfatrio, expandir o uso para os demais
processos.

O segundo objetivo determinar quais as caractersticas requeridas para o software,

com a finalidade de orientar a empresa na fase de seleo do fornecedor da
ferramenta. Estas caractersticas foram agrupadas em trs quesitos: requisitos
funcionais, no-funcionais, e contratuais (condies relativas ao processo de
aquisio).

Por fim, a partir destas anlises elaborado um plano a ser seguido por ocasio da
implantao, descrevendo todas as etapas a serem concludas para o sucesso da
adoo do BPM, bem como os riscos a serem considerados.

17
Portanto, o problema em questo consiste em modelar um grupo de processos,
estabelecer requisitos para a seleo do fornecedor, e definir um plano de
implantao de um sistema BPMS para a empresa em questo.

I.2

CONTEXTO DA EMPRESA

A organizao onde este trabalho se desenvolveu uma empresa nacional de

varejo txtil fundada no final da dcada de 80 a partir da criao de uma marca
prpria (Marca C). Foi solicitado sigilo com relao aos nomes das marcas e da
empresa. Atualmente a empresa conta com outras duas marcas de roupas: marca A
e marca B. A marca C corresponde ao grosso do faturamento da organizao,
apresentando uma linha completa de roupas tanto para o pblico feminino como
para o masculino. O pblico alvo bastante diversificado: mercado nacional, faixa
etria entre 15 e 40 anos, classes sociais de A a D. J a marca A atende somente
ao pblico feminino entre 20 a 40 anos pertencente a classe A, estando voltada
principalmente para o mercado da alta costura no exterior. Por fim, a marca B, de
surgimento recente, posiciona-se entre as duas marcas, tendo como publico alvo as
classes A e B, feminino e masculino, faixa etria de 20 a 40 anos.

A empresa possui mais de 1500 funcionrios, estando pouco mais de 300 dedicados
exclusivamente marca de luxo (Marca A). A marca C comercializada no Brasil
atravs de aproximadamente 100 lojas (prprias e franquias), alm de estar
presente em mais de 200 lojas multimarcas. A marca A possui pontos de venda
espalhados pelo mundo, incluindo pases europeus , Estados Unidos e sia, e
algumas lojas prprias no Brasil. A marca B comercializada no Brasil e no exterior
predominantemente em lojas multimarcas.

A fbrica da empresa localiza -se na regio metropolitana de So Paulo, e a maior

parte da produo dedicada marca de luxo. No mesmo local encontra-se o
escritrio da empresa, responsvel pelas trs marcas. A produo das linhas B e C
quase totalmente terceirizada.

18
Na fbrica tambm ficam estocados os produtos acabados e a matria prima
utilizada na confeco das peas. A fbrica funciona como centro de distribuio,
recebendo toda a produo feita por terceiros, armazenando as peas e
direcionando-as para as lojas em todo pas.

A empresa sofreu uma rpida expanso nos ltimos anos, apoiada em aumento
contnuo das vendas e nmero de lojas exclusivas (prprias ou franqueadas), e na
criao da marca B, focando um novo nicho de mercado. Esta expanso no foi
acompanhada de um planejamento eficaz de reestruturao administrativa, de modo
que atualmente a empresa sofre com falta de organizao e processos pouco
eficientes. Em especial, a falta de uma orientao por processos faz com que os
diferentes

departamentos

comuniquem-se

pouco

entre

si,

limitando-se

desempenhar suas funes especficas sem muita ateno ao resultado global

obtido pela integrao das funes das reas de negcio.

Neste contexto, a TI apresenta um enorme potencial para revolucionar o

funcionamento da empresa. O Departamento de TI, cuja direo foi trocada
recentemente, est ciente disto, e tem lanado mo de ferramentas de ltima
gerao para solucionar problemas como a falta de integrao entre os
departamentos. A substituio de sistemas e bancos de dados obsoletos est entre
as prioridades da rea.

Desta forma, um dos problemas a serem atacados o excessivo nmero de

sistemas legados, cuja existncia esta associada justamente excessiva
departamentalizao previamente mencionada. Existem sistemas especficos para
as reas Fiscal, Comercial, Financeiro. Existe uma srie de sistemas associados ao
PCP (Programao e Controle da Produo), alguns deles restritos a uma das trs
marcas da empresa. Os sistemas utilizam arquiteturas diferentes (Adabas, MySQL,
Java, etc.) e so pouco ou nada integrados uns aos outros.

O Departamento de Projetos da empresa, onde se desenvolveu este trabalho, tem

como uma de suas funes auxiliar na anlise de viabilidade da adoo de novos
sistemas de informao, e na impla ntao propriamente dita. Os estagirios da rea
contam com bastante autonomia no desenvolvimento dos projetos, e carga de

19
responsabilidade correspondentemente alta. Os projetos de TI em andamento que
contam com a participao do Departamento de Projetos envolvem ferramentas de
BI (Business Inteligence), GED (Gerenciamento Eletrnico de Documentos), BPMS
(Business Process Management System), ERP (Enterprise Resource Management),
e WMS (Warehouse Management System).

O projeto de implantao do ERP na empresa sem dvida o mais importante e

ambicioso. Durante o primeiro semestre de 2007 foram contratados consultores para
mapear e documentar os processos da empresa. A partir destes dados, trs
fornecedores pr-selecionados apresentaram suas solues de ERP para os
funcionrios, e foi feita uma avaliao de aderncia dos pacotes comerciais
oferecidos s necessidades da empresa. Em Agosto foi concluda a etapa de
seleo do fornecedor e teve incio a implantao, que deve durar aproximadamente
um ano. Com o sistema em uso, espera-se que boa parte dos sistemas legados
atuais possa deixar de ser utilizado. Outros benefcios esperados so maior
qualidade de informao gerencial, reengenharia de diversos processos segundo as
best practices do setor, reduo da mo de obra relacionada a processos de
integrao de dados, padronizao de procedimentos, acesso informao para
toda a empresa, entre outros. O projeto do ERP desenvolvido fundamentalmente
pelo Departamento de TI, com apoio do Departamento de Projetos, e colaborao
de todas as reas.

O projeto de implantao do BPMS, foco deste trabalho, tambm consta entre as

prioridades da rea de TI. Todas as etapas pr-implantao, exceto pela definio
do escopo e seleo final do fornecedor, contam com participao direta do autor
deste trabalho, em conjunto com outros membros dos Departamentos de Projetos e
TI. A princpio, cogitou-se a implantao em carter provisrio de um sistema de
Workflow, mais limitado do que o BPMS, devido urgncia de uma soluo de
integrao de alguns processos crticos para a empresa. Tal proposta foi
inviabilizada principalmente pela dificuldade de integrao dos vrios sistemas
legados ao mecanismo do Workflow. Alm disso, concluiu-se que os benefcios da
ferramenta BPMS, bem mais completa e com potencial muito maior para modificar a
maneira como a empresa gerencia suas atividades, compensa o investimento inicial
mais elevado. A implantao do sistema, porm, ser realizada aps a concluso do

20
projeto do ERP, visto que, de acordo com o Diretor da rea de TI, sem o ERP a
organizao no estaria apta a promover a mudana para a Gesto por Processos e
adoo do BPMS. Portanto, o sucesso do processo atual de adoo do ERP
crtico para a implantao bem sucedida do BPMS.

A adoo do BPMS faz parte da estratgia de aumento da produtividade e eficincia

da organizao atravs da Gesto por Processos (BPM). O conceito de BPM ser
descrito em detalhes mais frente, mas pode-se dizer que ele difere de abordagens
tradicionais associados Gesto por Processos, como a Reengenharia, na medida
em que no prope a mudana radical e sbita de modelo de gesto, e sim a
adoo gradual atravs de controle e melhoramento contnuo dos processos.

O objetivo deste trabalho, conforme previamente mencionado, modelar um grupo

inicial de processos de negcio, estabelecer os requisitos para a seleo do
software, e definir um plano de implantao passo a passo para a ferramenta. Este
plano ser utilizado no segundo semestre de 2008, desde que a implantao do
ERP ocorra dentro do tempo planejado. Alguns contatos iniciais j foram feitos com
fornecedores de sistemas BPM (IBM, Bizage), porm apenas em carter de
sondagem.

Por fim, deve-se ressaltar que os projetos acima mencionados contam com total
apoio da alta gerncia. Sem este apoio explcito no seria possvel empregar
ferramentas modernas de TI na empresa, dada a grande resistncia inicial dos
funcionrios a todo tipo de mudana. Espera-se, porm, que os funcionrios
entendam a relevncia dos projetos, participem, e terminem por encarar a mudana
como benfica. Espera-se tambm que os gerentes e demais cargos de gesto
aproveitem plenamente o potencial das ferramentas que tero em mos. Os
sistemas por si s so apenas parte da soluo, dependendo da utilizao correta e
eficiente por parte do cliente final para produzir os resultados desejados.

21

Figura 1: Exemplo de produtos da marca A.

I.3

JUSTIFICATIVA

O tema em questo foi selecionado em conjunto com a empresa e o Departamento

de Projetos, onde o estgio foi desenvolvido, e submetido avaliao do orientador,
prof. Mauro Spnola, que colaborou para aperfeio-lo.

O Departamento de TI da empresa sofreu uma reformulao completa nos ltimos

meses e o novo diretor trouxe uma srie de projetos para modernizar e melhorar o
desempenho dos sistemas de informao utilizados na empresa. Dois destes
projetos, conforme previamente citado, so a implantao do ERP e do BPMS.
Neste contexto, a funo do Departamento de Projetos dar amplo suporte ao
planejamento e realizao destes empreendimentos. A implantao do BPMS
despertou especial interesse por ser uma ferramenta com enorme potencial para
melhorar o desempenho de uma empresa em franca expanso num setor bastante
competitivo da indstria nacional.

Naturalmente a ferramenta de ERP tambm extremamente importante para o

processo de reestruturao em curso, mas a aquisio do software j havia
comeado antes do incio do estgio e a implantao s deve ser concluda em
2008.

22

No caso do sistema de BPM, existe a oportunidade de participao ativa desde o

incio do projeto. Inicialmente, este trabalho teria como foco a implantao
propriamente dita, sendo baseado numa anlise de desempenho de processos
antes e depois da utilizao do BPM. Entretanto, a adoo do sistema de BPM pela
empresa foi adiada para o segundo semestre de 2008, ou seja, aps a concluso da
implantao do ERP. Como resultado, o tema do trabalho foi modificado para o
planejamento da implantao do BPMS.

Do ponto de vista acadmico, o tema envolve uma ferramenta de TI moderna e cujo

uso tem se difundido de maneira acelerada no mercado nacional e internacional.
Este trabalho procura estabelecer relaes entre a estrutura de gesto e a estrutura
de TI da organizao, visto que o BPMS uma ferramenta de suporte a aplicao
de um conceito de gesto chamado BPM (Gesto de Processos de Negcio). Podese dizer ainda que o tema permite o exerccio da capacidade de planejamento e
estabelecimento de critrios para tomada de deciso, fundamental para qualquer
engenheiro para uma abordagem bem sucedida de seus projetos.

O tema requer capacidade de pesquisa e aplicao prtica de conceitos tericos,

sendo especialmente desafiador devido atualidade dos conceitos envolvidos e ao
pouco tempo de divulgao de material a respeito dos mesmos. Os artigos
assumem, assim, papel crucial no levantamento da fundamentao terica.

Concluindo, o tema bastante relevante tanto do ponto de vista acadmico como

profissional, e permite o desenvolvimento de um trabalho ao mesmo tempo rico em
informao e de bastante aplicabilidade prtica.

I.4

ESTRUTURA DO TRABALHO E METODOLOGIA

O primeiro passo no desenvolvimento deste trabalho a definio precisa do

problema a ser atacado. Embora aparentemente simples, esta etapa crucial para o
bom andamento do projeto: se o tema no estiver claro, o trabalho fica vago e

23
confuso, e o objetivo final no atingido. No caso deste trabalho, a definio do
problema evoluiu de uma concepo inicial pouco definida, associada principalmente
questo dos impactos do uso do BPMS, para um foco mais definido de planejar,
modelar e identificar requisitos da ferramenta. A deciso a respeito do tema contou
com a colaborao da rea de TI da empresa e do orientador deste trabalho.

A definio do problema d base para a definio dos objetivos que se pretende

alcanar por meio deste projeto. Com o tema definido, elaborada a estrutura do
trabalho, prevendo os captulos nos quais este se dividir, bem como os respectivos
contedos. Esta estrutura serve como base para a construo de um cronograma de
trabalho utilizado para avaliar o progresso do mesmo em relao aos prazos
propostos.

A etapa seguinte o detalhamento e a anlise do contexto no qual este trabalho

est inserido. Consiste basicamente no levantamento de informaes junto
empresa envolvida, incluindo suas expectativas e objetivos relativos aplicao do
BPMS, e relativos a este trabalho.

O terceiro passo a fundamentao terica do trabalho. Ela consiste numa reviso

bibliogrfica dos principais conceitos envolvidos no projeto, que serve como base
terica para a elaborao das demais etapas. O material para pesquisa utilizado
consiste de livros, artigos pub licados em peridicos acadmicos e na internet, e
trabalhos acadmicos (mestrado, doutorado, graduao). Os quatro principais
tpicos de pesquisa so: sistemas ERP, Gesto por Processos e TI, BPMS, e
Requisitos de software. A bibliografia utilizada est listada no final do trabalho, no
captulo Referencias Bibliogrficas, para eventual consulta pelo leitor deste trabalho.

A partir do referencial terico foi executado o passo seguinte: o desenvolvimento da

soluo proposta. Esta est fragmentada em trs ite ns principais: modelagem dos
processos, definio dos requisitos do software, e plano de implantao.

24
A definio das caractersticas dos processos foi feita da seguinte forma:
inicialmente, foi estabelecido o nmero de processos participantes da primeira fase
de implantao; em seguida, foram selecionados os processos, com graus de
complexidade variveis; por fim, os processos foram modelados com apoio do
software MS Visio, j na linguagem padro de BPM (BPMN).

A definio dos requisitos da ferramenta foi feita da seguinte forma: inicialmente,

foram listadas no capitulo Referencial Terico as principais caractersticas e
funcionalidades das solues de BPM existentes no mercado. Um possvel
fornecedor realizou uma apresentao do sistema, exemplificando as ferramentas
do mesmo e sua utilidade para a organizao. Com base nestas informaes foram
definidos, junto rea de TI, os requisitos funcionais e no funcionais do software,
bem como os requisitos contratuais de aquisio.

Tendo em mos os processos mapeados e os requisitos para escolha da

ferramenta, foi desenvolvido o plano de implantao do BPMS. Foram levantadas
todas as etapas envolvidas na implantao deste tipo de sistema, a partir da
fundamentao terica e da experincia dos profissionais da rea de TI que j
participaram de tal processo. Foram propostos procedimentos a serem seguidos
nestas etapas, considerando o contexto da organizao, os resultados deste
trabalho, e os riscos detectados. Por fim, foram estimados tempos de durao para
as etapas e uma seqncia lgica de execuo. O resultado um plano abrangente
de implantao, pronto para uso pela empresa.

Por fim, foi elaborada uma concluso destacando as contribuies do trabalho para
a empresa, para o aluno, e para o estudo do tema. A concluso inclui ainda
sugestes para possveis novos trabalhos com temas relacionados ao abordado
neste estudo.

25

II

FUNDAMENTAO TERICA

Este captulo tem como objetivo fazer uma reviso da literatura a respeito de quatro
tpicos relevantes para o desenvo lvimento deste trabalho: Sistemas ERP, Gesto
por Processos e TI, Requisitos de Software, e BPMS. A compreenso do
funcionamento dos sistemas ERP importante, pois h uma implantao de ERP
em curso na empresa estudada, com impacto direto sobre o projeto do BPMS e
sobre todo o contexto no qual este trabalho est inserido. Diversos aspectos do
planejamento da implantao do BPMS devem levar em conta o resultado (ou
progresso) da adoo do ERP, em especial no que diz respeito a processos que
envolvem sistemas legados variados. Os outros tpicos abordados, Gesto por
Processos e TI, Requisitos de Software e BPMS, conectam-se diretamente ao tema
deste trabalho, provendo os conceitos necessrios para a elaborao e
compreenso do mesmo. As fontes utilizadas foram livros, artigos publicados em
revistas acadmicas, e trabalhos de graduao e ps-graduao.

II.1 SISTEMAS ERP

II.1.1 Introduo
Os sistemas ERP (Enteprise Resource Planing) apresentaram um crescimento
expressivo no mercado de solues corporativas de informtica nos anos 90, devido
s presses competitivas sofridas pelas empresas nesta dcada e necessidade de
coordenar melhor suas atividades dentro da cadeia de valor, visando eliminar
desperdcios de recursos.

Segundo Davenport (1998), toda empresa coleta, gera e armazena uma enorme
quantidade de dados. Na maioria das empresas, entretanto, a informao no
guardada em um nico repositrio, mas sim fica espalhada em dzias ou mesmo
centenas de sistemas computacionais separados, cada um alocado a uma diferente
funo, unidade de negcio, regio, fbrica ou escritrio. Manter estes diferentes
sistemas gera custos imensos para armazenar e racionalizar informao
redundante, para reformatar e transferir informao de um sistema para outro, para
atualizar e resolver problemas em linguagens de software ultrapassadas, para
programar links de comunicao entre os sistemas de modo a automatizar a

26
transferncia de dados. Os custos indiretos so ainda mais impactantes: se a
gerncia no possui compreenso profunda do que acontece em todos os
departamentos relacionados a sua operao, sua deciso ser baseada em instinto,
e no ser racional. Em outras palavras, se os sistemas de uma empresa so
fragmentados, seu negcio fragmentado.

Neste contexto surgiram os sistemas de ERP, explorando a necessidade de rpido

desenvolvimento de sistemas integrados. Contriburam tambm para a expanso do
ERP fatores como a evoluo da tecnologia, o amadurecimento das opes
disponveis no mercado, e casos bem sucedidos de empresas que adotaram o
sistema no incio da dcada de 90.

II.1.2 Caractersticas dos sistemas ERP

Os sistemas ERP consistem em sistemas de informao integrados adquiridos na
forma de pacotes comerciais de software, cuja finalidade dar suporte maioria das
operaes de uma empresa industrial (suprimentos, manufatura, manuteno,
administrao financeira, contabilidade, recursos humanos, etc.). Conforme Beheshti
(2006), o ERP tem suas razes na indstria de manufatura e o sucessor dos
sistemas MRP e MRP II (Material Requirements Planning). O MRP era usado para
organizar o fluxo de informaes ao redor de processos de manufatura; o MRP II j
inclua a parte de recursos, provendo uma viso das implicaes da programao da
produo e do plano de aquisio de materiais; e finalmente o ERP um conjunto
mais completo de aplicaes capazes de conectar todos os processos internos de
uma empresa e at processos interorganizacionais como gesto de relao com
consumidores ou fornecedores. Davenport (1998) define o ERP em seu ncleo
como um nico banco de dados abrangente, que coleta e alimenta aplicaes
modulares com dados, dando apoio praticamente todas as atividades de negcio
da empresa entre funes, entre unidades de negcio, ao redor do mundo.
Quando informao nova adicionada em um lugar, toda informao relacionada
automaticamente atualizada.

27
Corra (1997) afirma que o desenvolvimento desde o MRP at o ERP se deu
fundamentalmente pela adio de mdulos: o MRP passou a ser chamado MRP II
quando deixou de atender apenas as necessidades de informao referentes ao
clculo de necessidade de materiais para atender s necessidades de informao
para tomada de deciso gerencial sobre outros recursos de manufatura. De maneira
anloga, conforme os fornecedores adicionaram mdulos integrados ao MRP II que
suportavam mais e mais funes, transcendendo muito o escopo da manufatura, tais
fornecedores consideraram que suas solues integradas eram suficientemente
capazes de suportar as necessidades de informao para todo o empreendimento. A
estas solues foi dado o nome de ERP (Enterprise Resource Planning).

Teoricamente, empresas poderiam desenvolver internamente sistemas com as

mesmas caractersticas, mas na prtica o termo ERP est associado a pacotes
comerciais. Alguns exemplos de pacotes existentes no mercado: R/3 da alem SAP,
IBaan Enterprise da holandesa Baan, Oracle E-Business Suite da americana Oracle,
Magnus da brasileira Datasul, e o AP7 Master da brasileira Microsiga.

Embora os sistemas ERP tenham-se originado para ate nder basicamente a

empresas industriais, a abrangncia de tais sistemas tem se ampliado, englobando
empresas das reas comercial, distribuio, utilidades, financeira, entre outras.

As seguintes caractersticas permitem distinguir os ERPs de sistemas desenvolvidos

internamente por empresas:

Possuem grande abrangncia funcional;

Requerem procedimentos de ajuste para que possam ser utilizados por

determinada empresa;

So sistemas de informao integrados e utilizam um banco de dados

corporativo;

Incorporam best practices (modelos de processos de negcio);

So pacotes comerciais de software;

28
Os sistemas ERP no so desenvolvidos para um cliente especfico, mas sim
procuram atender a requisitos genricos, de forma a explorar o ganho de escala em
seu desenvolvimento. Para tanto, os sistemas precisam incorporar modelos de
processos de negcio, os quais so obtidos por meio da experincia acumulada
pelas empresas fornecedoras em repetidos processos de implementao, ou por
intermdio de empresas de consultoria e pesquisa em processos de benchmarking.
Esses modelos de processo de negcio so as chamadas best practices, embora
neste caso quem define o que melhor quer dizer o fornecedor.

Quanto questo da integrao, deve-se fazer uma distino entre empresa

integrada e sistema de informaes integrado. Segundo Beheshti (2006), o ERP
uma soluo de gesto, e no um simples projeto de TI, e possui impacto muito
maior na organizao do que mudanas tradicionais no sistema. Ou seja, no se
trata da mera integrao de sistemas informatizados existentes ou que sero
implementados no futuro. Esta apenas uma ferramenta para o desenvolvimento de
uma empresa verdadeiramente integrada.

Deve-se tambm considerar que a implementao do ERP possui certo grau de

incerteza: complicado estimar a economia proporcionada pelo uso do sistema, e
difcil prever com preciso o desenvolvimento do mesmo devido s constantes
mudanas que ocorrem durante o processo. Alm disso, os benefcios intangveis do
ERP so difceis de mens urar em termos monetrios.

Os sistemas ERP so divididos em mdulos, que so conjuntos de funes

destinados a determinados departamentos da empresa. Na Figura 1 esto alguns
dos mdulos mais freqentemente utilizados em empresas industriais:

29
Planejamento
Produo

Fornecedores

Suprimentos

Produo

Vendas

RH

Contabilidade

Faturamento

Contas a pagar

Tesouraria

Contas a receber

Clientes

Figura 2: Principais mdulos de um sistema ERP

(adaptado de Souza e Zwicker (2003))
As interligaes internas entre os mdulos se do de maneira on-line, de acordo
com as especificaes do sistema de ERP. J as interligaes com entidades
externas, no caso, clientes e fornecedores, podem ou no ser realizadas de maneira
eletrnica (em geral ainda no o so), dependendo do interesse e esforo da
empresa e de seus parceiros. Essa interligao externa, englobando os diversos
participantes de uma cadeia de suprimentos, uma das questes mais desafiadoras
e importantes para empresas e seus departamentos de TI. Payne (2002) afirma que
os sistemas ERP parecem estar entrando em uma nova fase, do chamado ERP II,
que pode ser utilizado na integrao com E-business, cadeia de suprimentos, CRM
(Customer

Relationship

Management)

CCAs

(Collaborative

Commerce

Arrangements). Somada a implantao mais simples e novas funcionalidades, esta

capacidade de integrao externa pode dar um novo impulso ao crescimento do uso
de sistemas ERP entre empresas.

II.1.3 Benefcios e dificuldades associadas aos sistemas ERP

Entre os principais benefcios destacados pelas empresas fornecedoras de solues
de ERP esto a integrao, o incremento da possibilidade de controle sobre os

30
processos da empresa, a atualizao tecnolgica, a reduo de custos de
informtica e o acesso a informaes de qualidade em tempo real para a tomada de
decises sobre toda a cadeia produtiva. Entretanto, a adoo do sistema ERP
tambm pode ocasionar no surgimento de problemas. O Quadro 1 relaciona as
dificuldades e benefcios a aspectos destes sistemas:

Tabela 1: Benefcios e problemas dos sistemas ERP

(adaptado de Souza e Zwicker (2003))
Caractersticas

Benefcios

Problemas

- Reduo de custos de

Pacotes comerciais

informtica;

- Dependncia do

- Foco na atividade

fornecedor;

principal da empresa;

- Empresa no detm o

- Atualizao tecnolgica

conhecimento sobre o

permanente, por conta dos

pacote;

fornecedores;
- Necessidade de

Usam modelos de
processos

- Difunde conhecimento

adequao do pacote

sobre best practices;

empresa;

- Facilita a reengenharia

- Necessidade de alterar

de processos;

processos empresariais;

- Impe padres;

- Alimenta a resistncia
mudana;

31
Caractersticas

Benefcios
- Reduo do retrabalho e
inconsistncias;
- Reduo da mo de obra
relacionada a processos
de integrao de dados;
- Maior controle sobre a
operao da empresa;

Sistemas integrados

- Eliminao de interfaces
entre sistemas isolados;
- Melhoria na qualidade de
informao;
- Contribuio para a
gesto integrada;
- Otimizao global dos
processos da empresa;

Problemas
- Mudana cultural da
viso departamental para
a de processos;
- Maior complexidade de
gesto da implantao;
- Maior dificuldade na
atualizao do sistema,
pois exige acordo entre
vrios departamentos;
- Um mdulo no
disponvel pode
interromper o
funcionamento dos
demais;
- Alimenta a resistncia a
mudana;
- Mudana cultural da

- Padronizao de
informaes e conceitos;

viso de dono da
informao para a de
responsvel pela

- Eliminao de

informao;

discrepncias entre
Usam bancos de dados

informaes de diferentes

corporativos

departamentos;

- Mudana cultural para

uma viso de
disseminao de

- Melhoria na qualidade da
informao;
- Acesso a informaes
para toda a empresa;

informaes de
departamentos por toda a
empresa;
- Alimenta a resistncia a
mudana;

32
Caractersticas

Benefcios

Problemas

- Eliminao da
manuteno de mltiplos

Possuem grande

sistemas;

- Dependncia de um

- Padronizao de

nico fornecedor;

procedimentos;

- Se um sistema falhar,

- Reduo de custos de

toda a empresa pode

treinamento;

parar;

abrangncia funcional

- Interao com um nico

fornecedor;

Corra (1997) destaca que a principal motivao de grande nmero de empresas

que decidem adotar o ERP sua capacidade de integrar vrias reas e setores
funcionais da empresa, todas compartilhando a mesma base de dados nica e no
redundante. Por outro lado, a deciso radical de substituio ampla dos sistemas
pelo ERP deve levar em conta alguns aspectos:

Muitas

vezes,

determinados

sistemas

so

superiores

ao

mdulo

correspondente do ERP, pois passaram por anos de evolues e

aperfeioamentos;

s vezes, as interfaces entre sistemas no so to problemticas de

gerenciar quanto imaginamos;

Quanto maior o grau de substituio dos sistemas atuais pelos novos, maior
ser o tempo de implantao do ERP. A empresa deve considerar a
possibilidade de conviver com interfaces, caso opte por uma implantao
mais gradual.

Davenport (1998) relaciona alguns dos perigos associados adoo de sistemas

ERP: a adequao do processo de negcio ao sistema, e no o contrrio, pode
resultar em perda de vantagem competitiva (por exemplo, perda de flexibilidade); o
custo de implantao pode ser muito alto; o fato de todos os concorrentes de
determinado setor utilizarem a mesma soluo de ERP pode minar seu diferencial
competitivo.

33

Nah, Lau e Kuang (2001) apontam alguns fatores crticos de sucesso para a adoo
do ERP por uma empresa:

Equipe de trabalho de ERP eficiente e bem composta;

Apoio da alta gerncia;

Viso e plano de negcios claro;

Comunicao efetiva;

Boa gesto de projeto;

Existncia de um lder (champion) do projeto;

Sistemas legados e de negcio apropriados;

Mudana no programa e cultura de gesto;

Uso do BPR (Business Process Reengineering) e customizao mnima;

Desenvolvimento, teste e soluo de problemas no software;

Monitoramento e avaliao da performance;

II.1.4 Ciclo de vida de sistemas ERP

As diversas etapas pelas quais passa um projeto de desenvolvimento e utilizao de
sistemas de informao consistem em seu ciclo de vida. Os ERPs apresentam
particularidades em seu ciclo de vida devido a sua abrangncia funcional e ao
aspecto da integrao entre seus diversos mdulos. Conforme Souza e Zwicker
(2003), um modelo de ciclo de vida para ERP deve contemplar as etapas de deciso
e seleo, implementao e utilizao, como representado na Figura 2.

34
Novas necessidades, conhecimento acumulado e parmetros j
estabelecidos

Fase n
DECISO E
SELEO

IMPLEMENTAO

Fase 2

Fase n
UTILIZAO

Fase 1
Pacote
selecionado
Plano de
implementao

Fase 2
Fase 1

Mdulos parametrizados,
customizados.
Dados migrados
Usurios treinados

Figura 3: Modelo de ciclo de vida de sistemas ERP

(adaptado de Souza e Zwicker (2003))

Na etapa de deciso a empresa decide implementar um sistema ERP e escolhe o

fornecedor. Fundamental nesta etapa tomar uma deciso baseada na
compatibilidade entre a organizao e as caractersticas dos sistemas ERP
disponveis no mercado.

A escolha do fornecedor, segundo Beheshti (2006), pode ser feita de trs maneiras:
limitar a escolha a um ou dois fornecedores, com seus produtos e servios
(demanda pouco tempo, mas pode no detectar a melhor opo); estudo detalhado
de todos os fornecedores disponveis (demanda tempo e custa caro, mas tem mais
chances de resultar na melhor escolha); estudo superficial geral e limitao a dois
candidatos (meio termo entre as duas maneiras anteriores). Grandes fornecedores,
como SAP e Oracle, oferecem maior quantidade de mdulos, excelente suporte
contnuo e upgrades, mas so mais caros e mais padronizados, necessitando
maiores alteraes nos processos de negcio. Sistemas de fornecedores menores
oferecem mdulos direcionados a setores especficos do mercado, necessitando
desta forma menos mudanas operacionais e reduzindo o custo de implantao
total. Deve -se considerar ainda a terceirizao de mdulos como uma opo: uma
forma de transformar custos fixos em variveis, e repassar custos de manuteno e
upgrade para o fornecedor. A desvantagem da terceirizao a necessidade de boa

35
dose de confiana no prestador de servio (dados confidenciais), e uso de medidas
de segurana avanadas (pois os dados so enviados atravs da internet).

Souza e Zwicker (2003) definem critrios que podem ser utilizados na escolha do
pacote comercial: adequao da funcionalidade do pacote aos requisitos da
empresa (aderncia), arquitetura tcnica do produto, custo de implantao,
qualidade do suporte ps-venda, sade financeira e viso de futuro do fornecedor.

Na etapa de implantao os mdulos do sistema so colocados em funcionamento

na empresa. Esta etapa envolve a adaptao dos processos de negcio ao sistema,
a parametrizao e eventual customizao do sistema, a carga ou converso dos
dados iniciais, a configurao do hardware ou software de suporte, o treinamento de
usurios e gestores e a disponibilizao de suporte e auxlio. Podemos considerar a
etapa de implantao essencialmente como uma etapa de eliminao de
discrepncias at que a operao possa ser iniciada com chances de sucesso.
Essas discrepncias so resolvidas basicamente de quatro maneiras: ou adapta-se
o pacote, ou adaptam-se os processos da organizao, ou adapta-se tanto o pacote
como os processos, ou convive -se com a discrepncia.
No que diz respeito adaptao do sistema ERP aos processos da empresa, esta
pode ser feita atravs de parametrizao ou customizao (desenvolvimento de
programas extras para complemento de funes existentes). O processo especfico
de adaptao de um sistema ERP legislao e s prticas de negcio de
determinado pas conhecido como localizao.

A etapa de implantao est entre as mais crticas, pois envolve mudanas

organizacionais que implicam alteraes nas tarefas e responsabilidades de
indivduos e departamentos, alm de transformaes nas relaes entre os diversos
departamentos. Tais mudanas devem conduzir otimizao localizada de
atividades departamentais e otimizao global dos processos da empresa, e
necessitam de intensa participao e comprometimento da alta direo da empresa.
Alguns dos riscos presentes na etapa de implantao, segundo Huang (2004), so:

36
comunicao ineficaz com o usurio, conflito entre os departamentos dos usurios,
fracasso em conseguir o apoio do usurio, e falta de treinamento do usurio final.

Ainda na etapa implantao, deve-se decidir como ser iniciada a operao do ERP
na empresa: modelo big bang, ou seja, entrada em funcionamento de todos os
mdulos em todas as divises simultaneamente; modelo small bang, ou seja,
entrada em funcionamento de todos os mdulos sucessivamente em cada uma das
fbricas ou divises; ou implantao em fases, com os mdulos sendo implantados
em etapas, em todas ou em cada uma das divises.

Por fim, temos a etapa de utilizao, na qual o sistema passa a fazer parte do dia-adia das operaes. O conhecimento de todas as possibilidades de uso dos sistemas
ERP se estabelece apenas aps certo tempo de uso continuado da tecnologia, o
que resulta na realimentao da etapa de implantao com novas possibilidades e
necessidades, a serem resolvidas por novos mdulos, pela parametrizao ou pela
customizao. Neste caso, e no caso da implantao por fases, deve-se levar em
conta a limitao que os mdulos j implantados exercem sobre os mdulos a serem
implantados, uma vez que a sua configurao j est definida e uma vez que o
mdulo que j se encontra em operao tem sua modificao dificultada.

II.2 GESTO POR PROCESSOS E TI

II.2.1 Introduo
A dcada de 90 presenciou o surgimento de dois conceitos que tiveram grande
impacto sobre as empresas e negcios do mundo inteiro: a Gesto por Processos e
a Nova Economia.

A Nova Economia representa a globalizao da economia, a competio entre

empresas em mbito global. As empresas atualmente esto integradas a um nico
mercado mundial, e fatos que ocorrem em um ponto do planeta podem ter
repercusso no resto do mundo. Nestas organizaes transnacionais, a TI tem papel
fundamental: ela possibilita a existncia de novas estruturas organizacionais, de

37
novas estratgias de negcio, e de novas formas de relacionamento com o cliente e
entre empresas. Alm disso, o avano da TI o fator que viabiliza a integrao em
escala planetria, e, em ltima instncia, a existncia da Nova Economia.

J a Gesto por Processos prope que a seqncia de atividades que agregam

valor empresa passe a ser o foco de sua gesto. A diviso em departamentos
funcionais deixa de ser o critrio principal para analisar a melhor maneira de
desempenhar tais atividades. Isto possibilita grandes ganhos de eficincia e
competitividade, fundamentais num mercado cada vez mais globalizado e disputado.

A idia de buscar a melhor maneira de desempenhar as atividades no uma

novidade, tendo suas origens na Administrao Cientfica do comeo do sculo XX,
passando por tcnicas de O&M (Organizao e Mtodos), e pelo conceito de
melhoria contnua das tcnicas de administrao japonesas, bastante populares
nos anos 80. Entretanto, a origem mais imediata da gesto baseada em processos
a chamada Reengenharia, ou BPR (Business Process Reengineering), surgida na
dcada de 90.

A Reengenharia afirma que as novas prticas de gesto devem responder a trs

foras que atuam sobre a empresa: os clientes, a concorrncia e a mudana. A idia
que a empresa abandone procedimentos consagrados e paradigmas e reestruture
sua forma de trabalhar para criar produtos e servios que proporcionem valor aos
clientes. Trata-se, portanto, de uma mudana radical no funcionamento dos
processos, e no de uma melhoria contnua a partir dos processos pr-existentes.

Hammer e Champy (1994), dois dos criadores do termo, afirmam que

Reengenharia significa repensar e redesenhar radicalmente os processos de
negcio para atingir melhoria dramtica em medidas de performance atuais e
crticas, como custo, qualidade, servio e velocidade.

A discusso acerca da otimizao dos processos organizacionais e sua readaptao

em funo da estratgia da empresa implica freqentemente na necessidade de

38
novas aplicaes de TI. A TI viabiliza a aplicao concreta e bem sucedida da
Gesto por Processos nas empresas, e esta por sua vez pode promover o
alinhamento entre as estratgias de negcio e TI da empresa.

O prprio papel da TI nas organizaes modificou-se drasticamente nas ltimas

dcadas: do simples processamento de dados nos anos 60, para os sistemas de
informao gerenciais dos anos 70, para os atuais sistemas de informao
estratgicos (que procuram mudar a forma como a empresa conduz seu negcio).

O surgimento dos sistemas ERP na dcada de 90 torno u possvel promover a

integrao das informaes e do fluxo de todas as atividades da empresa atravs de
um nico banco de dados. Entretanto, so comuns os casos de implantao malsucedida ou mesmo traumtica de tais sistemas de informao. As principais causas
destes fracassos so tentativas de integrao de funes e atividades que
historicamente sempre foram tratadas separadamente, ou tratamento distinto do
recurso tecnolgico a ser implantado e do processo de mudana organizacional.

Conforme Davenport (1993), os processos de negcio so importantes neste caso

por serem responsveis pela execuo de procedimentos decorrentes da estratgia
corporativa, ou pelo sucesso do modelo de negcios da organizao. Como
possuem natureza basicamente multifuncional, ultrapassando os limites da estrutura
organizacional tradicional, os processos devem ser analisados criteriosamente, para
que as mudanas associadas ao ERP sejam bem sucedidas. Tais mudanas
incluiriam o alinhamento dos conhecimentos gerados pelos diversos departamentos,
relacionando tais conhecimentos as mais variadas funes e sub-processos de
negcio.

Empresas com estrutura funcional departamentalizada, ou seja, que no empregam

a Gesto por Processos, costumam se deparar com problemas como: a eficincia
dos setores individuais no corresponde eficincia do todo; e dificuldade de
desempenhar trabalhos que requerem cooperao de diferentes departamentos.
Implementar sistemas de informao como o ERP em empresas organizadas desta
forma no o mais adequado. Nestes casos, recomenda-se a reviso das

39
atividades em termos de processos-chave, que seriam identificados, analisados e
melhorados antes da aplicao do sistema. Ou seja, a adoo de sistemas de
informao para integrao e da Gesto por Processos est profundamente interrelacionada.

II.2.2 Gesto por Processos: definio

Analisando organizaes estruturadas de maneira tradicional, em unidades
funcionais, observam-se freqentemente as seguintes caractersticas:

A eficincia dos diferentes setores obtida s custas da eficincia da

empresa como um todo;

Fluxos de trabalho complexos, propcios a erros, lentos e compostos por

muitas tarefas dificultam a melhora na qualidade;

Ausncia de responsvel direto por processos, por respeito hierarquia

funcional;

Dificuldade

em

desempenhar

papis

que

requerem

cooperao

coordenao entre diferentes departamentos;

Tambm possvel fazer uma comparao entre os pontos fortes e fracos inerentes
a esta estrutura organizacional, conforme retratado na Tabela 2.

40
Tabela 2: Vantagens e desvantagens de uma organizao hierrquica (vertical).
Fonte: Netto (2006)
Vantagens das estruturas funcionais
Possibilidade
carreiras

de

desenvolvimento

especializadas

em

Desvantagens das estruturas funcionais

de Descentralizao

das

solicitaes

dos

reas clientes para as diversas reas

localizadas de interesse
Capacidade de obteno de conhecimento Foco da organizao na alta administrao
em

reas

particulares

dentro

da e no no cliente.

organizao
Grupos especializados de trabalho em Coordenao
nmero

reduzido

atendendo

diversas fraca

reas

sobre

existem

improdutivos

macroprocessos
diversos

derivados

das

trabalhos
barreiras

funcionais

Desta forma, embora a organizao hierrquica (verticalizada) possua atrativos e

consiga proporcionar o conhecimento por parte de cada indivduo de sua funo na
empresa, no fluxo horizontal de atividades que ocorre a verdadeira adio de valor
aos produtos e servios. A transformao de uma estrutura verticalizada em uma
estrutura horizontal, por processos, demanda esforo de mudana e adaptao
interna. A Gesto por Processos uma das ferramentas de gesto de operaes
que se prope a promover tal mudana.

Mas o que um processo de negcio? Zairi e Sinclair (1995) definem processo

como a maneira como todos os recursos de uma organizao so utilizados de
forma confivel, consistente e repetvel para atingir os objetivos da mesma. As
quatro caractersticas chave de um processo so:

Inputs previsveis e definveis;

Uma seqncia lgica ou fluxo linear;

Um conjunto de tarefas ou atividades claramente definidas;

Um resultado ou produto desejvel e previsvel;

41
Neste contexto, espera-se que uma estrutura organizacional horizontal melhore a
capacidade da empresa de adaptao ao gosto do consumidor (customizao),
aumente sua velocidade de reao s mudanas no mercado, bem como a
eficincia e eficcia de seus processos. Outras vantagens da viso por
macroprocessos de uma organizao:

Mostra relacionamentos internos e externos entre cliente e fornecedor, por

meio dos quais so gerados produtos e servios;

Ultrapassa as fronteiras funcionais e permite ver como as atividades que

adicionam valor ao cliente so de fato desempenhadas;

Inclui os trs elementos necessrios para descrever um negcio: cliente,

produto e fluxo de trabalho;

Favorece o trabalho em equipe e permite que cada um veja como seu

trabalho se encaixa no processo total;

Dentre as empresas que se prope a adotar a Gesto por Processos, predomina a

estrutura matricial, que nada mais do que um cruzamento entre as interfaces
vertical e horizontal (funcional e por processo). Dependendo da organizao, pode
ser dado maior ou menor enfoque ao aspecto funcional dentro da estrutura matricial:
predominantemente funcional, matricial equilibrada, estrutura por processo puro.

42

CLIENTE
Compras
Alta administrao

P&D

Produo

Logstica

Produo Logstica Vendas

Viso por processos, que atravessa as funes

hierrquicas de modo a criar valor para o cliente

CLIENTE

Finanas Operaes Comercial

Compras

P&D

Vendas

Organizao tradicional, com foco nas funes

hierrquicas e departamentos

Figura 4: Estrutura funcional comparada estrutura por processos.

Adaptado de Netto (2006)

Conforme Netto (2006), a Gesto por Processos pode ser conceituada como o
enfoque

sistmico

de

projetar

melhorar

continuamente

os

processos

organizacionais, por pessoas potencializadas e trabalhando em equipe, combinando

capacidades tecnolgicas emergentes e sob uma postura filosfica para a qualidade,
objetivando a entrega de valor ao cliente .
Zairi e Sinclair (1995) por sua vez definem a Gesto por Processos como uma
abordagem estruturada para analisar e melhorar continuamente atividades como as
de manufatura, marketing, comunicaes, e outros elementos principais da operao
de uma empresa.

Dentre os objetivos principais da Gesto por Processos, pode-se enumerar:

Aumentar o valor do produto ou servio segundo a percepo do cliente;

Simplificar processos, unificando ou eliminando tarefas que no adicionam

valor ao cliente;

43

Aumentar a produtividade, a eficcia e a eficincia;

Aumentar a competitividade, buscando estratgias inovadoras de negcio;

Focar nas estratgias competitivas consideradas as mais importantes pela

empresa: custo, qualidade, confiabilidade de entregas, velocidade de fluxo,
flexibilidade, etc.

Quanto aos princpios fundamentais e regras da Gesto por Processos, temos:

Criar responsveis dos processos;

Obter a informao uma nica vez e direto da fonte;

Enfoque sistmico dos processos e busca contnua por otimizao atravs de

soluo de problemas;

Tratar recursos dispersos geograficamente como se eles estivessem

centralizados;

Atribuir as decises e processamento da informao do processo ao ponto

onde o trabalho realizado

Permitir queles que usam as sadas dos processos executarem o processo;

Atividades principais precisam ser mapeadas e documentadas

Foco no consumidor atravs de ligaes horizontais entre atividades chave

Disciplina, consistncia e capacidade de repetir a performance em termos de

qualidade, atravs de documentos e procedimentos documentados;

Apoio em indicadores de performance de cada processo individual, e

determinao de metas e nveis de produo para atingir os objetivos
corporativos;

Inspirao em best practices para assegurar alta competitividade

A Gesto por Processos uma abordagem para mudana cultural, no sendo

suficiente a simples existncia de bons sistemas e a estrutura certa.

44

Figura 5: Uma estrutura de Gesto por Processos (BPM).

Adaptado de Tread (2006).

Existe um problema de nomenclatura envolvendo o conceito de Gesto por

Processos, pois diversos nomes j foram atribudos a este modelo de gesto desde
seu surgimento. O primeiro termo a ser amplamente difundido foi Reengenharia, no
comeo dos anos 90, mas este termo est muito associado ao projeto da mudana
organizacional, o que no contempla o carter de administrao de operaes,
tambm inerente ao conceito discutido neste trabalho. Por este motivo, optou-se
pela nomenclatura Gesto por Processos, que no deve ser encarada como
sinnimo de Reengenharia.

Na verdade, a Gesto por Processos um conceito mais amplo que procura

fornecer diretrizes para o negcio da empresa tanto em suas atividades de melhoria
contnua quanto nos projetos de mudana por ruptura. Se considerarmos um
enfoque sistmico da melhoria da qualidade e produtividade (Q&P), podemos dizer
que este composto por trs vetores: Tecnologia de Informao (TI), Filosofia da
Qualidade (FQ), e Potencializao (ou empowerment) e Trabalho em Equipe (PTE).
Aqui se entende filosofia da qualidade (FQ) por toda base conceitual associada

45
qualidade total (TQM) e melhoria contnua. Potencializao (PTE) trata dos fatores
que garantem que as pessoas possam de fato obter o poder de que necessitam para
inovar e tomar decises. Projetos de mudana por ruptura (tipicamente
Reengenharia) apiam-se fortemente na interao entre as aplicaes de TI e
pessoas com poder de deciso (PTE). J a prtica de atividades de melhoria
contnua (Kaizen, TQM) apia-se em valores conceituais de qualidade (FQ) e
execuo por pessoas com autonomia (PTE). A Gesto por Processos uma soma
destes vetores de Q&P, e, em ltima instncia, uma sobreposio dos conceitos de
Reengenharia e melhoria contnua (TQM), uma vez que ambos os conceitos podem
ser adotados de maneira integrada.

Davenport (1993) recomenda a adoo integrada da Reengenharia e da melhoria

contnua, listando quatro abordagens diferentes para a integrao entre os
conceitos:

Seqncia de iniciativas de mudana: aperfeioamento gradual de operaes

entre momentos distintos de reestruturao. Ou seja, alternncia entre
Reengenharia de processos e melhoria contnua dos mesmos.

Criao de um portflio de processos: envolve mapear todos os processos da

organizao e definir que tipo de mudana necessria em cada caso
(reformulao ou melhoria gradual).

Limitar o escopo da modelagem de processos: a Reengenharia se limita a

definir o funcionamento macro dos processos, seus inputs e outputs. O
detalhamento fica a cargo dos funcionrios diretamente envolvidos com o
processo.

Obter melhoria atravs da inovao: combina melhoria em curto prazo e

inovao em longo prazo . Consiste em adotar pequenas melhorias nos
processos que de alguma forma conduzam a inovao ou tendncias futuras.

preciso ressaltar que a adoo da Gesto por Processos no necessariamente

desejvel em todas as circunstncias. O fato de a maior parte das abordagens por
processo resultar em estruturas matriciais nas organizaes causa instabilidade e
aumenta o nvel de conflitos internos. Esta instabilidade gera necessidade de

46
coordenao e, em ultima instncia, custos. Embora isto no signifique que uma
empresa gerida por processos ser sempre mais custosa do que uma gerida
funcionalmente, pode-se dizer que a abordagem por processos no compensa em
ambientes onde a competio restrinja -se a custos. Alm disso, antes da adoo da
Gesto por Processos, deve-se fazer uma anlise do benefcio esperado em face ao
investimento necessrio, incluindo comparao com outros investimentos possveis
para a empresa.

Os gestores das empresas muitas vezes procuram reduzir a abrangncia da

abordagem por processos, restringindo-a a alguns processos chave, aos processos
mais operacionais, ou confinando-a a reas to amplas que nenhum participante
tem uma viso clara e completa da cadeia de adio de valor. Esta atitude
compromete enormemente a eficcia da adoo desta ferramenta de gesto, e
motivada muitas vezes pela crena equivocada de que a competio na empresa se
d apenas na dimenso de custo.

Os riscos associados implantao propriamente dita da Gesto por Processos so

diversos, entre eles:

Melhoria de processos no ligados estratgia de negcio;

Falta de envolvimento da alta administrao;

Equipes mal direcionadas, no avaliadas pelo cumprimento de metas, ou que

no conseguem implantar um sistema de avaliao, fundamental para a
melhoria contnua dos processos;

Falta de liderana ou metodologia de implantao.

Falta de alinhamento do departamento de RH a mudana, ou falta de

funcionrios capacitados;

II.2.3 Importncia da TI na Gesto por Processos

Davenport (1993) afirma que importante efetuar uma reflexo sobre processos e
ajudar as empresas a compreender como elas podem modificar seus processos.
Uma vez alcanados estes objetivos, possvel incluir a inovao e a melhoria de

47
processos como fatores intermedirios mais importantes nos estudos das vantagens
dos investimentos em TI.

Tais estudos devem considerar que os investimentos em TI no possuem um va lor

direto, mas sim um potencial para derivar valor. Desta forma, estes investimentos
no so um assunto de tecnologia, mas sim um assunto de negcios, podendo ser
medidos e gerenciados por um controle de perdas e lucros.

Assim, o valor de um investimento de TI corresponde a quanto este investimento

contribuiu para que a organizao se tornasse mais eficiente e eficaz ou seja, seu
impacto sobre os processos de negcio.

Segundo Davenport (1993), as oportunidades para apoiar a abordagem por

processos com a Tecnologia de Informao se enquadram em pelo menos nove
categorias diferentes, que tm como objetivo comum a reduo de custos,
eliminao de tempo gasto nos processos, e assim por diante.

Tabela 3: Categorias de impacto do uso da TI para a Gesto por Processos.

Fonte: Davenport (1993)
IMPACTO

MOTIVO

Automao

Eliminao de mo de obra em um processo

Informao

Coleta de dados a respeito de um processo para anlise futura

Seqncia

Mudana na seqncia na qual o processo desempenhado

Acompanhamento Monitoramento rigoroso da situao e objetos de processo

Analtico

Melhora na anlise de informao e suporte a tomada de

deciso

Geografia

Coordenao de processos em localidades fsicas diversas

Integrao

Coordenao entre tarefas e processos

Intelectual

Armazenamento e disseminao de bens intelectuais

Simplificao

Eliminao de intermedirios em um processo

48

Muitas vezes, entretanto, a experincia de implantao da ferramenta de TI no

boa, com as potencialidades do sistema no sendo totalmente aproveitadas. Isto
ocorre quando o foco da implantao na TI como ferramenta, e no como um meio
de mudanas gerenciais nos processos ou em como a empresa esta estruturada.
Este aspecto bastante importante no caso da Gesto por Processos, visto que a
mudana fundamentalmente estrutural e deve ter a TI como apoio, no como
objetivo final, sob risco de no atingir os benefcios esperados com a abordagem por
processos.

Por ocasio da adoo da Gesto por Processos, a Tecnologia de Informao pode

contribuir de duas formas diferentes: no auxlio do projeto dos processos, ou no
auxlio da construo e operao dos processos de trabalho (em geral, automao).

Dentro das ferramentas de projeto, existem aquelas focadas em simulao, e outras

focadas em modelagem. Na simulao de processos, a ferramenta permite que se
modele o funcionamento de determinada operao e em seguida utiliza modelos
matemticos para projetar o desempenho esperado desta operao. Entre outras
coisas, a simulao til no dimensionamento do processo analisado. J a
modelagem procura representar os processos atravs de smbolos, ou seja, fazer
um desenho do mesmo. As ferramentas mais sofisticadas funcionam de forma que,
medida que o projetista desenha o fluxo de atividades, so salvas informaes
sobre as caractersticas de cada atividade em um banco de dados, utilizado
posteriormente pelo software de apoio ao processo.

J as ferramentas de automao de processos reduzem a necessidade de trabalho

manual, armazenam todas as informaes pertinentes ao processo e automatizam
tarefas repetitivas. Para tal finalidade esto disponveis diversas solues no
mercado, algumas incorporadas em pacotes de maior abrangncia, como os ERPs,
e outras especificas para a gesto de processos. Vale ressaltar que por conta da
grande variabilidade dos processos encontrados nas organizaes, no existe uma
soluo universal que atenda a qualquer tipo de processo. Isso torna fundamental o
uso de critrios claros e uma metodologia de anlise objetiva para a seleo da

49
ferramenta de Gesto de Processos, para evitar que o sucesso da implantao seja
posto em risco devido a uma escolha equivocada.

Existem diferentes tipos de informao acerca de processos que precisam ser

gerenciadas. O primeiro objeto a ser identificado so as atividades, que consistem
nos passos a serem seguidos para realizar o processo. Outro objeto so as rotas, ou
os caminhos que devem ser seguidos para o desempenho das atividades. Os
operadores correspondem s pessoas que executam as tarefas. Por fim, os
documentos englobam as informaes a respeito do contedo do trabalho em
andamento. Cada processo particular apresenta uma relao especfica entre seus
objetos. Desta forma, uma ferramenta de gerenciamento de processos pode possuir
graus variados de automao, ou mesmo ser totalmente manual. Ela pode
armazenar desde dados e documentos digitais a endereos fsicos de documentos
reais. As rotas podem ser manuais, mas costumam ser automatizadas, podendo
enviar notificaes automticas aos operadores ao fim de uma etapa, ou mesmo
registrar tempos de atendimento e espera.

No que diz respeito especificamente automao, esta comporta uma imensa gama
de possibilidades que vo alm do aspecto tecnolgico e so muito importantes para
a Gesto por Processos. Conforme Pessa e Storch (2006), os aspectos principais
da automao so: prover instrumentos para o controle estratgico e gerencial;
assegurar responsabilizao; dissociar o fluxo de informao do fluxo de
documentos; e assegurar instantaneidade do fluxo de informao.

Prover instrumentos para o controle estratgico e gerencial: a possibilidade

de focar a gesto nos processos implica na necessidade de enxergar
processos de forma agregada, no como dados dispersos relativos a cada
vez que o processo foi desempenhado, mas sim como indicadores indicadores estes que devem ser gerados de maneira gil e flexvel pela
ferramenta escolhida.

Assegurar a responsabilizao: trata-se de assegurar que responsabilidades

individuais, nos nveis operacional e gerencial, sejam claramente identificadas
e estejam visveis para todos que possam intervir no processo para garantir
sua qualidade.

50

A tecnologia escolhida para automao de processos deve permitir a

dissociao do fluxo de informaes do fluxo de documentos de duas
maneiras: a substituio de documentos de papel por documentos digitais e a
supresso radical do prprio documento de forma completa.

Fluxo instantneo de informaes nos processos: Isto j factvel graas aos

avanos tecnolgicos dos ltimos anos, faltando apenas o redesenho de
processos e dos ciclos de aprendizado das pessoas, equipes e organizaes
para entenderem as informaes que recebem e para tomarem decises de
forma gil, tanto individual quanto coletivamente.

Finalmente, preciso verificar se as ferramentas de TI podem atender

satisfatoriamente aos requisitos exigidos para a gesto de processos. Para tanto,
til agrupar os processos em categorias. Koch apud Pessa e Storch (2006),
identifica as seguintes categorias:

Processos tipo colaborativo: so processos com pouqussima ou nenhuma

repetitividade, como projetos, cujo valor o contedo gerado, seus
documentos.

Processos tipo administrativo: so processos com alta repetitividade e baixo

valor em suas etapas.

Processos tipo produo: so processos com alta repetitividade, mas cujas

etapas envolvem alto valor.

Processos tipo ad-hoc: so atividades cuja prxima etapa no bem definida

e pode ocorrer cada vez de maneira distinta, tal qual situaes de
emergncia.

Uma organizao que adote a abordagem por processos precisa enquadrar seus
processos nas categorias acima definidas e selecionar ferramentas capazes de lidar
com estas categorias de forma eficiente.

51

II.3 SISTEMAS DE BPM (BPMS)

II.3.1 Introduo
Assim como o nmero de organizaes que adotam a Gesto por Processos tem
crescido continuamente, algumas das mais influentes grandes corporaes do
mercado tm colocado as demandas por automao de processos entre suas
prioridades. Isto se deve a uma srie de fatores, entre os quais podemos destacar:

Presses do mercado por iniciativas que confiram maior velocidade s

empresas e flexibilidade a seus processos, alm de presses dos governos e
sociedade por maior governana corporativa.

Maior integrao de cadeias de valor entre empresas e avano da

terceirizao, incluindo a terceirizao de processos inteiros.

Discusso aprofundada a respeito de prticas gerenciais como programas de

qualidade total (TQM) e Reengenharia, que desde os anos 80 oscilam em
termos de popularidade junto aos gerentes. Essa oscilao criou um
movimento pendular na rea de gerenciamento de processos, entre o
radicalismo e profundidade das mudanas defendidas pela Reengenharia, e o
carter incremental dos programas de TQM.

Necessidade de corrigir problemas associados aos sistemas ERP, que

proliferaram nos anos 90, ou de tornar o investimento em tais sistemas
rentvel. Em especial, procura-se reduzir o enrijecimento dos processos de
negcio da empresa aps a implantao, atravs da transferncia do trabalho
de adaptao incremental dos processos do analista de sistemas para o de
negcios (ou processos).

A resposta a esta demanda por sistemas que dem suporte a Gesto por Processos
so justamente os BPMS (Business Process Mangement Systems). Deve-se
ressaltar, porm, que a existncia destes sistemas s foi possvel graas ao
desenvolvimento e amadurecimento recente de diversas tecnologias, como por
exemplo, a Internet, as assinaturas e autenticaes digitais, o prprio ERP, a
convergncia entre recursos de telecomunicaes e de TI, a convergncia de

52
contedos para mdia digital, o aumento da velocidade de processamento e
transmisso de dados em redes, o middleware, etc.

Outras tecnologias esto ainda em suas etapas iniciais de desenvolvimento, mas j

vm dando grande impulso ao BPMS e a Gesto por Processos. Vale ressaltar: a
XML (Extended Markup Language), linguagem que permite a marcao de textos e
figuras com tags para uso humano, alm da definio de campos para metadados;
os padres de modelagem de processo, definidos pela WfMC (Workflow
Management Coalition) e OMG (Object Management Group); e o desenvolvimento
da BPML (Business Process Modeling Language) e BPMN (Business Process
Modeling Notation).

II.3.2 Definio do BPMS

Basicamente, o BPMS representa uma convergncia das tecnologias de automao
do Workflow, gerenciamento de imagens, GED (Gerenciamento Eletrnico de
Documentos), EDMS (Engineering Document Management Systems) e ECM
(Enterprise Content Management). Em outras palavras, o BPMS o ponto de
convergncia

das

diversas

tecnologias

que

concorriam

para

atender

as

necessidades da Gesto por Processos, procurando responder em especial s

limitaes da gerao anterior de tecnologias de Workflow. (PESSA; STORCH,
2006).

Smith e Fingar (2003) definem BPMS como um ambiente de modelagem, integrao

e execuo para o design, produo e manuteno de processos de negcio.

Silver (2007) afirma que o BPMS uma plataforma fundamental para a realizao
da inovao, eficincia, aderncia s regras e agilidade prometidas pela Gesto por
Processos. Os BPMS apiam todo o ciclo de vida de implantao de processos,
desde a modelagem at o design da implantao, execuo e monitoramento de
atividades de negcio, recebendo feedback para remodelagens e melhora contnua
de desempenho.

53
Existe certa confuso no mercado acerca das nomenclaturas Workflow e BPMS.
Como a tecnologia em questo resultado de um processo evolutivo no linear,
baseado na evoluo a partir de diversos sistemas pr-existentes, natural que os
vendedores de software procurem refletir na denominao da categoria de seu
produto eventuais diferenciais competitivos ou inovaes. Embora existam de fato
grandes diferenas entre as duas ferramentas, Reijers (2006) afirma que os
vendedores e analistas de mercado freqentemente ignoram ou minimizam as
semelhanas entre os BPMS e os sistemas de Workflow, por razes comerciais.

O Workflow uma ferramenta de automao de processos do final dos anos 80,

cujo foco so os processos mais crticos das empresas, caracterizados como
Workflows de produo. Os Workflows de produo so organizados de forma
semelhante s linhas de montagem industriais, sendo por definio fluxos de
trabalho com seqncias e atividades estabilizadas e padronizadas, com grandes
volumes de documentos e processamento.

As tecnologias de Workflow trouxeram uma srie de avanos que constituram o

ponto de partida para o desenvolvimento dos sistemas de BPM. Exemplos destes
avanos so os formulrios eletrnicos (eliminando documentos que apenas
transmitiam fisicamente informaes entre as etapas do processo), as imagens
digitalizadas (mais uma vez, eliminao do uso de papel), e as regras de negcio
internalizadas no sistema (padronizando decises simples ou restringindo as
alternativas de deciso dos usurios). Pode-se dizer que o Workflow tornou mais
fcil a relao entre homem e mquina, integrando tarefas automatizveis com
tarefas cuja participao do homem imprescindvel.

Entretanto, as demandas da Gesto por Processo envolviam recursos que o

Workflow no possua, visto que as bases tecnolgicas existentes ento ainda no
estavam desenvolvidas o suficiente. Os sistemas de BPM, atravs das novas
tecnologias dos anos 90, resolveram muitas destas limitaes, tais como a
necessidade de integrao com bancos de dados corporativos, integrao com
aplicativos sem interveno do usurio, integrao business to business (B2Bi),
operao em tempo real, linguagem padronizada para a representao dos

54
processos e reduo do custo de licenas. Alm disso, os sistemas BPM
contemplam todos os processos de uma organizao, e no apenas os Workflows
de produo. Isto inclui os chamados Workflows ad hoc, que, em relao aos
Workflows de produo, apresentam menor grau de previsibilidade, menor
padronizao de tarefas e menores volumes de documentos ou seja, so fluxos de
trabalho que requerem maior improvisao e uso da inteligncia humana.

Por fim, deve-se ressaltar que o objetivo principal da adoo dos sistemas de BPM
no a substituio de trabalho humano pelo trabalho de mquinas, mas sim a
eliminao completa de atividades que sacrificam o uso da inteligncia humana e a
eliminao do tempo gasto entre tarefas.

II.3.3 Caractersticas fundamentais de um sistema de BPM

Aps a definio do BPMS, podem-se apresentar suas principais funcionalidades. A
seguir so descritas as caractersticas fundamentais de um sistema de BPM,
segundo Marcelo e Storch (2006).

Automao de fluxos de trabalho (Workflow). A engrenagem central de

funcionamento dos BPMS, originalmente presente nos sistemas de Workflow.
Permite que os usurios recebam suas tarefas em caixas de entrada, com as
respectivas instrues normativas e com links para documentos necessrios a
execuo da tarefa. A execuo da tarefa fica registrada em formulrios
eletrnicos que alimentam automaticamente histricos de cada caso.
Eliminao de arquivos paralelos, tanto em papel quanto em diretrios
pessoais.

Integrao de processos fim-a-fim. Os BPMS so capazes de integrar

processos e sub-processos no somente no nvel do Workflow (fluxo de
trabalho, ou seja, tarefas humanas), mas tambm no nvel de EAI (Enterprise
Application Integration, ou seja, tarefas automticas em sistemas). Assim, o
BPMS utiliza dados de sistemas de informao existentes e acrescenta dados
nesses sistemas, em tempo real. Para tanto, o sistema precisa ser capaz de
acessar e incluir dados nos cadastros dos sistemas legados existentes nas

55
organizaes, o que um dos recursos que mais distinguem o BPMS dos
sistemas de Workflow tradicionais.

Integrao com sistemas de pagamento, de modo que um processo possa

envolver a emisso de boletos ou recebimento de avisos de compensao de
cheques de outros sistemas (como por exemplo, sistemas bancrios). Esta
funcionalidade melhora o desempenho do processo, pois elimina filas e
deslocamentos para guichs que nem sempre esto abertos.

Integrao com processos interorganizacionais. As empresas privadas e

rgos pblicos se organizam cada vez mais em redes interorganizacionais,
de forma que cada um atue na rea onde mais eficiente. Isso gera a
necessidade de agilidade na criao de novos processos ou modificao de
processos existentes, sob pena de excluso dos circuitos onde acontecem os
negcios. A ferramenta deve contemplar essa integrao entre empresas,
tanto entre processos j existentes, como com processos em surgimento ou
ainda no estruturados.

Modelagem grfica dos fluxos de trabalho. Uma ferramenta de BPMS deve

possuir uma interface de modelagem grfica, que englobe todos os tipos de
fluxos de processo possveis, desvios, trmites, laos paralelos, juno e
separao posterior de processos para trmite em conjunto, etc. Alm disso,
a funcionalidade deve permitir que os analistas de processo desenhem e
implantem novos fluxos, sem precisar programar, restringindo a participao
do analista de TI integrao com sistemas legados. Os fluxos podem ser
desenhados com base em interface grfica e em notao de objetos de
desenho para descrio de fluxos, compatveis com os padres de notao
que vm surgindo como consenso nos ltimos anos, para que seja possvel o
intercmbio

de

processos

com

outras

modelagem e documentao de processos.

ferramentas

consagradas

de

56

Figura 6: Exemplo de interface de modelagem grfica de processos de um BPMS.

(fonte: Appian Solutions (2007))

Flexibilidade de alterao de regras sem necessidade de programao. O

sistema permite que os analistas de processos assumam a tarefa de executar
tais alteraes. Alm disso, possvel extrair regras internas de sistemas
legados cuja manuteno complicada, e transferi-las para o BPMS. Assim,
tal regra mantida e reutilizada por diversas unidades organizacionais
atravs do BPMS, o que reduz a carga de trabalho para o departamento de
TI.

Documentos eletrnicos com caractersticas que proporcionem a eliminao

do papel como ferramenta de transmisso e uso de documentos. Atravs do
BPMS possvel o uso de documentos eletrnicos com diversas vantagens
em relao ao papel, como a proteo de partes do documento contra acesso
no autorizado, ou anotaes para uso compartilhado. Alm disso, o sistema
no deve limitar-se a permitir a anexao de documentos a atividades, mas
tambm permitir que o usurio interaja com o documento, ainda que no
possa alter-lo, atravs de anotaes, discusses, ou extrao de dados.

57
Devido variedade de tipos de documentos existente, a tendncia de que
os BPMS integrem-se com ferramentas de GED, especialmente voltadas para
atender a estas demandas.

Gerenciamento Eletrnico de

Documentos

contedos.

Engloba

categorizao de documentos e contedos de documentos atravs de

vocabulrios padronizados, pesquisa por palavra-chave no texto inteiro,
controle de verses, armazenamento em estrutura de pastas, proteo e
controle de acessos a documentos, etc.

Figura 7: Exemplo de caixa de entrada de usurio de um BPMS, com suas tarefas,

gerenciador de documentos e ferramentas colaborativas.
(fonte: Appian Solutions (2007))

Formulrios eletrnicos para entrada de dados. Atravs do BPMS possvel

a extino dos formulrios de papel, tanto para preenchimento que alimenta
automaticamente outros sistemas, quanto para aqueles que precisam ser
impressos para serem preenchidos. Dentre os diferentes pacotes de BPMS
disponveis no mercado, existe ampla variao nos recursos oferecidos para

58
flexibilizar a criao e manuteno de diversos tipos de formulrios
eletrnicos, facilitar seu preenchimento, garantir segurana dos dados,
proteger campos de acesso restrito, e reconhecer assinaturas digitais (para
dispensar o papel como prova de autenticidade).

Formatao de documentos padro com dados variveis. O BPMS deve

permitir a emisso de documentos em formatos padro e preenchimento
automtico com dados variveis. Isto importante, pois muitos documentos
de empresas tm caractersticas altamente estruturadas e suscetveis
padronizao, por exemplo, faturas, notas fiscais, avisos de cobrana, e-mails
de confirmao a clientes, etc. Assim, uma ferramenta de BPM deve ser
capaz de definir textos-padro produzidos para notificao de atores ou
interessados em cada tipo de processo.

Adoo de padres de dados e objetos, adequando-se Arquitetura

Orientada para Servios (SOA) e tecnologia de Web Services. Desta forma,
torna-se possvel fragmentar as funes dos processos em componentes e
terceirizar o desenvolvimento de qualquer destes componentes para uma
fbrica

de

software,

aproveitando

componentes

que

tenham

sido

desenvolvidos previamente para outras empresas, e que sejam negociados

no mercado de Web Services.

Componentes do tipo Application Program Interface (API), ou seja, que

permitem o desenvolvimento de conectores para integrao de processos do
BPMS com outros sistemas que sejam implementados na empresa,
principalmente aqueles que possuam carter de componentes bsicos da
arquitetura da empresa (como o ERP).

Monitoramento do progresso e desempenho de processos em tempo real. O

monitoramento em tempo real permite a atribuio de responsabilidades
sobre o desempenho do processo at o nvel superior da organizao, que
pode tomar atitudes e decises com base no nvel dos indicadores definidos
como crticos. O controle dos tempos de execuo aponta pontos crticos a
serem melhorados em cada processo, atravs da manuteno evolutiva dos
fluxos. Alm disso, so oferecidos indicadores de desempenho operacional
do processo. Estas funcionalidades so extremamente importantes para

59
viabilizar o papel do chamado process owner (dono do processo) nas novas
estruturas organizacionais.

Figura 8: Relatrios de monitoramento do desempenho de processos.

(fonte: Appian Solutions (2007))

Shaw et al. (2007) descreve outras caractersticas dos BPMS, como o acesso a
ferramentas de Gesto por Processos tais quais: bibliotecas de processos de
negcio baseados em best practices; manipulao grfica manual de configuraes;
mudana automatizada de configuraes de aplicativos; links com sistemas de
comunicao; e, possivelmente, gesto de projetos integrada e controle de
mudanas. Os BPMS podem inclusive ter um design que os permita escolher
automaticamente entre opes de reconfigurao de processos, ou facilitar a
escolha manual da nova configurao.

60

Figura 9: Estrutura do BPMS da Appian Solutions, segundo o prprio fornecedor.

(fonte: Appian Solutions (2007))

Quanto aos riscos associados implantao do BPMS, Reijers (2006) afirma que a
falta de uma orientao por processos pr-existente na organizao pode estar
relacionada a todo tipo de problemas que afetam o custo, a velocidade e o sucesso
final da implantao. Existem outros fatores crticos associados implantao de
sistemas de Workflow que tambm se aplicam ao caso dos BPMS, devido s
similaridades essenciais entre os dois sistemas, com a possvel exceo de algumas
limitaes tecnolgicas j superadas nos BPMS, citadas anteriormente. Podemos
distinguir quatro categorias fundamentais para o sucesso e fracasso da implantao
destes sistemas: tecnologia, gesto, pessoas e processo.

Sob a perspectiva da tecnologia, o foco na capacidade de interoperabilidade com

outros sistemas como requisito fundamental para o sucesso (o que era uma das
maiores limitaes do Workflow). Alm disso, importante que a ferramenta seja
capaz de se adaptar a aumentos de demanda, ou seja, possua flexibilidade de
expanso. Tambm vale destacar que a escolha da ferramenta correta para cada
caso especfico fundamental.

61

Do ponto de vista da gesto, as razes para o fracasso da implantao so similares

quelas que arrunam projetos de Reengenharia: gerenciamento pobre ou ineficiente
das mudanas, resistncia por parte de organizaes burocrticas rgidas, e falta de
apoio contnuo da alta gerncia.

Na categoria pessoas, os usurios precisam estar convencidos de que a ferramenta

dar suporte a sua maneira de trabalhar. Para isso, alguns autores sugerem que o
designer do sistema ou de sua implantao deve experimentar o trabalho do usurio
final a quem o sistema esta destinado. Alm disso, a percepo por parte do usurio
final de que o sistema fcil de usar, comunicao eficiente com os funcionrios e
sua participao ativa no projeto de impla ntao, so apontados como importantes
fatores para o sucesso da adoo de sistemas Workflow.

Por fim, a categoria processos, cujos aspectos apontam para a necessidade da

existncia de uma organizao por processos nas empresas antes da adoo de
ferramentas de Workflow / BPMS, conforme citado anteriormente. Os fatores crticos
aqui englobados incluem: uma abordagem por processos no desenvolvimento de
aplicativos; compreenso, pela organizao, do conceito de processo; e percepo
dos processos chave desde os estgios iniciais do processo de implantao.

II.3.4 Tendncias futuras

Definidas as caractersticas, possvel observar algumas tendncias para a
evoluo dos sistemas de BPM. Pessa e Storch (2006) sugerem algumas possveis
tendncias futuras de mercado:

Consolidao de fornecedores atravs de fuso e aquisio de empresas.

Surgimento e crescimento acelerado de empresas que conseguem atender

de forma diferenciada as necessidades de segmentos especficos de
mercado. Estratgias de marketing e penetrao para buscar a liderana de
nicho de mercado.

62

Incorporao nos BPMS de ferramentas de colaborao virtual (fruns, chats,

mensagens instantneas, conferencias virtuais, etc.).

Alinhamento de fornecedores em torno de ambientes e plataformas de infraestrutura dominantes.

Aproximao dos movimentos de Gesto por Processos e Gesto de

Projetos. O BPMS pode ser de grande auxilio na Gesto de Projetos, visto
que projetos tambm englobam processos padronizveis que precisam ser
tornados eficientes.

Segundo Ashish Mohindroo, diretor snior de produtos da Oracle (Redwood Shores,

Califrnia), em entrevista para Feig (2007), inovaes recentes em tecnologia de
BPM tem sido principalmente ao redor de recursos de simulao. Sistemas mais
novos tm a habilidade de amarrar-se a ferramentas de BI (Business Inteligence) e
coletar dados para criar uma viso em tempo real do negcio, e como conseqncia,
simulaes mais realistas. Muitos especialistas apontam a integrao entre BPMS e
BI como a direo futura destas tecnologias, incluindo ai o uso de dados histricos
para o desenvolvimento dos processos alm da adio de dados em tempo real para
processos que envolvam tomada de deciso.

Phil Gilbert, CFO e EVP do grupo de produtos para a Lombardi Software (Austin,
Texas), que fornece uma srie de solues de BPM, explica que a tendncia hoje
em dia que o objetivo das implementaes de BPMS seja a melhora na
experincia do consumidor (tanto interno quanto externo), ao invs do simples
aumento de eficincia dos processos.

Por fim, algumas consideraes a respeito da popularidade do BPMS entre

empresas. De acordo com o Instituto Gartner (Stamford, Connecticut), o mercado
global de sistemas BPM est em franco crescimento e deve ultrapassar U$ 1 bilho
em 2007, em termos de rendimentos totais de software, atingindo U$ 2,6 bilhes em
2011. Segundo a empresa, a proliferao dos BPMS, que teve incio em 2005,
marca o fim das solues tipo pure-play cujo foco exclusivo eram capabilidades de
Workflow humano em reas especficas do mercado. (FEIG, 2007).

63

II.3.5 BPMN
BPMN uma notao baseada em fluxograma utilizada para definir processos de
negcio. A BPMN foi criada a partir de um acordo entre diversas empresas que
comercializam ferramentas de modelagem de processos. Este acordo estabeleceu
uma notao unificada, em contraste com as notaes prprias de cada software
previamente existentes, de forma a facilitar o treinamento e entendimento por parte
do usurio final.

A iniciativa de criar uma interface grfica para a linguagem de execuo de

processos partiu do BPMI (Business Process Management Institute). Em Maio de
2004 foi lanada a especificao de BPMN 1.0, e em Fevereiro de 2006 o BPMN foi
adotado pelo OMG (Object Management Group consrcio internacional de
empresas do ramo de computao, sem fins lucrativos, dedicado a integrao de
padres para uma ampla gama de tecnologias e ramos de negcio).

Processos modelados por analistas de negcios em BPMN podem ser diretamente

aplicados a sistemas de BPM sem precisar de traduo humana para outras
linguagens, ou seja, a notao apresenta inerente um mecanismo automtico de
converso para BPEL (Business Process Execution Language). Assim, possvel
modelar os processos para uso no BPMS sem a necessidade de digitao de uma
nica linha de cdigo, fato amplamente alardeado pelas empresas que
comercializam tais sistemas.

Na prtica, os sistemas disponveis no mercado apresentam boa capacidade de

reconhecimento e converso de processos modelados em BPMN para processos
executveis. Entretanto, tal converso quase nunca perfeita, sendo necessrios
pequenos ajustes e complementos posteriores. Os formulrios a serem preenchidos
e consultados, bem como sua associao s diferentes etapas e atores, tambm
precisam ser criados dentro da interface do BPMS utilizado. A notao BPMN esta
apresentada de forma sucinta no apndice A.

64

Figura 10: Papel da BPMN na modelagem e execuo de processos em um

ambiente de negcios.
(Fonte: OMG (2007))

II.4 REQUISITOS DE SOFTWARE

O objetivo deste captulo fornecer uma breve descrio do que so requisitos de
software. So definidas as duas categorias de requisitos relevantes para este
trabalho, e a maneira como estes requisitos devem ser descritos.

II.4.1 Definio de Requisito

Os requisitos de um sistema so fundamentalmente uma descrio de suas funes
e restries, buscando permitir a compreenso do problema a ser solucionado pelo
sistema. Os requisitos podem guiar tanto o processo de desenvolvimento do
software quanto o processo de aquisio. (SOMMERVILLE, 2003)

65
Todo o trabalho acerca do levantamento dos requisitos chamado de engenharia de
requisitos. Este trabalho inclui o processo de descobrir, analisar, documentar, e
verificar as funes e restries do sistema.

Dentro da indstria de software pode-se verificar grande variabilidade na forma de

utilizao dos requisitos. Em alguns casos, trata -se de uma definio minuciosa e
formalizada matematicamente das funes do sistema. Outros encaram os requisitos
como declaraes abstratas e de alto nvel das funcionalidades e restries do
software. De maneira geral, espera-se que a definio dos requisitos por parte do
cliente seja abstrata o suficiente para que no estabelea uma soluo predefinida,
de modo a garantir a existncia de diferentes alternativas para atendimento das
necessidades do cliente.

II.4.2 Requisitos funcionais

Os requisitos funcionais so declaraes de funes que o sistema deve possuir, da
maneira como o sistema deve reagir a entradas especficas e como deve se
comportar em determinadas situaes. Os requisitos funcionais podem ainda, caso
haja necessidade, declarar explicitamente o que o sistema no deve fazer.

Segundo Sommerville (2003), os requisitos funcionais para um sistema descrevem a

funcionalidade ou os servios que se espera que o sistema fornea. Eles dependem
do tipo de software que est sendo desenvolvido (ou adquirido) e dos usurios de
software que se espera verificar. Os requisitos funcionais costumam ser expressos
de modo bastante geral, como requisitos de usurio. Exemplos de requisitos
funcionais so: o sistema deve possuir ferramentas de mapeamento de processos; o
sistema deve possuir funcionalidade de gerenciamento de documentos; e o sistema
deve permitir a criao de relatrios a partir de dados armazenados.

A compreenso do conceito de requisitos funcionais ser aprofundada atravs da

aplicao prtica promovida na proposta deste trabalho. Desta forma, para maior

66
detalhamento a respeito de como usar os requisitos funcionais, favor referir-se ao
item III.2.1.

II.4.3 Requisitos no funcionais

Sommervile (2003) afirma que os requisitos no funcionais so aqueles que no
dizem respeito diretamente s funes especficas fornecidas pelo sistema. Eles
podem estar relacionados a

propriedades de sistema emergentes, como

confiabilidade, tempo de resposta e espao em disco. Como alternativa, eles podem

definir restries para o sistema, como a capacidade dos dispositivos de E/S
(entrada/sada) e as representaes de dados utilizadas nas interfaces de sistema.
Alguns requisitos no funcionais podem ainda estar relacionados no apenas ao
software a ser desenvolvido, mas tambm ao prprio processo de desenvolvimento.
Exemplos de requisitos deste tipo so especificaes do projeto ou dos padres de
qualidade a serem seguidos.

Deve-se ressaltar que muitas vezes os requisitos no funcionais so mais

importantes que os requisitos funcionais individuais. Isto porque eles no definem
caractersticas individuais do software, mas sim caractersticas do sistema como um
todo. Falhas no cumprimento de requisitos funcionais apenas degradam o sistema,
enquanto que falhas no cumprimento dos requisitos no funcionais podem inutilizar
o sistema por completo.

De acordo com Paula Filho (2003), a definio dos requisitos no funcionais deve
ser quantitativa e precisa. Alm disso, apenas as caractersticas consideradas
indispensveis para a aceitao do sistema devem ser tratadas como requisitos no
funcionais. Um exemplo de requisito no funcional o estabelecimento do nmero
de usurios simultneos que o sistema deve suportar.

O uso dos requisitos no funcionais est ilustrado na proposta deste trabalho.

Assim, para maior detalhamento a respeito deste conceito, favor referir-se ao item
III.2.2.

67

III PROPOSTA
Este captulo descreve a proposta deste estudo, a qual, conforme previamente
estabelecido, est dividida em trs etapas: modelagem dos processos de negcio,
requisitos do software BPMS, e plano de implantao. A proposta, caso aceita, est
pronta para uso por parte da empresa onde foi feito o estgio.

III.1 MODELAGEM DE PROCESSOS DE NEGCIO

A primeira etapa desta proposta consiste em selecionar um grupo de processos e
model-los para uso pelo BPMS. Conforme previamente descrito, a inteno
utilizar a ferramenta inicialmente em um pequeno nmero de processos, expandindo
o uso progressivamente, conforme os problemas iniciais detectados sejam
resolvidos e a eficcia e eficincia do programa estejam comprovadas (implantao
em fases). O detalhamento de um grupo de processos tambm til para o
processo de seleo do software, visto que permite identificar as necessidades reais
dos processos contemplados.

III.1.1 Seleo dos processos para modelagem

Inicialmente, foi necessrio escolher quais os processos que fariam parte do Projeto
Piloto (primeira fase de implantao). A escolha foi feita numa primeira etapa com a
equipe de TI, sendo submetida em seguida validao por parte das principais
reas participantes do processo. O mtodo utilizado foi a matriz de deciso, sendo
os pesos e notas resultado de consenso entre o autor deste trabalho e o
Departamento de TI.

Desta forma, partiu-se de um nmero relativamente alto de processos candidatos:

dezenove. Para a maioria destes processos havia sido feita uma lista de atividades e
atores envolvidos, e alguns haviam sido efetivamente mapeados, embora sem
grande detalhamento . Estas informaes so provenientes de duas fontes principais:
o prprio Departamento de Projetos, que tem como uma de suas atribuies mais

68
freqentes o estudo e melhoria dos processos de negcio da empresa; e o
Departamento de TI, que produziu o contedo para a implantao do ERP.

A partir da experincia prvia de membros do Departamento de TI, estabeleceu-se

que o grupo inicial no deveria contar com mais de cinco processos, de forma a
permitir um monitoramento minucioso e uma implantao inicial rpida, alm de
flexibilidade e agilidade em caso de problemas. Determinou-se ainda a necessidade
de graus de complexidade variveis entre os processos, para garantir um uso inicial
abrangente do software, embora complexidade excessiva tenha sido evitada. A
importncia do processo e o impacto de eventuais falhas em sua operao foram um
critrio especialmente relevante para a seleo.

Portanto, embora o nmero final possa ser menor do que o definido, a proposta
apresenta cinco processos selecionados entre o total originalmente disponvel.
Ficar a cargo do Departamento de TI, por ocasio da implantao inicial, decidir o
nmero de processos efetivamente contemplados. De qualquer forma, mesmo que
nem todos os mapeamentos sejam utilizados na primeira fase, esta proposta oferece
alternativas de escolha, e processos eventualmente no utilizados nesta fase
provavelmente o sero na fase de expanso.

Os critrios utilizados na seleo e seus respectivos pesos (1 5) esto

apresentados na Tabela 4.

Tabela 4: Critrios e pesos utilizados na escolha dos processos para modelagem.

Processo

Avaliao

Peso

Impacto potencial em caso de falha na

operao

Quanto menor, melhor

Adequabilidade ao uso no BPMS

Quanto maior, melhor

Quanto maior, melhor

Grau de detalhamento das

informaes pr-existentes

69
Processo

Avaliao

Peso

Necessidade de monitoramento/
melhoria

Quanto maior, melhor

Quanto maior o
reas envolvidas

interesse em participar

do projeto, melhor

A matriz de deciso utilizada est dividida em trs graus de complexidade de

processo: baixo, mdio, alto. O objetivo selecionar um processo simples, dois de
complexidade mediana, e dois de maior complexidade. As notas atribudas aos
candidatos esto apresentadas nas Tabelas 5, 6 e 7.
Tabela 5: Matriz de deciso para escolha de processo de complexidade baixa.
PROCESSO

Conserto de pea
defeituosa

Controle de
qualidade da
produo
terceirizada
N
N*P

CRITRIO

N*P

Impacto potencial em caso de falha

na operao

20

Adequabilidade ao uso no BPMS

12

Grau de detalhamento das

informaes pr existentes

Necessidade de monitoramento/
melhoria

reas envolvidas

N*P

10

25

16

20

12

12

TOTAL

50

PROCESSO

Processamento
de venda em loja

53

Compra de
material no
produtivo

CRITRIO

N*P

N*P

Impacto potencial em caso de falha

na operao

20

Adequabilidade ao uso no BPMS

20

20

Grau de detalhamento das

informaes pr existentes

Necessidade de monitoramento/
melhoria

12

reas envolvidas

TOTAL

Processamento
de "Special Order"

44

63

74

70

Tabela 6: Matriz de deciso para escolha de dois processos de complexidade mdia.

Recebimento de
Devoluo de
PROCESSO
Franquia /
Multimarca
P
N
N*P

CRITRIO

Recebimento de
Devoluo de
Loja Propria

Emisso de
Ordem de
Produo
(Faco)
N
N*P

Envio de matria
prima para
produo
terceirizada
N
N*P

N*P

15

20

10

10

12

16

16

15

12

12

Necessidade de monitoramento/
melhoria

12

reas envolvidas

Impacto potencial em caso de falha

na operao

Adequabilidade ao uso no BPMS

Grau de detalhamento das

informaes pr existentes

TOTAL

64

45

PROCESSO

Conferncia de
documentao
fiscal

Envio de produtos
para as lojas
proprias

58

52

Compra de
tecidos e
aviamentos

Montagem do
Showroom

CRITRIO

N*P

N*P

N*P

N*P

Impacto potencial em caso de falha

na operao

10

10

15

Adequabilidade ao uso no BPMS

16

16

16

16

Grau de detalhamento das

informaes pr existentes

12

Necessidade de monitoramento/
melhoria

12

reas envolvidas

TOTAL

44

50

55

45

71

Tabela 7: Matriz de deciso para escolha de dois processos de complexidade alta.

PROCESSO

Produo interna
(Marca A)

Produo por
terceiros (Marca
C)

Desenvolvimento
de Produto
(Marca C)

Abertura de loja
nova

CRITRIO

N*P

N*P

N*P

N*P

Impacto potencial em caso de falha

na operao

10

15

Adequabilidade ao uso no BPMS

16

20

16

Grau de detalhamento das

informaes pr existentes

15

12

Necessidade de monitoramento/
melhoria

15

12

15

reas envolvidas

TOTAL

64

PROCESSO

42

Exportao para Exportao para

loja propria
lojas multi-marcas

CRITRIO

N*P

N*P

Impacto potencial em caso de falha

na operao

15

Adequabilidade ao uso no BPMS

12

Grau de detalhamento das

informaes pr existentes

12

Necessidade de monitoramento/
melhoria

12

15

reas envolvidas

TOTAL

57

43

58

53

72
A Tabela 8 descreve brevemente os processos selecionados.

Tabela 8: Descrio sucinta dos processos escolhidos.

Processo

Descrio

Processamento de Special Registro de venda e ordem de produo de peas

Orders
Envio

customizadas (Special Orders) da marca A.

de

matria

prima Toda a produo das marcas B e C feita por

para produo terceirizada

terceiros. Os materiais utilizados na confeco,

entretanto,

so

adquiridos

pela

empresa

pertencem a ela, devendo ser retirados pelos

faccionistas contratados por ocasio da produo.
Recebimento de devoluo Recebimento, conferncia dupla e alocao no
de loja prpria

estoque de peas das lojas prprias das marcas B

e C.

Produo interna (marca A)

Desenvolvimento
produtos (marca C)

Produo interna das peas da marca A.

de Desenvolvimento e preparao para produo das

peas da prxima coleo da marca C.

III.1.2 Modelagem dos processos

Nesta etapa do trabalho, os processos selecionados foram mapeados e modelados
de forma a estarem aptos a insero no sistema de BPM. Isto foi feito em trs
etapas.

Primeiro, foram coletadas informaes a respeito das etapas do processo, as

relaes entre as etapas, os documentos e atores envolvidos. Parte desta
informao j havia sido reunida em projetos anteriores.

Segundo, o processo foi mapeado, ainda sem grande detalhamento, atravs do

programa MS Visio, sob a forma de fluxograma.

73
Por fim, o processo foi detalhado e modelado para ser inteligvel para o software
onde ser inserido. Este segundo mapeamento foi feito j na notao utilizada pelo
BPMS, a saber, a BPMN (Business Process Modeling Notation). O programa de
modelagem utilizado foi o MS Visio, porm com uma extenso especial para BPMN
(na linguagem do programa, um Stencil). Normalmente, o prprio software de BPM
apresenta um mdulo de modelagem em BPMN, porm a aquisio da ferramenta
ainda no foi concretizada, da a necessidade de uso do MS Visio. No item 3.5 do
captulo II o leitor encontra informaes detalhadas a respeito da BPMN. No
Apndice A (pg. 124) pode ser encontrada uma lista dos elementos componentes
do BPMN utilizados neste trabalho.

O resultado da modelagem dos processos em BPMN est representado nas Figuras

11, 12, 13, 14 e 15. Cada processo acompanhado de uma descrio prvia de
algumas de suas caractersticas principais.

74
PROCESSO 1
Nome: Processamento de Special Orders
Complexidade: Baixa
reas envolvidas: Comercial (lojas), PCP (produo).
Documentos envolvidos: Pedido assinado.
Informaes adicionais:

A durao atual mdia de 3 semanas.

Special Orders so pedidos de peas do catlogo com pequenas alteraes:

cor, comprimento, modelagem, tecido, etc. A alterao deve, no entanto, ser
aprovada pelo estilista da marca (alteraes que desfigurem a pea so
recusadas).

Figura 11: Modelagem do Processo 1 Processamento de Special Orders

75

76
PROCESSO 2
Nome: Envio de matria prima para produo terceirizada
Complexidade: Mdia
reas envolvidas: PCP, Compras (Almoxarifados), Distribuio, Fiscal
Documentos envolvidos: Real de Corte, Ordem de Emisso de Nota Fiscal, Nota
Fiscal.
Informaes adicionais:

O processo padro inclui envio de tecido.

A durao mdia atual de aproximadamente 5 dias.

A pea piloto o modelo utilizado pelo faccionista na confeco das peas,

enquanto que o risco uma plotagem em tamanho real dos cortes a serem
feitos no tecido, na etapa inicial de produo. Estes dois itens so
adicionados apenas no momento do carregamento.

Real de Corte um documento que estabelece a quantidade real a ser

produzida. A diferena em relao programao original decorre da
disponibilidade de tecido. A variao pode corresponder a at 5% do original,
em nmero de peas.

Figura 12: Modelagem do Processo 2 - Envio de matria prima para produo

terceirizada.

77

78
PROCESSO 3
Nome: Recebimento de devoluo de loja prpria
Complexidade: Mdia
reas envolvidas: Distribuio, Auditoria (Portaria, Segurana).
Documentos envolvidos: Nota Fiscal, Ficha de Grade.
Informaes adicionais:

A Ficha de Grade um registro de todas as peas cujos cdigos de barra

foram conferidos (discriminadas em cdigo e quantidade). O sistema compara
a lista de peas com o registro do que foi emitido pela loja de origem.

O processo modelado costuma ter durao inferior a um dia, porm pode

haver excees, quando o volume das devolues supera a capacidade diria
de conferncia pea a pea.

Figura 13: Modelagem do Processo 3 - Recebimento de devoluo de loja prpria.

79

80
PROCESSO 4
Nome: Desenvolvimento de Produtos (marca C)
Complexidade: Alta
reas envolvidas: Produto (Pilotagem, Digitalizao), PCP (Qualidade, Produo),
Comercial.
Documentos envolvidos: Ficha de Desenvolvimento de Produto, Ficha Tcnica,
Risco.
Informaes adicionais:

A durao atual mdia 3 meses (desde o inicio do desenvolvimento da

coleo at o Show Room ou entrega da produo nas lojas).

Risco um documento com o encaixe (em tamanho real) das diferentes

partes a serem cortadas no tecido, para produo da pea. O objetivo
minimizar o consumo de tecido na produo. O encaixe modelado em CAD
e plotado para ser entregue ao fornecedor.

Algumas

tarefas

envolvem

participao

conjunta

dos

departamentos

Comercial e Produto.

Figura 14: Modelagem do Processo 4 - Desenvolvimento de Produtos (marca C).

81

82
PROCESSO 5
Nome: Produo Interna (marca A)
Complexidade: Alta
reas envolvidas: PCP (Produo Costura e Corte), Compras (Aviamentos).
Documentos envolvidos: Ficha de Solicitao de Excluso, Risco.
Informaes adicionais:
A durao atual mdia de 10 dias.
Para informaes a respeito do Risco, consultar processo anterior.
O setor de Costura conta com Controle de Qualidade prprio (interno).
Exceto pelo corte, toda a produo manual (alta -costura).

Figura 15: Modelagem do Processo 5 - Produo Interna (marca A).

83

84

III.2 REQUISITOS DO SOFTWARE BPMS

A segunda etapa desta proposta consiste em definir os requisitos a serem
preenchidos pelo sistema para atender s necessidades da empresa. Atualmente, o
mercado de solues de BPM ainda encontra-se em seus estgios iniciais de
desenvolvimento, de forma que os softwares oferecidos representam a viso e
idias prprias dos desenvolvedores a respeito do que as empresas precisam e
querem em um sistema de gerenciamento de processos. natural que isto cause
um pouco de confuso, e que os softwares de diferentes fornecedores apresentem
grande variabilidade entre si. Esta sesso busca definir clara e objetivamente os
requisitos do BPMS que ser utilizado na empresa, de modo a dar suporte ao
processo de escolha do fornecedor dentre as diversas opes existentes no
mercado.

A definio foi feita com foco nos requisitos funcionais (funcionalidades ou

ferramentas do programa), requisitos no-funcionais (caractersticas inerentes ao
sistema), e requisitos contratuais (aspectos relevantes para o processo de
aquisio). A modelagem de processos efetuada no captulo anterior tambm
desempenha um papel no processo de seleo, visto que diferentes processos
possuem diferentes necessidades, determinando assim diferentes requisitos.

III.2.1 Requisitos funcionais

Para a definio dos requisitos funcionais, partiu-se de um conjunto de
funcionalidades encontradas em sistemas de BPM, presente na fundamentao
terica deste trabalho. O passo seguinte foi identificar, a partir dos processos de
negcio atualmente existentes, e das modificaes necessrias para a adoo da
Gesto por Processos, quais das funcionalidades so essenciais para a empresa.
Esta etapa foi efetuada em conjunto com o Departamento de TI e gerentes das
reas envolvidas. Foi feita ainda uma apresentao por parte de um potencial
fornecedor da ferramenta, onde as funcionalidades do software apresentado foram
detalhadas, de forma a tornar mais claro o potencial de aplicao na organizao.

85

Desta forma, foi possvel levantar um conjunto de atributos fundamentais para o

software a ser adquirido. Estes atributos esto documentados a seguir,
acompanhados de uma breve justificativa e descrio da aplicao pretendida
dentro da empresa.

Requisito Funcional 1: Automao de Processos de Negcio (Workflow)

Descrio: Esta funcionalidade deve permitir que tarefas sejam distribudas aos
usurios correspondentes automaticamente, atravs de rotas de processo prestabelecidas. Alm disso, as etapas do processo desempenhadas por sistemas
devem ser disparadas automaticamente, e as informaes necessrias para a
execuo das tarefas devem acompanhar o fluxo de trabalho.

Os benefcios

esperados da automao dos processos de negcio so ganho de eficincia e

reduo do lead time de execuo dos processos. Maior detalhamento pode ser
encontrado nos ite ns II.2.3 (pg. 50) e II.3.3 (pg. 56) deste trabalho.
Aplicao na empresa: Automao do grupo de processos de negcio selecionado
para o projeto piloto de implantao, e de processos que sejam includos
posteriormente. A automao permitir a reduo do lead-time destes processos,
graas maior agilidade na distribuio das tarefas, e disponibilizao imediata da
informao. Tarefas de consolidao de dados dos processos selecionados,
efetuadas atualmente em planilhas eletrnicas atravs de relatrios obtidos de
diversos sistemas legados, sero eliminadas. Os processos nos quais o impacto da
automao na produtividade ser maior so: desenvolvimento de produtos,
acompanhamento da produo externa, e compra de materiais. Estes processos
trabalham com prazos estreitos, como a data de showroom da coleo ou a data de
entrega da produo, cujo no atendimento resulta em perda de vendas e
faturamento.
Atores envolvidos: Funcionrios participantes dos processos inseridos no sistema.

Requisito Funcional 2: Modelagem ou edio de processos

Descrio: Deve ser possvel modificar, ampliar ou atualizar os processos de
negcio atravs de interface grfica intuitiva e de linguagem de modelagem aceita

86
como padro (BPMN). Esta funcionalidade reduz a dependncia das diversas reas
em relao ao Departamento de TI, melhorando a capacidade de resposta da
organizao a mudanas no ambiente em que est inserida. Maior detalhamento
pode ser encontrado no item II.3.3 (pg. 57) deste trabalho.
Aplicao na empresa: Permitir aos gerentes e diretores a promoo de
mudanas e melhorias nos processos da empresa sem depender de alteraes
demoradas nos sistemas envolvidos. Reduzir a sobrecarga de trabalho do
Departamento de TI, restringindo sua participao aos casos em que haja
necessidade de integrao com bancos de dados de outros sistemas. Esta
funcionalidade especialmente til para o Departamento de Projetos, cuja atribuio
justamente promover melhorias nos processos vigentes da empresa e modelar o
funcionamento de novos processos.
Atores envolvidos: Gerentes das reas e Departamento de Projetos.

Requisito Funcional 3: Gerenciamento Eletrnico de Documentos (GED)

Descrio: Funcionalidade que permite o armazenamento, categorizao, proteo,
controle de acessos e de verses de documentos. Maior detalhamento pode ser
encontrado no item II.3.3 (pg. 59) deste trabalho.
Aplicao na empresa: O GED aumentar consideravelmente a produtividade da
empresa, por facilitar o acesso informao e estruturar a maneira como esta
armazenada e organizada, alm de estabelecer padres para a documentao.
Atualmente, a empresa no conta com nenhuma forma estruturada de gesto de
seus documentos. Cada rea e usurio conta com uma pasta compartilhada na rede
local, com acesso restrito, onde os documentos ficam guardados. As reas onde o
volume de gerao de documentos maior so Produto (documentao das peas e
do processo de desenvolvimento), Projetos (pois para cada projeto so feitos
mapeamentos, anlises, propostas e relatrios), Fiscal e Financeiro.
O Departamento de Projetos ser beneficiado com o acesso facilitado s
informaes e relatrios de toda e empresa, pois isto reduzir o tempo despendido
na coleta de dados e aumentar a acurcia dos mesmos.
Atores envolvidos: Departamentos de Produto, Projetos, Fiscal e Financeiro.
Expanso do uso englobar todos os cargos administrativos da empresa.

87

Requisito Funcional 4: Criao de formulrios para coleta de dados

Descrio: O BPMS deve permitir a criao de formulrios eletrnicos que sero
associados s etapas dos processos que exigem inputs, permitindo a eliminao dos
formulrios de papel e do processo de digitalizao dos mesmos. Os formulrios
devem possuir opes de proteo de campos de acesso restrito, reconhecimento
de assinatura digital, e ferramentas para facilitar o preenchimento por parte do
usurio final. Maior detalhamento pode ser encontrado no item II.3.3 (pg. 58 e 59)
deste trabalho.
Aplicao na empresa: Os formulrios eletrnicos permitiro a reduo do intenso
fluxo de papel observado atualmente na organi zao. Processos de digitao
(digitalizao) da informao coletada em formulrios de papel sero eliminados.
Com os formulrios armazenados digitalmente, os gerentes possuiro maior volume
de dados para anlises e auxlio tomada de deciso. Alm disso, o
reconhecimento de assinatura digital encurtar o tempo de execuo dos processos
que dependem de aprovaes mltiplas de gerentes e/ou diretores (compra de
materiais, liberao ou devoluo de notas fiscais com problemas, aprovao de
peas barradas no controle de qualidade, entre outros).
A responsabilidade pela criao do formulrio e anexao ao processo ser
inicialmente do Departamento de TI, a partir de solicitao dos gerentes.
Posteriormente, esta funo ser assumida pelos prprios gerentes e Departamento
de Projetos.
Atores envolvidos: Gerentes, Departamento de TI e Projetos.

88

Requisito Funcional 5: Monitoramento do progresso do processo

Descrio: O monitoramento em tempo real deve permitir que se verifique o status
de uma instncia do processo em execuo. O status deve incluir a etapa pendente,
o usurio responsvel, a durao das etapas concludas e a durao da etapa
corrente. O monitoramente deve permitir aos process owners a atribuio de
responsabilidades e cobrana quanto ao respeito a prazos de concluso de
atividades. Maior detalhamento pode ser encontrado nos itens II.2.3 (pg. 50) e II.3.3
(pg. 60) deste trabalho.
Aplicao na empresa: Todos os processos inseridos no BPMS tero seu
progresso controlado pelo gerente responsvel (process owner). Esta funcionalidade
permitir aos process owners identificar problemas, atrasos e gargalos, garantindo a
concluso da tarefa conforme programado, ou permitindo o restabelecimento de
prazos e metas com antecedncia. Este monitoramento permitir tambm a medio
do desempenho corrente do processo e dos usurios participantes do mesmo. Alm
dos process owners, os demais participantes do processo podero controlar o
progresso das atividades que desempenham, atravs da identificao das
pendncias para concluso e do tempo consumido at o momento da verificao.
Alm dos processos inseridos no projeto piloto de implantao, os processos
posteriormente adicionados tambm possuiro process owners e tero seu
progresso monitorado. O maior impacto do monitoramento ser verificado nos
processos que trabalham com prazos estreitos: desenvolvimento de produtos,
aquisio de materiais, controle da produo terceirizada e exportao de produtos.
Atores: Gerentes (process owners) e participantes dos processos includos no
BPMS.

Requisito Funcional 6: Anlise do histrico de desempenho do processo

Descrio: Funcionalidade anloga ao monitoramento do progresso, porm
baseada em dados histricos coletados pelo BPMS. Permite a anlise do
desempenho em um perodo de tempo determinado, de forma a identificar pontos de
melhoria, analisar o comportamento de indicadores de desempenho do processo, e
verificar o resultado de modificaes efetuadas. A ferramenta deve fornecer
relatrios padronizados, mas tambm permitir alteraes nos mesmo caso

89
desejvel. As alteraes devem contemplar a incluso de novos parmetros
gerenciveis, e a possibilidade de modificar a estrutura de apresentao do relatrio,
alterando inclusive o formato dos grficos gerados. Maior detalhamento pode ser
encontrado nos itens II.2.3 (pg. 48 e 49) e II.3.3 (pg. 60) deste trabalho.
Aplicao na empresa: Os process owners efetuaro anlises peridicas do
desempenho dos processos sob sua responsabilidade. A partir dos indicadores de
desempenho obtidos, ser possvel estabelecer metas, traar planos de ao, e
analisar os resultados das medidas adotadas. Os indicadores de desempenho e
metas existentes atualmente dizem respeito ao faturamento das lojas (as lojas,
vendedores e supervisores possuem metas de venda por perodo de tempo). O
indicador de desempenho mais importante dos processo internos o lead-time de
processo (global e por etapa).
O monitoramento do desempenho histrico ser aplicado ao grupo inicial de
processos do projeto piloto, e aos demais projetos inseridos no BPMS. Os processos
com maior nmero de execues (executados mais com maior freqncia ou h
mais tempo no sistema) permitiro anlises mais aprofundadas.
Alm dos gerentes e seus respectivos processos, o Departamento de Projetos
reunir as informaes de desempenho dos diversos processos para efetuar suas
anlises de maneira abrangente e sistmica.
Atores: Gerentes e Diretores, Departamento de Projetos

Requisito Funcional 7: Simulao de desempenho de processos

Descrio: Permite que processos modelados sejam testados antes de sua
implantao, fornecendo o comportamento dos indicadores de desempenho do
processo em um ambiente com parmetros estabelecidos pelo usurio. A
funcionalidade deve estar presente em interface grfica, e deve permitir ao usurio
definir quais os indicadores de desempenho e parmetros da simulao. Ver itens
II.2.3 (pg. 49) e II.3.4 (pg. 64) deste trabalho.
Aplicao na empresa: O Departamento de Projetos poder simular o resultado
das alteraes propostas em processos antes de implant-las. O mesmo ser
possvel para processos inteiramente novos. Os resultados destas simulaes sero
parte da prpria justificativa e fundamentao destes projetos.

90
A simulao permitir a anlise do desempenho esperado de um processo aps
incluso no BPMS, e comparao com o desempenho corrente (fora do sistema).
Alm disso, a simulao ser utilizada para prever o desempenho de processos j
inseridos no BPMS em diferentes cenrios, atravs da modificao dos parmetros
de simulao.
Atores: Departamento de Projetos, Gerentes.

Requisito Funcional 8: Ferramentas de desenvolvimento colaborativo de

contedo
Descrio: Esta funcionalidade permite o trabalho conjunto no desenvolvimento de
documentos, favorecendo a troca de opinies e proposio de revises. Deve incluir
fruns de discusso, sistema de troca de mensagens (chat), tags (para associao a
documentos), publicao de documento em rede e edio do mesmo por outros
usurios, e controle de alteraes e de verses. Ver itens II.3.3 (pg. 62) e II.3.4
(pg. 64) deste trabalho.
Aplicao na empresa: O uso desta funcionalidade independe de o usurio fazer
parte de algum dos processos inseridos no sistema. A aplicao inicial contemplar
os departamentos de Produto, Projetos e TI. O Departamento de Produto utilizar a
ferramenta no processo de desenvolvimento de novos produtos, trabalhando em
conjunto com usurios localizados nas filiais internacionais. Os Departamentos de
Projetos e TI foram escolhidos devido ao carter do trabalho por eles desenvolvido,
que exige colaborao e troca constante de opinies. Independentemente da
expanso do nmero de processos no BPMS, o uso das ferramentas colaborativas
ser estendido progressivamente s demais reas administrativas da empresa.
Atualmente a nica forma existente de desenvolvimento colaborativo o
compartilhamento de documentos em pastas de acesso comum, alocadas na
intranet da empresa.
Atores: Departamentos de Produto, Projetos e TI.

Requisito Funcional 9: Gesto de usurios e processos

Descrio: O BPMS deve possuir uma funcionalidade de incluso, excluso e
gerenciamento de usurios e processos do sistema. A funcionalidade deve permitir a

91
criao de diferentes perfis de usurio e de processo, alm da criao de grupos de
usurios e processos.
Aplicao na empresa: Esta funcionalidade ser usada pelo Departamento de TI
para controlar o uso da ferramenta, atendendo as solicitaes dos demais
departamentos quanto ao status dos usurios e processos inseridos no BPMS.
Trata-se de uma funcionalidade bsica, porm importante para o bom uso do
software.
Atores: Departamento de TI.

Portanto, a empresa deve procurar uma soluo de BPMS que atenda a todos os
requisitos funcionais acima estabelecidos. Alguns destes requisitos so comuns
maioria dos BPMS disponveis no mercado, mas mesmo assim deve ser feita uma
verificao minuciosa dos softwares oferecidos antes da aquisio, dada a ampla
variabilidade ainda observada dentre os pacotes que se autodenominam sistemas
de BPM. Se o processo de avaliao dos fornecedores no for feito corretamente,
corre-se o risco de se adquirir uma ferramenta que no atenda as expectativas de
desempenho depositadas no BPMS, devido ausncia de funcionalidades
fundamentais. Existem at mesmo pacotes de Workflow, cujas funcionalidades se
resumem automao do processo, batizados de BPMS apenas por razes
comerciais.

Muitas vezes, os fornecedores adicionam funcionalidades extras a seus sistemas de

BPM, sendo estas bastante diferentes de um programa para outro. Estas
funcionalidades extras, apesar de no estarem includas nos requisitos bsicos,
podem ser utilizadas como critrios de diferenciao e deciso na hora da escolha
do software. Para tanto, deve-se levar em conta a utilidade real das ferramentas
adicionais para a empresa. No caso da empresa estudada, foram definidas algumas
caractersticas desejveis, complementares aos requisitos funcionais:
Possibilidade de acesso ao contedo do BPMS atravs de softwares de
navegao na web (o Internet Explorer o na vegador padro da empresa).
Desta forma, no ser necessrio instalar o software em todos os terminais
de uso. Os usurios podero acessar suas caixas de entrada, concluir

92
tarefas, preencher formulrios e incluir documentos no sistema como se
estivessem acessando uma pgina de internet.
Ferramentas extras de Gerenciamento Eletrnico de Documentos, como
pesquisas por palavra-chave (no ttulo ou no corpo de texto).
Opes extras de monitoramento de progresso de processo. Tais opes
devem permitir que o process owner estabelea limites superiores ou
inferiores para os indicadores do status do processo. Caso estes limites sejam
ultrapassados, deve existir um sistema de notificao automtica. Esta opo
ser especialmente til com o amadurecimento do uso do programa e
presena de um nmero elevado de processos no sistema.
Ferramenta de criao de documentos padronizados. Permite a criao de
formatos padro para emisso e preenchimento de documentos com
caractersticas estruturveis (NF, OPs, Fichas tcnicas, Faturas, emails de
confirmao, Fichas de Controle de Qualidade). Permite ainda que sejam
embutidas regras de negcio para preenchimento automtico de campos do
documento.

Por fim, deve -se ressaltar que, por se tratar de uma aquisio de pacote comercial
de software, e no de um desenvolvimento interno, no foi necessria a definio
detalhada dos casos de uso, atores, e diagramas de relacionamento do programa.
Presume-se que este trabalho tenha sido feito pelas empresas desenvolvedoras dos
aplicativos

de

BPMS.

Desta

forma,

resta

ao

cliente

estabelecer

quais

funcionalidades so indispensveis para o software escolhido. A parametrizao

posterior no caracteriza um processo de desenvolvimento, utilizando-se de
funcionalidades prontas inerentes ao software.

III.2.2 Requisitos no-funcionais

A definio dos requisitos no-funcionais foi feita em conjunto com o Departamento
de TI da empresa, considerando os aspectos crticos para que o software possa
atender corretamente a gama de processos existente. Deve -se ressaltar que esta
definio no est restrita ao grupo inicial de processos selecionados para insero

93
no sistema. Foram consideradas as possibilidades de expanso do uso para outros
processos alm dos originais.

As categorias de requisitos no funcionais seguem a lista de atributos da qualidade

estabelecidos na norma ISO-9126, encontrada em Paula Filho (2003). Os requisitos
levantados so aqueles indispensveis para a aceitao do software (critrios
qualificatrios).

Tabela 9: Requisitos de desempenho do sistema

Requisito
Estticos
Dinmico

Definio

Valor

Nmero de terminais suportados

400

Nmero de usurios simultneos

Nmero de transaes (pico)
(transaes/hora)

140
2000

O nmero de terminais apoiados foi estabelecido a partir do total de funcionrios

que ocupam cargos administrativos na empresa (e que, portanto, esto
potencialmente inseridos em algum dos processos do BPMS). Foi considerada
tambm a expanso prevista deste nmero nos prximos anos. O nmero de
usurios simultneos foi estabelecido a partir do nmero total de lojas prprias (um
usurio por loja), mais 20% do total de terminais instalados. O nmero de
transaes foi determinado pela multiplicao do nmero de usurios (400) pela
freqncia mdia estimada de uso, em transaes por hora (5 transaes/hora).

Tabela 10: Requisitos de funcionalidade do sistema

Requisito
Acurcia

Definio
Correlao entre resultados de
teste padronizado e resultados
obtidos por um mtodo de
referncia

ndice de compatibilidade com

Interoperabilidade
produto.

Valor
No se aplica
100% para o
ERP, sistema
LINX, sistema
de varejo

94
Requisito
Segurana do
acesso

Definio

Valor

ndice de sucesso em testes de

resistncia penetrao.

100%

A acurcia no foi considerada um requisito no-funcional para a ferramenta em

questo. A segurana do acesso foi estabelecida em 100% para os testes de
penetrao, pois o sistema deve trabalhar com chave-digital e em sistema fechado
(Intranet corporativa).

A interoperabilidade precisa ser total com os demais sistemas aos quais o BPMS
estar integrado. Estes sistemas so o ERP (em implantao), o LINX (sistema de
emisso de OPs, controle da produo, e aquisio de materiais) e o sistema de
vendas utilizado no varejo. Atualmente existe uma srie de sistemas legados cujo
uso ser descontinuado com a adoo do ERP, e que por isso no foram
considerados na definio da interoperabilidade requisitada. A integrao aqui
considerada a capacidade do BPMS de acessar, inserir e retirar informaes dos
bancos de dados dos demais sistemas.

A integrao entre sistemas uma das questes mais relevantes para o sucesso da
implantao do BPMS na organizao. Os processos selecionados envolvem inputs
em at trs sistemas legados diferentes (no caso do processo Processamento de
Special Order). O objetivo da empresa eliminar isto, centralizando toda a
informao necessria em um nico formulrio de BPMS, evitando assim
redundncias e perda de tempo. Para tanto, fundamental que esta informao
possa ser distribuda para os bancos de dados dos respectivos sistemas. Mesmo
que a maior parte destes sistemas seja de fato eliminada aps adoo do ERP, a
permanncia do LINX e a possvel permanncia do software de varejo fazem com
que os processos selecionados para incluso no BPMS possuam etapas em mais de
um sistema, tornando a interoperabilidade um requisito no-funcional extremamente
importante.

Tabela 11: Requisitos de confiabilidade do sistema

95
Requisito
Maturidade

Definio
Porcentagem do tempo em
operao sem falhas.

Tolerncia a
falhas

ndice de degradao por falha.

Recuperabilidade

Porcentagem do tempo gasto

para recuperao de falhas

Valor
99.97%
5%
0,02%

Os requisitos de confiabilidade estabelecidos so os mesmos utilizados na

aquisio dos demais sistemas da empresa. A porcentagem do tempo destinada
recuperao de falhas 0,02%, considerando-se que 0,01% do tempo gasto no
diagnstico de falhas. O ndice de degradao por falha rigoroso (apenas 5%),
pois considera processos crticos para a empresa que sero inseridos no BPMS,
como o sistema de cobrana das lojas prprias. Uma falha que comprometa mais do
que 5% do funcionamento do sistema de cobrana das lojas tem impacto direto
sobre o faturamento mensal da empresa, especialmente no caso da marca C, devido
ao seu volume de vendas.

Tabela 12: Requisitos de usabilidade do sistema

Requisito

Definio

Inteligibilidade

Tempo mdio necessrio para

transmisso de conceito lgico,
durante o treinamento.

Apreensibilidade

Tempo mdio necessrio para

que usurio padro seja treinado
no produto.

Produtividade do usurio
(operaes realizadas / hora)
Operacionalidade
Taxas de erros de utilizao
(erros / hora)

Valor
No se aplica

2 horas
No se aplica
No se aplica

Dentre os requisitos de usabilidade, o nico que foi considerado relevante para a

escolha da ferramenta foi a apreensibilidade. A definio do tempo necessrio para
treinamento considera o tempo disponvel para treinamento, a complexidade da
tarefa a ser executada pelo usurio padro, e a experincia atual de treinamento dos
funcionrios nos mdulos do ERP. Assumiu-se que o usurio avanado ter maior
tempo disponvel para treinamento (no caracterizando, assim, uma restrio).

96
Considerou-se tambm que, no caso em questo, o requisito de inteligibilidade
est incluso no valor de apreensibilidade definido.

Requisitos de operacionalidade no so significativos dadas as caractersticas do

software de BPM e a grande variabilidade dos processos que nele sero
executados. Para processos como o desenvolvimento de produtos, por exemplo,
no faz sentido mensurar a produtividade do usurio em operaes realizadas por
hora.

Tabela 13: Requisitos de manutenibilidade do sistema

Requisito

Definio

Valor

Analisabilidade

Tempo mdio para diagnstico de

problemas de alta severidade

5 min

Tempo mdio para resoluo de

Modificabilidade problemas
Tempo mdio para modificao
(insero de novo processo)
Porcentagem de defeitos
Estabilidade
detectados resultantes de
modificaes no sistema
Testabilidade

Esforo associado aos testes de

regresso

20 min
2 dias
5%

No se aplica

A analisabilidade considerou apenas o diagnstico de problemas de alta

severidade. Para problemas de mdia severidade, o valor estabelecido foi 2 horas,
porm, pode-se considerar que isto j est contemplado pelo requisito de alta
severidade.

A modificabilidade foi considerada um requisito especialmente importante para

sistemas BPM, tendo sido desmembrada em dois valores de referncia: tempo
mdio para resoluo de problemas e para implantao de modificaes. O primeiro
valor foi estabelecido a partir do tempo gasto para recuperao de falhas
(previamente determinado), e estimativa de freqncia de ocorrncia de falhas
individuais. O segundo valor foi estimado para a operao de modificao mais
relevante, a insero de novo processo de negcio no sistema.

97

A estabilidade foi definida em 5%, considerando que o sistema, por ser

parametrizvel, estar em constante modificao. Testabilidade no foi considerado
um requisito no-funcional relevante.

Tabela 14: Requisitos de portabilidade do sistema

Requisito
Adaptabilidade
Capacidade
para ser
instalado

Definio
Porcentagem de funes
independentes do ambiente de
uso
Durao estimada da primeira
fase de implantao
Custo estimado da fase de
implantao

Valor
100%
60 dias
R$ 50.000

Conformidade

Frao mdia de implantao das

recomendaes do padro
desejado

100% com
SOX

Capacidade
para substituir

Frao das funes que operam

de forma idntica s funes
correspondentes do produto de
referncia (outro BPMS).

15%

A adaptabilidade foi estabelecida em 100%, devido ao amplo escopo de aplicao

do produto, e ao fato de ele ser completamente parametrizvel. A durao
estimada da fase de implantao considerou apenas o grupo inicial (piloto) de
processos, e foi baseada na durao da implantao dos projetos atuais do
Departamento de TI , na experincia de seus membros em projetos similares, e no
plano de implantao que faz parte desta proposta. O custo estimado de
implantao contempla o tempo gasto pela empresa na transio dos sistemas
antigos para o novo (incluindo treinamentos), e o valor desembolsado com os
consultores do fornecedor da ferramenta que trabalham em conjunto com o
Departamento de TI da empresa nesta etapa. A conformidade deve ser de 100%
com os padres SOX (Sarbanes-Oxley Act) adotados pelo Departamento de TI.

98
Por fim, a capacidade para substituir foi estabelecida em 15%, considerando-se
que as solues de BPMS so extremamente adaptveis, sendo portanto normal
que estas apresentem alto grau de diferenciao e demandem esforos de
implantao especficos. Os 15% contemplam funcionalidades de modelagem e
reconhecimento da BPMN, alm da automao e monitoramento do progresso de
processos. fundamental que processos modelados em um software sejam
exportveis para outro.

Por ocasio da escolha do BPMS, o software deve atender a todas as

especificaes mnimas acima determinadas, ou seja, estes requisitos so critrios
qualificatrios de seleo. Deve -se ressaltar ainda que esta definio de requisitos
no-funcionais til no apenas para selecionar a ferramenta adequada para a
organizao, mas tambm para guiar a realizao de testes durante a implantao,
de modo a verificar se o software atende de fato aos requisitos pr-estabelecidos.

III.2.3 Requisitos contratuais

O objetivo deste tpico definir como a empresa deve regulamentar o processo de
aquisio do software junto ao fornecedor. Para tanto, foram definidos os requisitos
contratuais indispensveis, ou seja, o contedo fundamental do SA (Supplier
Agreement, ou Acordo de Fornecedor). Os requisitos esto divididos em dois
grupos, estando o primeiro grupo associado aquisio propriamente dita do pacote
comercial, e o segundo associado aos processos de implantao e parametrizao
posteriores.

A definio dos requisitos contratuais partiu dos tpicos listados na seo de SAM
(Supplier Agreement Management) do CMMI (Capability Maturity Model Integration),
um modelo de referncia desenvolvido pelo SEI (Software Engineering Institute). A
partir desta lista inicial de tpicos, foi selecionado um grupo de tpicos relevantes
para o caso especfico da aquisio de um BPMS pela empresa. Estes tpicos foram
relacionados ao contexto da empresa e classificados nos grupos previamente
estabelecidos. Por fim, efetuou-se a validao e reviso dos requisitos levantados. O
trabalho foi desempenhado mais uma vez em conjunto com o diretor do

99
Departamento de TI da organizao, que conta com a experincia da negociao
recente do contrato de implantao do ERP e de outros sistemas na empresa.

Inicialmente, necessrio caracterizar o tipo de aquisio que ser feita. A aquisio

do BPMS consiste na compra de uma licena padro de um pacote comercial pronto
(identificada pela sigla COTS, Comercial Of-the-shelf Product). De posse da licena,
o cliente conta com o suporte do fornecedor no processo de parametrizao e
implantao, atravs de consultores que trabalham por determinado perodo na
empresa contratante. Embora o resultado final aps a implantao seja nico,
adaptando-se as especificidades e necessidades de cada organizao que adota o
BPMS, no se pode dizer que se trata de um produto customizado, desenvolvido
especialmente para cada cliente. Isso por que o produto desenvolvido o mesmo
para todos, variando apenas a maneira como a parametrizao feita aps
aquisio da licena.

Definida a forma de aquisio do produto, foram levantados os seguintes requisitos

contratuais:
Definio clara dos custos de licenciamento, implantao, suporte tcnico /
manuteno, e atualizao.
Definio das especificaes do software oferecido.
Estabelecimento do desconto proporcional para compras em larga escala. O
contrato deve incluir o desconto incidente na aquisio inicial e descontos
para posterior ampliao do nmero de licenas. Caso no haja descontos,
isto deve ser explicitado.
Detalhamento da cobertura do contrato de licenciamento, ou seja, quem e
quantos so os usurios autorizados a usar o BPMS. No caso da empresa,
deve incluir licenas para fornecedores (por serem responsveis por tarefas
em processos que sero automatizados), e possibilidade de acesso para
clientes (para visualizao, na forma de pgina web, do status do pedido de
compra e estgio em que se encontra a produo de pea sob encomenda).
Regras de acesso melhorias futuras. O contrato deve estabelecer o direito
(ou no) da empresa contratante a atualizaes no software adquirido, por

100
ocasio da publicao de novas verses. O nmero de atualizaes incluso
no preo de licenciamento inicial deve estar explicitado.
Regras de suporte no local de uso. O contrato deve definir a forma como ser
feito o suporte em caso de comunicao de problema. Para tanto, devem
estar presentes no contrato: o perodo de cobertura de suporte incluso no
preo inicial de aquisio; a definio de que o atendimento ser feito no local
de uso; o prazo mximo para atendimento da solicitao de suporte; e o custo
do suporte que exceda a cobertura do pacote inicial.
Regras para incluso de funcionalidades extras que no esto no produto. O
contrato deve estabelecer a possibilidade (ou no) do desenvolvimento de
funcionalidades extras customizadas para a empresa, caso tal necessidade
exista. Os critrios de determinao do preo cobrado devem estar claros, se
a incluso for permitida.
Regras para manuteno do sistema. Alm das questes de suporte, o
contrato deve contemplar a maneira como a manuteno ser feita. Para
tanto, deve constar no documento: tipos de manuteno contemplados
(apenas corretiva ou tambm preventiva); de quem a responsabilidade pela
manuteno (contratante ou fornecedor); e qual ser o procedimento caso o
produto no seja mais comercializado.
Garantias inclusas. O contrato deve estabelecer se existe alguma forma de
garantia ao usurio do BPMS contra falhas. No caso da empresa estudada,
importante que esteja definido se existiro compensaes financeiras por
perdas causadas diretamente por mal-funcionamento do software.
Identificao das pessoas, tanto do fornecedor quanto da empresa
contratante, que esto autorizadas a fazerem mudanas no contrato (Acordo
de Fornecedor). Deve incluir a identificao de como estas mudanas sero
determinadas, aprovadas, comunicadas e desempenhadas.

Alm dos requisitos contratuais para aquisio, foram levantados alguns requisitos
contratuais relativos s etapas de implantao e parametrizao do BPMS:
Estabelecimento da documentao e servios que devem ser disponibilizados
ao fornecedor. Este item estabelece os dados e suporte necessrios para que

101
os consultores do fornecedor faam a parametrizao, reservando entretanto
empresa o direito de no divulgar informaes confidenciais.
Declarao do trabalho a ser feito, termos e condies, lista de deliverables,
cronograma, oramento, e procedimento de aceitao (validao). Consiste
no detalhamento do projeto de implantao da ferramenta.
Identificao dos procedimentos e padres que devero ser seguidos na fase
de implantao, assim como a forma como ser feito o monitoramento do
trabalho do fornecedor.

O contrato pode ainda incluir uma clusula determinando a obrigatoriedade do

atendimento

dos

requisitos

funcionais

no-funcionais

pr-estabelecidos.

Entretanto, considerou-se que o atendimento destes requisitos configura um critrio

qualificatrio no processo de seleo, e desta forma no precisa estar
regulamentado no Acordo de Fornecedor. Deve -se ressaltar tambm que a definio
dos valores assumidos pelos itens do contrato, como por exemplo o nmero de
atualizaes inclusas no preo de licenciamento, ser feita em negociao com os
fornecedores, dependendo ainda de maior detalhamento das propostas dos
mesmos. Tais valores no representam, porm, critrios qualificatrios de seleo
do pacote de BPMS.

Alm dos requisitos contratuais acima listados, existem alguns cuidados a serem
tomados durante o processo de assinatura do contrato e posteriormente, de forma a
garantir a validade do mesmo. Embora no sejam requisitos, foram estabelecidos os
seguintes procedimentos desejveis:
Certificar-se de que todas as partes do acordo entendem e esto de acordo
com todos os requerimentos colocados, antes que o acordo ou mudanas no
mesmo sejam implantadas.
Efetuar modificaes nos projetos que envolvam o BPMS, caso necessrio,
para que eles estejam alinhados com as condies definidas no Acordo de
Fornecedor.

102
Reavaliar periodicamente o contrato (Acordo de Fornecedor), para certificarse de que ele reflete com acurcia a relao atual cliente -fornecedor, os
riscos existentes, e as condies de mercado.

Assim, os requisitos contratuais levantados neste item so fundamentais para definir

a relao cliente-fornecedor na aquisio do software de BPMS. Foram levantados
os requisitos relativos aquisio em si, instalao (parametrizao), e alguns dos
procedimentos a serem seguidos aps o contrato entrar em vigncia.

Concluindo, de posse dos requisitos funcionais e no-funcionais determinados nos

itens anteriores, somados aos requisitos contratuais, a empresa tem uma viso
detalhada e completa dos requisitos buscados na ferramenta de BPMS, e de como
regulamentar sua relao com o fornecedor do software. Este estudo, em conjunto
com o grupo de processos modelados, guiar a empresa no processo de seleo do
BPMS mais adequado s suas necessidades, dentre as inmeras opes
disponveis em um mercado amplo, porm ainda pouco maduro.

III.3 PLANO DE IMPLANTAO

O propsito deste item fornecer um plano de implantao para o BPMS na
empresa estudada. As etapas anteriores deste trabalho, modelagem de processos e
definio das caractersticas do software, fornecem suporte para a concluso de
fases crticas do projeto, como a seleo do fornecedor e a implantao inicial
(Projeto Piloto). O plano de implantao complementa o estudo, estruturando o uso
do material produzido nos captulos anteriores e possibilitando a aplicao prtica
deste trabalho na empresa.

A elaborao deste plano teve como base a experincia atual da empresa com a
implantao do ERP, e o modelo de ciclo de vida deste tipo de sistema, presente na
fundamentao terica deste trabalho (ver item II.1.4, pg. 34) . Analisando este
modelo e a forma como a implantao em curso foi planejada, foi possvel
estabelecer um paralelo para a implantao de um sistema de BPM, efetuando-se

103
as modificaes necessrias decorrentes das diferenas entre os sistemas. Foi
possvel ainda contar com a experincia de profissionais do Departamento de TI que
j participaram da implantao de BPMS em outras empresas.

Deve-se ressaltar que apesar de o BPMS e o ERP possurem similaridades e

complementarem um ao outro, as diferenas entre eles resultam em especificidades
no plano de implantao, alm de os riscos envolvidos e benefcios esperados
serem diferentes.

O plano de implantao est dividido em quatro partes. Inicialmente, foram

relacionadas as etapas das fases de pr-implantao (deciso e seleo), que j
esto em curso. Em seguida, esto identificadas as etapas da implantao
propriamente dita, que consiste em colocar o sistema em funcionamento na
empresa, e as etapas da utilizao. Cada uma das etapas esta acompanhada de
uma de uma estimativa de tempo de execuo, dos responsveis pela etapa, e dos
possveis riscos identificados. As estimativas e definio dos riscos, incluindo o grau
de severidade e ao a ser tomada, foram feitas a partir da fundamentao terica
do trabalho, do desenvolvimento atual do projeto do ERP na organizao, e das
informaes disponibilizadas pelos fornecedores de BPMS prospectados. As etapas
podem incluir sub etapas ou mais de uma atividade.

Deve-se ressaltar que, paralelamente ao plano de implantao proposto,

fundamental que a empresa promova modificaes em sua estrutura e forma de
gesto, de forma a adotar de fato a Gesto por Processos. O BPMS apenas uma
ferramenta de apoio e potencializao das mudanas promovidas pela Gesto por
Processos. O uso isolado do BPMS em uma organizao que no possui orientao
para processos (estrutura funcional) produz resultados bastante restritos em
comparao com o potencial de melhoria em empresas gerenciadas por processos.
No caso da empresa estudada, a adoo da Gesto por Processos est em curso,
sendo um dos objetivos da alta gerncia (as mudanas ocorrem top-down ). Faz
parte da estratgia definida para a adoo da Gesto por Processos, alm do
BPMS, a aquisio do ERP.

104
As Tabelas 15, 16, 17 e 18 apresentam as quatro partes do projeto de implantao
do sistema.

Tabela 15: Etapas referentes ao processo de deciso

Classificao N
1
2
Deciso
3
4

Etapa
Deciso de implementar o
BPMS
Definio macro do escopo
do projeto
Definio da equipe do
projeto
Comunicao aos
participantes

Responsveis
Durao
Alta gerncia,
concluda
Depto. TI
Depto. TI

concluda

Depto. TI

concluda

Alta gerncia,
Depto. TI

concluda

Todas as etapas da fase de deciso j foram completadas. A participao da alta

gerncia foi determinante para a aprovao do projeto e envolvimento das diversas
reas de negcio da organizao. A equipe de projeto estabelecida conta com
membros do Departamento de TI e do Departamento de Projetos, incluindo o autor
deste trabalho.

Tabela 16: Etapas referentes seleo da ferramenta

Classificao N
5
Processos

6
7

8
Fornecedor
9

Etapa
Identificao dos processos
candidatos incluso no BPMS
Seleo dos processos para
primeira fase de implantao
(projeto piloto)
Mapeamento e detalhamento dos
processos selecionados
Levantamento dos requisitos da
ferramenta: funcionais, no
funcionais, contratuais (critrios
qualificatrios)
Levantamento dos critrios de
escolha (critrios classificatrios)

10 Seleo do fornecedor

Responsveis Durao
Depto. TI e
concluda
Projetos
Depto. TI e
Projetos

concluda

Depto.
Projetos

concluda

Depto. TI e
Projetos

concluda

Depto. TI

5 dias

Depto. TI e
Projetos

60 dias

105
O processo de seleo do sistema de BPM para a empresa est parcialmente
concludo. Os processos a serem beneficiados na primeira fase do projeto foram
selecionados, mapeados e detalhados (ver item III.1, pg. 70). De posse desta
definio, foi efetuado o levantamento dos requisitos da ferramenta, que consistem
nos critrios qualificatrios de seleo (ver item III.2, pg. 78). Resta ao
Departamento de TI definir os critrios de escolha, de maneira similar ao que foi feito
por ocasio da aquisio do ERP. A escolha ser feita a partir de um grupo de
fornecedores pr-selecionados por atenderem aos requisitos identificados. Estes
fornecedores devero elaborar suas propostas e apresent-las, incluindo no
apenas os aspectos relativos ao software em si, mas tambm ao processo de
implantao e parametrizao. A deciso ser tomada em conjunto pela equipe
responsvel pelo projeto de aquisio do BPMS (ou seja, ter participao dos
Departamentos de TI e Projetos).

Analisando-se os riscos da fase de seleo do fornecedor do software, detectou-se o

risco do surgimento de problemas e deficincias do software apenas durante a
implantao ou durante o uso continuado. Este risco est detalhado Figura 16.

RISCO: DETECO DE PROBLEMAS APS SELEO

Prob
80 - 99%

Descrio:

60 - 79 %

Deteco dos defeitos e falhas do software adquirido

apenas durante a implantao ou uso continuado.

40 - 59 %
20 - 39 %

Plano de Contingncia:
Exigir do fornecedor contratado a correo dos
problemas ou fornecimento de atualizao.

0 - 19 %
1

3
Impacto

Risco:
Baixo
Mdio
Alto

Plano de Mitigao:
Estabelecer garantias no Acordo de Fornecedor
(contrato). Atentar para o preenchimento dos requisitos
no-funcionais. Realizar testes antes do fechamento do
contrato. Entrar em contato com outras empresas
clientes do fornecedor.
Ao:

Mitigar

106
Figura 16: Diagrama de risco da fase de seleo do BPMS.

Existem outros riscos relacionados fase de seleo, entretanto a possibilidade de

deteco de problemas apenas aps a seleo e implantao do sistema foi
considerado o mais relevante.

Tabela 17: Etapas referentes implantao

Classificao N
11

Planejamento

12

13
14
15
15a

Execuo

Etapa
Definio da equipe de
implantao
Anlise do ambiente de
implantao (estrutura de
hardware, de comunicao,
de informao,
organizacional, reas de
negcio)
Estabelecimento do
cronograma de atividades
Instalao do software e
mudanas de hardware
necessrias
Primeira fase (Projeto Piloto):
Confirmao dos processos e
atores para incluso no
sistema

Responsveis Durao
Depto. TI,
5 dias
Consultores

Consultores

30 dias

Consultores.
Depto. TI

5 dias

Consultores,
Depto. TI

20 dias

Depto. TI e
Projetos

Consultores,
15b Comunicao aos envolvidos Depto. TI e
Projetos
Modelagem dos processos
Depto. de
15c
(BPMN)
Projetos
Insero dos processos no
BPMS (inclui integrao com
Depto. TI,
15d sistemas, criao de
Consultores
formulrios, e incluso de
regras de negcio)
15e Testes
Depto. TI
Consultores,
15f Treinamento dos usurios
Depto. TI e
Projetos
Entrada em operao
15g
Usurios
(transio)

3 dias

3 dias
concluda

20 dias

5 dias
10 dias
10 dias

107
A etapa de implantao tem seu incio condicionado ao trmino da etapa de seleo,
e ao trmino da implantao do ERP na organizao. A responsabilidade pela
implantao do Departamento de TI, de forma que a atuao dos demais
departamentos, incluindo Projetos, visa apenas dar suporte a este processo. A
participao dos consultores da empresa contratada para fornecer o software
fundamental, principalmente nas atividades de parametrizao do sistema, de
apresentao e de treinamento dos usurios finais. Portanto, a equipe de
implantao composta por membros do Departamento de TI e consultores do
fornecedor do sistema, que trabalham no local de aplicao.

A etapa de execuo tem como objetivo iniciar o Projeto Piloto de adoo do BPMS,
ou seja, por em funcionamento um grupo reduzido de processos integrado e
monitorado atravs da ferramenta. Uma das sub etapas da implantao, a
modelagem dos processos, j foi completada (ver item III.1.2 deste trabalho). Assim,
por ocasio da insero dos processos no BPMS, bastar que o sistema promova a
converso da linguagem de modelagem BPMN para a linguagem de execuo
(cdigo), conhecida como BPEL (Business Process Execution Language). Existem
ainda outras atividades necessrias para a insero de um processo no sistema:
criao dos formulrios, incluso de regras de negcio, integrao com demais
sistemas, e incluso dos usurios do processo. A durao estimada para os testes
assume que estes sero bem sucedidos, ou seja, em caso de falha, esta atividade
pode consumir mais do que cinco dias.

Por fim, considerou-se a necessidade de um perodo de transio quando os

processos entrarem em operao no BPMS. Durante este perodo, a possibilidade
de execuo dos processos fora do sistema ser mantida, de modo a prevenir que
problemas ou falhas comprometam por total as operaes da empresa. Aps este
perodo, a execuo dos processos inseridos na ferramenta dever obrigatoriamente
ser feita na mesma.

Os principais riscos identificados na fase de implantao do sistema de BPM esto

representados nas Figuras 17 e 18.

108
RISCO: IMPOSSIBILIDADE DE INTEGRAO COM SISTEMA LEGADO
Prob
80 - 99%

Descrio:

60 - 79 %

Impossibilidade total ou parcial de integrar o BPMS com

um dos sistemas legados da empresa.

40 - 59 %
20 - 39 %

0 - 19 %
1

3
Impacto

Plano de Contingncia:
Verificar possibilidade de substituir sistema no
integrvel.
Plano de Mitigao:
Testar compatibilidade do BPMS com os principais
sistemas legados antes da aquisio. Antes de implantar
novos sistemas, proceder verificao de
compatibilidade.

Risco:
Baixo
Mdio
Alto

Ao:

Evitar

Figura 17: Diagrama do risco de dificuldades de integrao, relativo fase de

implantao.

109
RISCO: RESISTNCIA MUDANA POR PARTE DOS ENVOLVIDOS NOS PROCESSOS
Prob
80 - 99%

Descrio:

60 - 79 %

O BPMS, por representar mudanas e maior controle

sobre os processos de negcio, pode enfrentar
resistncias por parte dos atores dos processos.

40 - 59 %
20 - 39 %

Plano de Contingncia:
Analisar queixas e esclarecer os benefcios dos processos
integrados para o usurio final.

0 - 19 %
1

3
Impacto

Risco:
Baixo
Mdio
Alto

Plano de Mitigao:
Treinamento e envolvimento das reas da empresa no
projeto de adoo do BPMS. Comunicao dos
benefcios esperados e considerao das sugestes do
usurio final. Seleo de processos cujos atores possuam
disposio em participar.
Ao:

Mitigar

Figura 18: Diagrama do risco de enfrentamento de resistncias internas, relativo

fase de implantao.

Desta forma, os riscos de maior importncia durante a fase de implantao foram a

impossibilidade de integrao com algum sistema legado, e a manifestao de
resistncia mudana por parte dos envolvidos. A probabilidade de ocorrncia deste
ltimo foi considerada alta, principalmente por se tratar de um problema recorrente
na empresa estudada.

Tabela 18: Etapas referentes Utilizao

Classificao N
Utilizao

16

Etapa
Avaliao e correo de
problemas

Responsveis
Gerentes,
Usurios, Depto.
TI

Melhoria (Novas
Gerentes,
necessidades, conhecimentos
17
Usurios, Depto.
acumulados, parmetros
TI
conhecidos)

Durao
-

110
Classificao N

Etapa

Responsveis
Depto. TI,
Expanso (Fases posteriores,
18
Projetos,
incluso de outros processos)
Gerentes
Treinamento para uso de
Consultores,
19 funcionalidades avanadas
Depto. TI
20 Validao junto ao fornecedor Depto. TI

Durao
-

A etapa de utilizao compreende o uso aps a implantao. Embora esta etapa no

esteja inclusa no plano inicial de implantao, que tem seu trmino aps entrada em
operao do grupo inicial de processos no sistema, a descrio das atividades til
para o entendimento do ciclo de vida do BPMS e dos procedimentos a serem
adotados para maximizar sua utilidade.

As atividades acima descritas no possuem relao de interdependncia

cronolgica, ou seja, elas podem acontecer simultaneamente. As duraes so
amplamente variveis e por isso no foi efetuada uma estimativa. As atividades de
avaliao, melhoria e expanso remetem novamente a fase de implantao, uma
vez que os novos processos inclusos ou as modificaes operadas implicam na
execuo das atividades listadas para esta fase. Pode-se dizer que a primeira
implantao a primeira fase da adoo do BPMS pela organizao, sendo as
expanses subseqentes fases complementares que culminam na insero da
maior parte dos processos de negcio no sistema.

As Figuras 19 e 20 apresentam os riscos identificados na etapa de utilizao.

111
RISCO: PERDA DE APOIO DA ALTA GERNCIA
Prob
80 - 99%

Descrio:

40 - 59 %

A falta de apoio da alta gerncia pode prejudicar a

expanso do uso do sistema ou comprometer o sucesso
do gerenciamento dos processos j inseridos.

20 - 39 %

Plano de Contingncia:

60 - 79 %

0 - 19 %
1

3
Impacto

Risco:
Baixo
Mdio
Alto

Levantar motivos da perda de apoio . Apresentar

resultados benficos do uso do software (se disponveis).
4

5
Plano de Mitigao:
Manter a alta gerncia informada do progresso do
projeto e dos beneficios por este gerado. Envolver a alta
gerncia no projeto, solicitando sugestes e buscando
auxilio na tomada de decises.
Ao:

Evitar

Figura 19: Diagrama de risco de perda do apoio da alta gerncia, relativo fase de
utilizao.

112
RISCO: UTILIZAO INADEQUADA PELO USURIO FINAL
Prob
80 - 99%

Descrio:

60 - 79 %

Percepo de que o sistema complicado demais,

gerando falhas e uso incorreto do mesmo.

40 - 59 %
20 - 39 %

Plano de Contingncia:

0 - 19 %

Treinamento pontual para usurios com maiores

dificuldades. Deteco e correo de erros.
1

Impacto

Plano de Mitigao:
Selecionar sistema de fcil domnio, que seja claro e
compreensvel. Treinamento inicial adequado.

Risco:
Baixo
Mdio
Alto

Ao:

Mitigar

Figura 20: Diagrama de risco de utilizao inadequada pelo usurio final, relativo a
fase de utilizao.

Assim, todos os riscos levantados para as respectivas fases devem receber ateno,
de forma a serem evitados, mitigados, ou para que possuam um plano de
contingncia adequado. Dado o impacto da degradao ou total paralisao dos
processos a serem inseridos inicialmente no sistema, fundamental que a gesto de
riscos seja eficiente, garantindo que a ferramenta mantenha sua credibilidade e
traga os benefcios esperados para a organizao.

Portanto, o plano de implantao estabelecido deve ser seguido pela empresa para
a adoo bem sucedida do sistema de BPM. Modificaes podem ser efetuadas
com o desenvolvimento posterior do projeto, medida que novas informaes sejam
adicionadas e novas necessidades sejam identificadas. Espera-se que o fornecedor
selecionado contribua para o detalhamento das etapas envolvidas em cada fase e
aumento da preciso das estimativas de durao, bem como sugesto de eventuais
atividades

no

contempladas,

mas

julgadas

relevantes.

atribuio

de

113
responsabilidades tambm pode sofrer modificaes dependendo da disponibilidade
das reas e seus membros durante o perodo de implantao. Apesar disto, o plano
proposto deve prover a estrutura para o projeto de implantao da ferramenta na
empresa, alm de permitir a compreenso do ciclo de vida do BPMS.

III.4 RESUMO DOS RESULTADOS

Este item consiste de um resumo dos resultados obtidos neste captulo. Trata-se de
uma descrio sucinta da proposta elaborada a partir do estudo realizado.

Inicialmente, foram selecionados cinco processos de negcio da empresa para

serem inseridos no sistema na primeira fase da implantao. Estes processos
apresentam graus de complexidade variveis, de modo a permitir um uso inicial
abrangente do software. Os processos selecionados foram: Processamento de
Special Orders (complexidade simples); Envio de matria prima para produo
terceirizada, Recebimento de devoluo de loja prpria (complexidade mdia);
Desenvolvimento de produtos, Produo interna (complexidade alta). Os processos
foram ento modelados atravs da linguagem padro dos sistemas de BPM, a
BPMN (Business Process Modeling Notation).

A segunda parte da proposta a definio dos requisitos da ferramenta, para dar

suporte ao processo de aquisio da mesma. Os requisitos foram divididos em trs
categorias: funcionais, no funcionais, e contratuais. Os requisitos funcionais foram
estabelecidos a partir das necessidades da empresa e da fundamentao terica do
estudo. So eles: Automao de Processos de Negcio (Workflow); Modelagem ou
edio de processos; Gerenciamento Eletrnico de Documentos (GED); Criao de
formulrios para coleta de dados; Monitoramento do progresso do processo; Anlise
do histrico de desempenho do processo; Simulao de desempenho de processos;
Ferramentas de desenvolvimento colaborativo de contedo; Gesto de usurios e
processos. Os requisitos no funcionais englobam requisitos de desempenho,
funcionalidade, confiabilidade, usabilidade, manutenibilidade e portabilidade. Por fim,
os requisitos contratuais definem os itens que devem estar presentes no Acordo de

114
Fornecedor por ocasio da aquisio do sistema de BPM. Foram levantados ainda
caractersticas da ferramenta que, embora no configurem requisitos, so
consideradas desejveis.

A parte final da proposta o plano de implantao. Foram estabelecidas quatro

fases de implantao: deciso, seleo da ferramenta, implantao e utilizao.
Cada fase foi desdobrada em uma seqncia de etapas, associadas ao respectivo
responsvel

pela

execuo

previso

de

durao.

Algumas

etapas,

principalmente nas duas fases iniciais, j foram concludas, incluindo as atividades

desenvolvidas neste trabalho. Para cada fase, foram identificados os riscos mais
significativos envolvidos: na fase de seleo da ferramenta, o risco de deteco de
problemas aps a seleo; na fase de implantao, riscos de impossibilidade de
integrao dos sistemas e resistncia a mudanas na organizao; e na fase de
utilizao, os riscos de perda de apoio da alta gerncia e utilizao incorreta pelo
usurio final. A fase de deciso j est concluda.

115

IV CONCLUSO

A principal contribuio deste trabalho para a empresa onde o estudo foi realizado
a concluso de trs atividades necessrias para adoo de um sistema de BPMS: a
modelagem dos processos, a definio dos requisitos da ferramenta, e a criao de
um plano de implantao. Desta forma, a organizao tem clareza a respeito dos
prximos passos a serem seguidos e o que considerar em cada etapa do projeto. A
execuo destas atividades foi realizada seguindo metodologia fundamentada no
referencial

terico

estabelecido.

Outra

contribuio

do

estudo

fornecer

embasamento terico ao projeto, permitindo melhor entendimento acerca do tema

por parte dos membros da equipe, e garantindo desta forma o aproveitamento pleno
das funcionalidades do sistema. O referencial terico levantado define o papel do
BPMS no processo de adoo da Gesto por Processos, que o objetivo final a ser
alcanado pela empresa.

Do ponto de vista acadmico, este estudo identifica os desafios enfrentados no

somente para adoo do sistema de BPMS, mas tambm da prpria Gesto por
Processos, por parte de organizaes de mdio porte no cenrio brasileiro. O
trabalho elucida como o BPMS e a Gesto por Processos podem ser utilizados como
ferramentas competitivas, mesmo em empresas cuja estrutura organizacional
inicialmente observada fortemente funcional. Em especial, o estudo demonstra a
aplicabilidade da ferramenta no setor txtil, um setor onde a competitividade das
organizaes tem importncia vital em face da intensa concorrncia em escala
global observada atualmente. Alm disso, o fato de o projeto de adoo do BPMS
estar integrado a implantao do ERP explicita a relao entre os dois sistemas, a
maneira como estes interagem, e a contribuio conjunta para a mudana para uma
estrutura de Gesto por Processos. Por fim, este trabalho fornece uma metodologia
para implantao do BPMS que pode ser replicada em outras organizaes que
precisem gerenciar seus processos. As atividades desempenhadas servem como
exemplo prtico de aplicao, definindo como proceder para selecionar os
processos, como empregar a linguagem BPMN para modelagem dos mesmos, como

116
definir os requisitos do sistema, e como elaborar um plano de implantao para a
ferramenta.

As informaes reunidas no referencial terico, somadas aos resultados produzidos

pelo trabalho, contribuem para o desenvolvimento do estudo dos sistemas de BPM,
o que importante devido atualidade do tema, dado o surgimento recente destes
sistemas, e ao interesse despertado pelo mesmo na comunidade empresarial e
acadmica.

Da

perspectiva

do

aluno,

primeira

contribuio

deste

trabalho

foi

desenvolvimento da capacidade de an lise sistmica de organizaes e seus

processos. Outra contribuio foi a compreenso e exemplificao do uso de
ferramentas modernas de gesto, em especial, da Gesto por Processos, e do papel
da TI na modificao de estruturas organizacionais. O estudo permitiu ao aluno obter
conhecimento detalhado acerca de sistemas de BPM e de como efetuar sua
implantao. Foi possvel ainda empregar conhecimentos adquiridos durante o curso
de Engenharia de Produo, principalmente nas disciplinas Sistema de Informao I,
Automao e Controle, Gesto da Qualidade de Produtos e Processos, Gesto da
Tecnologia da Informao, e Gesto de Projetos. Concluindo, este trabalho
contribuiu para o desenvolvimento de habilidades de pesquisa, identificao de
problemas, formulao de idias e propostas, emprego de metodologia na soluo
de problemas, e apresentao dos resultados obtidos.

Finalmente, prope-se a continuidade do trabalho na empresa estudada. Uma

proposta de estudo complementar consiste na execuo das demais atividades da
implantao do BPMS que no foram includas neste projeto, em especial, a seleo
do fornecedor do software. Para tanto, pode-se elaborar uma proposta de
metodologia para o processo seletivo e aplic-la, estabelecendo-se os critrios de
seleo e utilizando-se de requisitos similares aos definidos no presente trabalho.
Outra proposta de estudo complementar a anlise do impacto da implantao do
sistema, atravs do estabelecimento de indicadores de desempenho de processos e
medio dos mesmos antes e depois do gerenciamento atravs do BPMS. Por fim,
prope-se o desenvolvimento de trabalhos similares em organizaes que atuem em

117
diferentes segmentos da indstria, utilizando-se a metodologia aplicada neste
trabalho, ou promovendo modificaes e melhorias na mesma.

118

REFERNCIAS BIBLIOGRAFICAS

APPIAN SOLUTIONS. Apresenta os servios e produtos da empresa Appian.

Disponvel em: <http://www.appian.com/promo/tour.jsp>. Acesso em: 26 jul. 2007.
ARMISTEAD, C.; Principles of business process management. Managing Service
Quality, v.6, n.6, p.48-52, 1996.
BEHESHTI, H.M. What managers should know about ERP/ERP II. Management
Research News, v.29, n.4, p. 184 193, 2006.
CORRA, H.L. Planejamento, programao e controle da produo: MRP II / ERP:
conceitos, uso e implementao. So Paulo, Atlas, 1997.
DAVENPORT, T.H. Need radical innovation and continuous improvement? Integrate
process reengineering and TQM. Planning Review, v. 21, n. 3, p. 9-12, May/Jun.
1993.
DAVENPORT, T.H. Process innovation: reengineering work through information
technology. Harvard Business School Press, 1993.
DAVENPORT, T.H. Putting the enterprise into the enterprise system. Boston,
Harvard Business Review, v.76, n.4, p.121(11) Jul/Ago. 1998.
FEIG, N. BPM: beyond workflow: banks are using business process management to
improve the customer experience. Bank Systems + Technology, n.44, v.7, p.32-36,
Jul. 2007.
GORE, E.W. Organizational culture, TQM, and business process reengineering: An
empirical comparison. Team Performance Management, v. 5, n. 5, p. 164-170, 1999.
HAMMER, M. Reengineering work: dont automate, obliterate. Harvard Business
Review, v. 68, n. 4, p. 104-112, Jul/Aug. 1990.
HAMMER, M.; CHAMPY, J. Reengenharia: revolucionando a empresa em funo
dos clientes, da concorrncia e das grandes mudanas da gerncia. Rio de Janeiro,
Campus, 1994.
HUANG, S.; CHANG, I.; LI, S.; LIN, M. Assessing risk in ERP projects: identify and
prioritize the factors. Industrial Management & Data Systems, v.104, n.8, p. 681
688, 2004.

119
LAURINDO, F.J.B. Gesto integrada de processos e da tecnologia da informao.
Captulo 5, p. 68 97. So Paulo, Atlas, 2006. (Coordenadores: LAURINDO, F.J.B.;
ROTONDARO, R.G.)
LAURINDO, F.J.B.; ROTONDARO, R.G. Gesto integrada de processos e da
tecnologia da informao. Captulo 1, p. 1 13. So Paulo, Atlas, 2006.
(Coordenadores: LAURINDO, F.J.B.; ROTONDARO, R.G.)
LEE, R.G.; DALE, B.G. Business process management: a review and evaluation.
Business Process Management Journal, v.4, n.3, p.214-225, 1998.
MARTIN, J. Engenharia da informao: introduo. Rio de Janeiro, Campus, 1991.
NAH, F.F.; LAU, J.L.; KUANG, J. Critical factors for successful implementation of
enterprise systems. Business Process Management Journal, v.7, n.3, p. 285 296,
2001.
NETTO, C.A. Gesto integrada de processos e da tecnologia da informao.
Captulo 2, p. 14 37. So Paulo, Atlas, 2006. (Coordenadores: LAURINDO, F.J.B.;
ROTONDARO, R.G.)
OMG. Object Management Group. Pgina do consrcio internacional sem fins
lucrativos de empresas de computao. Disponvel em: <http://www.omg.org/>.
Acesso em: 20 ago. 2007.
PAULA FILHO, W.P. Engenharia de software: fundamentos, mtodos e padres. Rio
de Janeiro, LTC, 2003.
PAYNE, W. The time for ERP? Work Study, v.51, n.2, p 91 93, 2002.
PESSA, M.S.P.; STORCH, S. Gesto integrada de processos e da tecnologia da
informao. Captulo 10, p. 190 218. So Paulo, Atlas, 2006. (Coordenadores:
LAURINDO, F.J.B.; ROTONDARO, R.G.)
PRITCHARD, J.; ARMISTEAD, C. Business process management lessons from
European business. Business Process Management Journal, v.5, n.1, p.10-35, 1999.
REIJERS, H.A. Implementing BPM systems: the role of process orientation. Business
Process Management Journal, v.12, n.4, p.389 409, 2006.
REIJERS, H.A.; HEUSINKVELD, S. Business process management: attempted
concepticide? Proceedings of the 14th Information Resources Management
Conference, IDEA Group, Hershey, p. 128-31, 2004.

120
ROTONDARO, R.G. Gerenciamento por processos. So Paulo, EPUSP/FCAV,
1998. (Apostila do Curso Planejamento e Organizao da Qualidade)
SALERNO, M. S. Projeto de organizaes integradas e flexveis: processos, grupos
e gesto democrtica via espaos de comunicao-negociao. So Paulo, Atlas,
1999.
SOFTWARE ENGINEERING INSTITUTE . CMMI for Development (CMMI-DEV)
Version 1.2 (CMU/SEI-2006-TR-008). Pittsburgh, PA, Software Engineering Institute
- Carnegie Mellon University, Aug 2006.
SHAW, D.R. et al. Elements of a business process management system: theory and
practice. Business Process Management Journal, v.13, n.1, p. 91-107, 2007.
SILVER, B. BPMS watch: understanding and evaluating BPM suites. BPM Institute,
Jul 2007. Disponvel em: <http://www.bpmins titute.org/articles/article/article/bpmswatch-understanding-and-evaluating-bpm-suites.html>. Acesso em: 13 ago. 2007.
SMITH, H.; FINGAR, P. Workflow is Just a Pi Process. Computer Sciences
Corporation,
Hampshire,
EUA,
2003.
Disponvel
em:
<http://www.bpm3.com/picalculus>. Acesso em: 20 ago. 2007.
SOMMERVILLE, I. Engenharia de software. So Paulo, Addison Wesley, 2003.
SOUZA, C.A.; ZWICKER, R. Sistemas ERP no Brasil: teoria e casos. Captulos 2 e
3, p. 63 104. So Paulo, Atlas, 2003. (Organizadores: SOUZA, C.A.; SACCOL,
A.Z.)
TREAD, M. What is BPM anyway? BPM Institute, Dec 2006. Disponvel em:
<http://www.bpminstitute.org/articles/article/article/what-is-bpm-anyway.html>.
Acesso em: 20 ago. 2007.
ZAIRI, M.; Business process management: a boundaryless approach to modern
competitiveness. Business Process Management Journal, v.3, n.1, p.64-80, 1997.
ZAIRI, M.; SINCLAIR, D. Business process re-engineering and process
management: a survey of current practice and future trends in integrated
management. Management Decision, v.33, n.3, p.3-16, 1995.

121

APNDICE A DESCRIO DA NOTAO UTILIZADA PARA

MODELAGEM DE PROCESSOS

BUSINESS PROCESS MODELING NOTATION (BPMN)

Elementos de Diagrama

Objetos de Fluxo

Conectores

Artefatos

Raias

Atividades

Fluxo sequencial

Objeto de informao

Campo

Eventos

Fluxo de mensagem

Anotao

Raias (no campo)

Gateways

Associao

Grupo

Atividades

Tarefa

Eventos

Sub-Processo

Tarefa em "loop"

122

Inicial

Intermedirio

Final

Nenhum

Erro

Link

Mensagem

Compensao

Mltiplo

Timer

Regra

Terminar

Gateways

Exclusivo

Inclusivo

Por informao

Por evento

Complexo

Paralelo

Conectores (complemento)

Fluxo condicionado

Fluxo padro

Para regras detalhadas de uso, favor consultar: http://www.bpmn.org