analise e modelagem de processos de negocios para a definicao de requisitos de um sistema de informacao

Prévia do material em texto

FERNANDO ALBUQUERQUE KALIL 
ANÁLISE E MODELAGEM DE PROCESSOS DE NEGÓCIOS PARA A 
DEFINIÇÃO DE REQUISITOS DE UM SISTEMA DE INFORMAÇÃO 
Trabalho de Formatura apresentado à Escola 
Politécnica da Universidade de São Paulo para 
obtenção do Diploma de Engenheiro de 
Produção 
 
 
São Paulo 
2010 
 
 
FERNANDO ALBUQUERQUE KALIL 
ANÁLISE E MODELAGEM DE PROCESSOS DE NEGÓCIOS PARA A 
DEFINIÇÃO DE REQUISITOS DE UM SISTEMA DE INFORMAÇÃO 
Trabalho de Formatura apresentado à Escola 
Politécnica da Universidade de São Paulo para 
obtenção do Diploma de Engenheiro de 
Produção 
 
Orientador: 
Prof. Dr. Mauro Spínola 
São Paulo 
2010 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
FICHA CATALOGRÁFICA 
 
 
 
 
 
 
 
Kalil, Fernando Albuquerque 
Análise e modelagem de processos de negócio para a defi- 
nição de requisitos de um sistema de informação / F.A. Kalil. -- 
São Paulo, 2010. 
 88p. 
 
Trabalho de Formatura - Escola Politécnica da Universidade 
de São Paulo. Departamento de Engenharia de Produção. 
 
1.Gestão por processos (Modelagem) 2.Sistema de informa- 
ção 3.Engenharia de requisitos I.Universidade de São Paulo. 
Escola Politécnica. Departamento de Engenharia de Produção 
II.t. 
 
 
DEDICATÓRIA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Ao meu avô Maneca, 
Que nos deixou recentemente, 
Mas que sempre será um grande exemplo para mim. 
 
 
 
 
AGRADECIMENTOS 
 
Agradeço, em primeiro lugar, ao meu pai Jorge, à minha mãe Liana e à minha irmã 
Emmanuelle por todo o apoio e carinho em todas as etapas da minha formação e da minha 
vida. 
Ao meu orientador, Prof. Dr. Mauro Spínola pelo estímulo, orientação e compreensão 
na realização deste trabalho. 
Ao Aymeric Voisin, responsável pelo meu treinamento na empresa onde foi realizado 
o estudo, pela disposição para responder todas as minhas perguntas, muitas vezes numerosas. 
Ao Antoine Decitre, um dos acionistas fundadores da empresa e responsável por 
minha contratação, por ter me oferecido um trabalho rico em ensinamentos. 
A todos meus colegas de trabalho no Brasil que em algum momento ou outro 
dedicaram tempo para me responder questões, me ajudar com o estudo e me ensinar o que 
fosse necessário. O ambiente de trabalho era muito agradável e foi um prazer trabalhar com 
todos. 
 
 
 
RESUMO 
 
O setor energético brasileiro tem desfrutado de significativo desenvolvimento ao longo dos 
últimos anos. Neste contexto, uma jovem empresa francesa se dedica, desde 2006, ao 
desenvolvimento de projetos de geração de energia no Brasil. Saldos incoerentes nos 
demonstrativos financeiros da empresa, pagamentos realizados em duplicidade e dificuldade 
de obtenção de informações financeiras históricas evidenciam as deficiências dos processos 
internos de pagamento e contabilização. O presente trabalho tem como objetivo analisar os 
processos financeiros desta empresa com o intuito de modelar novos processos e definir os 
requisitos do sistema de informação que servirá de suporte aos novos processos. Para alcançar 
este objetivo, foi feita uma pesquisa bibliográfica sobre temas relacionados a processos de 
negócio e sistemas de informação e as informações foram levantadas durante o período de 
mais de um ano em que o autor estagiou na empresa. Os novos processos foram modelados 
utilizando a notação BPMN e foram especificados os requisitos do sistema BPM a ser 
implementado como parte da solução do problema. 
 
Palavras-chave: Processos de negócio, Modelagem de processos, Sistemas de 
Informação, Especificação de requisitos. 
 
 
ABSTRACT 
 
The Brazilian energy sector has been under significant development over the last years. In this 
context, a young French company has been dedicated to develop power generation projects in 
Brazil since 2006. Inconsistency in the company’s financial statements, payments made in 
duplicate and the difficulty of obtaining historical financial information are evidences of the 
deficiencies of the company’s payment and accounting processes. This paper intends to 
examine the current financial processes of the company in order to model new ones and 
define the requirements of the information system that will support this change. To achieve 
this objective, a literature research on topics related to business processes and information 
systems was made and information was raised during the period of more than a year in which 
the author worked at the company. The new processes were modeled using the BPMN 
notation and the requirements of a BPM system were defined. 
 
Keywords: Business Process, Process Modeling, Information Systems, Software 
Requirements Specification. 
 
 
LISTA DE ILUSTRAÇÕES 
 
Figura 1 – Presença da Velcan no mundo ................................................................................ 22 
Figura 2 – Organização societária da Velcan no Brasil............................................................ 23 
Figura 3 – Fotos da PCH Rodeio Bonito. ................................................................................. 26 
Figura 4 – Projetos da Velcan no Brasil ................................................................................... 27 
Figura 5 – Estrutura funcional versus visão por processos ...................................................... 34 
Figura 6 – Ciclo de vida clássico .............................................................................................. 39 
Figura 7 – Aplicação de ferramentas de quarta geração ........................................................... 41 
Figura 8 – Etapas de desenvolvimento do trabalho .................................................................. 44 
Figura 9 – Representação de FEPSC ........................................................................................ 45 
Figura 10 – Swimlanes do BPD ............................................................................................... 51 
Figura 11 – Organograma da Velcan em São Paulo ................................................................. 56 
Figura 12 – Funcionários em canteiros de obras ...................................................................... 57 
Figura 13 – Processo atual para pagamento de serviços .......................................................... 65 
Figura 14 – Processo atual de compra e pagamento de bens .................................................... 66 
Figura 15 – Processo 1 – Solicitação de compra ou contratação de serviço ............................ 70 
Figura 16 – Processo 2 – Aprovação e pagamento de serviços baseados em contratos ........... 71 
Figura 17 – Processo 3 - Aprovação e pagamento de serviços – compromissos mensais ....... 72 
Figura 18 – Processo 4 - Solicitação de viagem e/ou adiantamento ........................................ 73 
Figura 19 – Processo 5 – Relatório de despesas ....................................................................... 75 
Figura 20 – Processo 6 – Pagamento ........................................................................................ 76 
 
 
 
LISTA DE QUADROS 
 
Quadro 1 – Evolução do papel da TI ao longo do tempo ......................................................... 36 
Quadro 2 – Impacto da TI sobre a reengenharia de processos ................................................. 36 
Quadro 3 – Modelos de ciclo de vida de softwares .................................................................. 40 
Quadro 4 – Sequência lógica da elaboração do FEPSC ...........................................................45 
Quadro 5 – Técnicas de levantamento de processos ................................................................ 46 
Quadro 6 – Elementos básicos do BPMN ................................................................................ 49 
Quadro 7 – Tipos de conectores do BPMN .............................................................................. 50 
Quadro 8 – Artefatos do BPMN ............................................................................................... 51 
Quadro 9 – Taxionomia de requisitos de um BPMS ................................................................ 52 
Quadro 10 – Propostas da ISO-9126 para requisitos não-funcionais ....................................... 54 
Quadro 11 – Resumo da classificação contábil-financeira ....................................................... 58 
Quadro 12 – Guias de recolhimento de impostos ..................................................................... 61 
Quadro 13 – Requisitos não funcionais .................................................................................... 82 
 
 
 
 
 
LISTA DE GRÁFICOS 
 
Gráfico 1 – Pagamentos por mês .............................................................................................. 59 
Gráfico 2 – Meios de pagamento utilizados ............................................................................. 62 
 
 
 
 
 
 
 
LISTA DE ABREVIATURAS E SIGLAS 
 
ANEEL – Agência Nacional de Energia Elétrica 
BPMN – Business Process Modeling Notation 
BPD – Business Process Diagram 
BPEL – Business Process Execution Language 
BPMI – Business Process Management Initiative 
CCEE – Câmara de Comercialização de Energia Elétrica 
DPN – Diagrama de Processos de Negócio 
ECM – Enterprise Content Management 
EDMS – Electronic Document Management Software 
EPC – Event-Driven Process Chain 
FEPSC – Fornecedores, entradas, processos, saídas e clientes 
GED – Gerenciamento Eletrônico de Documentos 
IDEF – Integrated Definition 
OMG – Object Management Group 
PCH – Pequena Central Hidrelétrica 
TI – Tecnologia da Informação 
UML – Unified Modeling Language 
USP – Universidade de São Paulo 
 
 
 
SUMÁRIO 
 
1. Introdução ...................................................................................................... 21 
1.1 A Empresa ......................................................................................................................... 21 
1.1.1 Atividades no Brasil ..................................................................................................... 23 
1.1.2 Modelo de desenvolvimento da empresa no Brasil ...................................................... 25 
1.1.3 Situação atual dos projetos .......................................................................................... 26 
1.2 O Estágio 27 
1.3 O Problema ....................................................................................................................... 28 
1.4 Objetivo do Trabalho ....................................................................................................... 30 
1.5 Organização do Trabalho ................................................................................................ 30 
2. Fundamentos teóricos ................................................................................... 32 
2.1 Abordagem por processos ................................................................................................ 32 
2.1.1 Introdução .................................................................................................................... 32 
2.1.2 Gestão de processos de negócio ................................................................................... 34 
2.1.3 O papel da tecnologia da informação nas organizações ............................................. 35 
2.1.4 Sistemas BPM ............................................................................................................... 37 
2.2 Definição de requisitos para um sistema de informação .............................................. 38 
2.2.1 Ciclo de vida de sistemas de informação ..................................................................... 39 
2.2.2 Requisitos ..................................................................................................................... 42 
3. Método ........................................................................................................... 44 
3.1 Mapeamento de processos de negócio ............................................................................. 44 
3.2 Modelagem de processos .................................................................................................. 47 
3.3 Business Process Modeling Notation (BPMN) ................................................................ 48 
3.3.1 Elementos básicos ........................................................................................................ 49 
3.3.2 Swimlane ....................................................................................................................... 50 
3.3.3 Artefatos ....................................................................................................................... 51 
3.4 Método para definição de requisitos ............................................................................... 52 
3.4.1 Requisitos do BPMS ..................................................................................................... 52 
3.4.2 Outros requisitos não funcionais .................................................................................. 53 
 
4. Aplicação do Método ..................................................................................... 55 
4.1 Apresentação da situação atual ...................................................................................... 55 
4.1.1 Atores dos processos .................................................................................................... 56 
4.1.2 Classificação contábil-financeira ................................................................................ 58 
4.1.3 Mapeamento dos processos atuais ............................................................................... 59 
4.1.4 Exemplos ilustrativos de pagamentos .......................................................................... 63 
4.2 Análise da situação atual e modelagem de novos processos ......................................... 67 
4.2.1 Análise dos processos atuais........................................................................................ 67 
4.2.2 Modelagem de novos processos ................................................................................... 68 
4.3 Requisitos do sistema de informação ............................................................................. 76 
4.3.1 Tecnologia e arquitetura de software e integração com outros sistemas ................... 77 
4.3.2 Automação de fluxos de trabalho................................................................................. 77 
4.3.3 Modelagem gráfica de processos ................................................................................. 78 
4.3.4 Recursos para gerenciamento de processos ................................................................ 78 
4.3.5 Gerenciamento eletrônico de documentos e conteúdos ............................................... 79 
4.3.6 Formulários eletrônicos ............................................................................................... 79 
4.3.7 Captura, processamento e impressão de documentos ................................................. 80 
4.3.8 Integração e interoperabilidade com outros sistemas .................................................80 
4.3.9 Segurança lógica e garantia de privacidade ............................................................... 81 
4.3.10 Outros requisitos não-funcionais ................................................................................. 81 
5. Conclusão ....................................................................................................... 83 
Referências bibliográficas ................................................................................. 85 
Apêndice A - Detalhamento da classificação contábil-financeira ................. 87 
Apêndice B – Solicitação de Pagamento e Carimbo ...................................... 90 
 21
1. Introdução 
O setor elétrico brasileiro, cuja construção se deu primordialmente por um monopólio 
estatal, tem, desde 1995, passado por um processo de reformulação, a fim de implementar um 
modelo horizontal para o setor de produção de energia, com base em concorrência nos 
segmentos de produção e comercialização e em regulação nos segmentos de transmissão e 
distribuição. 
A produção independente tem permitido a entrada de novos investidores, com 
autonomia para fazer contratos bilaterais de compra e venda de energia elétrica de forma 
competitiva. Com a finalidade de atender à crescente demanda verificada no mercado e às 
necessidades de centros consumidores de pequeno porte, o governo brasileiro tem oferecido 
uma série de benefícios para o investidor privado, além de ter simplificado o processo para a 
obtenção de licenças para a construção de pequenas centrais hidrelétricas, como uma forma de 
estimular o investimento. 
Neste contexto, a Velcan Energy, uma jovem empresa francesa, se instalou no Brasil 
no início de 2006. Com uma equipe enxuta e pouco experiente no setor de construção civil, a 
empresa concluiu a construção de sua primeira central hidrelétrica em novembro de 2009. As 
experiências e dificuldades enfrentadas na condução deste primeiro empreendimento serão de 
grande importância para o desenvolvimento de ferramentas para a gestão dos projetos futuros. 
Em linha com este cenário, o autor deste trabalho, que realizou estágio na empresa por 
mais de um ano, se propõe a analisar o fluxo de informações financeiras e o seu controle com 
o intuito de redesenhar os processos administrativo-financeiros com base no desenvolvimento 
de um sistema de informação adaptado às necessidades de gestão. 
1.1 A Empresa 
O grupo Velcan Energy, criado em abril de 2005, desenvolve e opera usinas que 
produzem eletricidade a partir de fontes renováveis: biomassa (resíduos agrícolas) e 
hidráulica. Os projetos do grupo, em sua maioria centrais hidrelétricas, estão localizados na 
Índia e no Brasil. 
A Velcan escolheu estes dois países porque são mercados emergentes caracterizados 
por um forte crescimento econômico e recursos energéticos renováveis abundantes. Além 
disso, nestes países, as necessidades de produção de eletricidade são importantes e a 
 22
exploração de energias renováveis pode ser muito rentável, pois os custos de produção são 
significativamente mais baixos do que em países desenvolvidos. 
A receita do grupo é obtida principalmente a partir da venda de eletricidade à rede 
pública local ou a grandes compradores industriais. A produção de energia limpa permite 
também, em certas condições definidas no Protocolo de Kyoto, a venda de créditos de 
carbono, que são comprados por empresas ou governos interessados ou obrigados a reduzir a 
emissão de gases causadores do efeito estufa. 
A Velcan Energy SA, sede do grupo com base em Paris, controla mais de 20 
empresas, distribuídas em quatro países – Índia, Brasil, Emirados Árabes Unidos e França – 
que se distinguem pela função e pela área em que atuam. 
Algumas subsidiárias têm função de prospecção de novos projetos e/ou de empresa de 
engenharia, enquanto outras são apenas entidades jurídico-financeiras destinadas ao 
desenvolvimento, financiamento e operação de um ou mais projetos. 
O escritório de Paris tem uma equipe de engenheiros que trabalha em conjunto com 
equipes de projeto na Índia e no Brasil. Em Dubai, Emirados Árabes Unidos, se encontra o 
departamento jurídico do grupo. O departamento financeiro era baseado também em Dubai 
até o segundo semestre de 2009, quando foi transferido para Paris. Ao todo, a empresa tem 
por volta de 150 funcionários. 
 
Figura 1 – Presença da Velcan no mundo 
Fonte: adaptado pelo autor a partir de documentos internos da empresa 
 
 23
Em decorrência de operações financeiras realizadas pela Velcan no mercado de ações, 
o grupo desfruta de fundos próprios para realizar os investimentos necessários ao 
desenvolvimento dos seus projetos a curto e médio prazos. 
1.1.1 Atividades no Brasil 
O Grupo estabeleceu sua filial brasileira, Velcan Desenvolvimento Energético do 
Brasil, no início de 2006, com o objetivo de desenvolver rapidamente uma carteira de projetos 
hidrelétricos. A Velcan finalizou a construção de sua primeira usina hidrelétrica no segundo 
semestre de 2009. A empresa conta ainda com três outros projetos em fase de obtenção de 
licenças finais e diversos projetos em fase de prospecção. No entanto, o modelo de 
desenvolvimento continua em constante mutação para se adaptar ao mercado brasileiro. 
 
 
Figura 2 – Organização societária da Velcan no Brasil 
Fonte: elaborado pelo autor 
 
Os esforços da Velcan no Brasil estão voltados para o desenvolvimento de projetos de 
Pequenas Centrais Hidrelétricas - PCH - que são atualmente uma forma rápida e eficiente para 
promover a ampliação da oferta de eletricidade no Brasil. São consideradas PCHs as centrais 
hidrelétricas com capacidade total instalada superior a 1.000 kW e inferior ou igual a 30.000 
kW e dotadas de uma área total de reservatório igual ou inferior a três quilômetros quadrados. 
A energia gerada nestas usinas pode ser vendida através de distribuidores públicos, por meio 
VDEB
Quebra 
Dedo
Pirapetinga Ibituruna
Rodeio 
Bonito
Rodeio Bonito 
Hidroenergia
Velcan Energy
França
Brasil
Entidades controladoras
Administração / engenharia
Projetos de PCH
PCH em operação
 24
de contratos de longo prazo; no mercado livre, por meio de corretores; ou diretamente a 
grandes consumidores industriais. 
Com a finalidade de melhorar a atratividade e fomentar a implantação destes 
empreendimentos perto dos centros consumidores e em áreas periféricas ao sistema de 
transmissão, o Governo Federal criou incentivos para o estabelecimento de PCHs no território 
nacional. Esses incentivos incluem: 
• Benefícios fiscais 
• Financiamento do BNDES com longos prazos e baixos custos 
• Simplificação dos processos de obtenção de autorizações 
Devido à grande atratividade, em parte produzida pelos incentivos descritos acima, o 
mercado tem se desenvolvido rapidamente e vários investidores brasileiros e de diferentes 
partes do mundo têm se interessado pelo negócio. 
Contudo, apesar da simplificação do processo para a obtenção de autorizações, desde a 
prospecção de novos projetos até a venda efetiva de energia, o processo é longo e 
competitivo. A ANEEL (Agência Nacional de Energia Elétrica) controla o processo como um 
todo, mas várias outras aprovações são necessárias: de entidades ambientais, do poder público 
local e de outras entidades que controlam o sistema elétrico brasileiro. 
De maneira resumida, o primeiro passo desse processo é o estudo prospectivo com o 
objetivo de identificar os rios com potencial hidrelétrico inexplorado. Então, as empresas 
interessadas apresentam projetos básicos de centrais hidrelétricas à ANEEL. De acordo com 
critérios previamente definidos, a ANEEL concede a licença a uma determinada empresa após 
referendar a documentaçãoapresentada. 
Uma vez obtida a licença da ANEEL, o empreendedor não está mais exposto à 
concorrência no projeto em questão e deve realizar, então, estudos técnicos, econômicos e 
ambientais mais detalhados, com base nos quais solicita as demais autorizações. 
Uma vez obtidas estas autorizações, a construção do empreendimento pode ser 
iniciada. Esta etapa dura, dependendo das características de cada projeto, de 24 a 48 meses, 
sem considerar imprevistos de ordem técnica. 
Vale mencionar também que existe um mercado secundário de compra e venda de 
projetos e licenças em diferentes estágios do processo. 
 25
1.1.2 Modelo de desenvolvimento da empresa no Brasil 
Em 2006, a Velcan chegou ao Brasil com o objetivo de adquirir licenças para projetos 
hidrelétricos. Sem uma equipe completa de engenharia local, a Velcan comprou quatro 
licenças de PCHs em menos de dois anos. 
No entanto, durante a fase de desenvolvimento dos projetos, a equipe de engenharia da 
Velcan constatou que a qualidade dos projetos não era satisfatória. Os custos de construção de 
Rodeio Bonito, por exemplo, ultrapassaram o orçamento inicial em cerca de 25% devido ao 
mau dimensionamento do projeto de engenharia, resultando em ajustes consideráveis durante 
a execução da obra. Com relação aos projetos de Ibituruna e Pirapetinga, após a realização de 
estudos mais precisos, verificou-se que os projetos pressupunham maior uso de recursos 
hidrológicos do que a capacidade hidrológica local, resultando em baixas taxas de utilização 
das centrais hidrelétricas. 
No início de 2008, a Velcan decidiu não comprar mais projetos no mercado 
secundário, desenvolvendo seus próprios projetos desde a prospecção até a construção. Para 
isso, a empresa recrutou uma equipe multidisciplinar brasileira composta por engenheiros 
eletromecânicos, engenheiros eletrotécnicos, engenheiros hidráulicos, engenheiros estruturais, 
geólogos e biólogos. A empresa se inscreveu, então, em diversos processos de outorga da 
ANEEL. 
Porém, a Velcan enfrentou inúmeros atrasos nos processos administrativos. Além 
disso, mudanças na regulamentação criaram ainda mais complicações. Diferentemente do que 
a direção da empresa esperava, o processo de viabilização de um projeto, desde os primeiros 
estudos até a obtenção da licença de instalação, leva de 24 a 60 meses. Por esta razão, 
tornaram-se insustentáveis os elevados custos fixos ligados à folha de pagamento da equipe 
técnica. Desta forma, em maio de 2009, a Velcan mudou mais uma vez seu modelo de 
desenvolvimento no Brasil e, consequentemente, a equipe técnica foi dissolvida. 
Após um período de incertezas, a Velcan retomou o estudo de novos projetos, em 
ritmo mais lento do que em anos anteriores, para compensar a possibilidade de fracasso de 
alguns projetos. 
 
 26
1.1.3 Situação atual dos projetos 
Rodeio Bonito é a primeira central hidrelétrica construída pelo grupo Velcan. A 
central hidrelétrica está em operação comercial desde novembro de 2009, e a energia gerada é 
vendida no mercado livre da Câmara de Comercialização de Energia Elétrica (CCEE) através 
de contratos de curto prazo. A construção sofreu consideráveis atrasos em relação às 
previsões iniciais devido a uma multiplicidade de acontecimentos e dificuldades que, 
individualmente, geraram atrasos pequenos, mas cuja acumulação, especialmente na fase final 
de construção, levou a um atraso considerável. 
 
Figura 3 – Fotos da PCH Rodeio Bonito. 
Fonte: Fotos tiradas pelo autor em visita ao local 
 
Ibituruna, Pirapetinga e Quebra Dedo são os outros três projetos comprados no 
mercado secundário de licenças. Estes três projetos estão ainda em fase de avaliação técnico-
econômica e de obtenção de licenças administrativas necessárias ao início da construção. As 
licenças ambientais ainda não foram obtidas. Problemas ambientais descobertos após a 
aquisição das licenças limitam a capacidade de geração elétrica previamente aprovada pela 
ANEEL. A revisão e a alteração dos projetos devem ser autorizadas pela ANEEL, que está, 
no momento, relutante a aprovar tais modificações. Não existe uma data prevista para uma 
possível construção destes três projetos. 
 27
 
Figura 4 – Projetos da Velcan no Brasil 
Fonte: Site da companhia 
A Velcan tem outros projetos em fase de prospecção, mas que serão mantidos em 
confidencialidade a pedido da empresa. 
 
1.2 O Estágio 
O autor ingressou na empresa em fevereiro de 2009 para a realização do estágio de 
conclusão do programa de Duplo Diploma entre o Departamento de Engenharia de Produção 
da Escola Politécnica da USP e a École Nationale des Ponts et Chaussées da França. 
Diferentemente do Brasil, os estágios na França não são realizados concomitantemente com 
os estudos. Durante o período de estágio, o aluno permanece inteiramente dedicado à empresa 
e ao projeto nela desenvolvido, o que possibilita realizar o estágio em tempo integral em 
qualquer lugar do mundo. 
Na fase inicial do estágio, o autor passou por um período de um mês de treinamento 
técnico e organizacional, sendo duas semanas no escritório administrativo em Paris e duas 
semanas no centro financeiro em Dubai. 
Em Paris, o treinamento consistiu principalmente na aprendizagem de como a empresa 
se organiza. A Velcan tem uma organização complexa no sentido de que se espalha em 
diversos escritórios pelo mundo, sendo as estruturas hierárquicas matriciais. Mesmo sendo um 
 28
brasileiro em treinamento para trabalhar com outros brasileiros, o autor tinha a função de 
incorporar a cultura francesa na filial brasileira. 
Durante as duas semanas de treinamento em Dubai, foram apresentados os princípios 
contábeis do grupo e as necessidades de informações financeiras dos centros administrativos. 
Após o período de formação, o autor passou a trabalhar no escritório de São Paulo da 
empresa com objetivos definidos: 
• Implementar, no Brasil, a classificação contábil-financeira desenvolvida pela equipe 
financeira de Dubai, com o objetivo de padronizar o tratamento da informação 
financeira do grupo nos diferentes países. 
• Elaborar relatórios financeiros para o acompanhamento dos dados. 
• Analisar o processo financeiro para estabelecer um banco de dados completo e, 
sobretudo, confiável. 
No entanto, por se tratar de uma equipe relativamente pequena no Brasil, o aluno se 
envolveu nas mais diversas atividades durante o estágio, desde a parte financeira até a 
comercial, passando pela técnica. 
 
1.3 O Problema 
Logo no início do estágio, verificou-se que os processos de pagamento e de 
contabilização tinham limitações que levavam a erros nas informações contábeis da filial 
brasileira. Além disso, existiam saldos incoerentes que se arrastavam por anos por não haver 
qualquer procedimento de verificação das informações. Uma grande parte do trabalho 
desenvolvido ao longo do estágio foi dedicada à auditoria das informações contábeis de todas 
as entidades brasileiras e dos saldos dos contratos da central hidrelétrica em construção. 
Exemplos de erros detectados num primeiro momento: 
• Dívidas a fornecedores que não faziam sentido 
• Salários a serem pagos a funcionários que já haviam deixado a empresa 
• Saldos antigos de tributos a recolher (o pagamento integral de tributos é feito a cada 
mês, então não há motivo para se ter passivos tributários que se arrastam por meses) 
• Conta “cliente” no ativo (a Velcan não tinha clientes) 
 29
• Pagamentos em duplicidade 
De um lado, o esforço para corrigir as contas fez com que mais erros fossem 
encontrados. Por outro lado, para limpar as contas, foi necessário encontrar as origens dos 
problemas através da análise do processo e de suas falhas. 
A partirdo estudo sobre o processo financeiro, foi possível adquirir uma profunda 
compreensão da interação entre as partes envolvidas, desde a assinatura do contrato de 
prestação de serviço, ou solicitação de compra, até a contabilização do pagamento. Isto 
permitiu fazer diferentes análises, sempre com o objetivo de garantir a qualidade das 
demonstrações financeiras e dos relatórios destinados à direção e aos acionistas. 
O relatório de trabalho de conclusão de curso apresentado à École Nationale des Ponts 
et Chaussées descreve uma primeira abordagem para esta situação, com análises preliminares 
e algumas pequenas melhorias implementadas no processo. O esforço para estudar o processo 
e auditar as contas atraiu a atenção da equipe no Brasil sobre a importância de adotar 
processos padronizados e procedimentos de controle. No entanto, as soluções propostas e 
implementadas são em grande parte restritas a procedimentos de controle e avaliação de 
falhas e, conseqüentemente, não impedem a ocorrência de novos erros no futuro. 
Além disso, a maneira como são realizadas as tarefas e os seus controles não é 
eficiente. Por mais que atualmente as informações financeiras e contábeis estejam corretas, 
isto é, condizentes com a realidade da empresa, isto só ocorre porque o volume de 
pagamentos e contratos ainda é relativamente pequeno. A empresa concluiu recentemente a 
construção de sua primeira central hidrelétrica, o que representou uma quantidade média 
próxima de 200 pagamentos por mês e aproximadamente 60 contratos com fornecedores. 
Porém, espera-se que até o final de 2011 sejam iniciadas três novas construções de maior 
porte, o que representaria um volume muito maior de pagamentos, referentes a mais de um 
empreendimento. 
Deste modo, o desenvolvimento de ferramentas informatizadas é um passo importante 
para melhorar o tratamento das informações financeiras da subsidiária brasileira da Velcan. 
As principais limitações do processo atual não serão eliminadas sem a integração dos 
intervenientes do processo através da tecnologia da informação. 
 
 30
1.4 Objetivo do Trabalho 
Antes mesmo de o aluno ingressar na empresa, foram feitas análises para implementar 
sistemas informatizados para o controle gerencial e financeiro das atividades da Velcan no 
Brasil. Porém, a direção considerou as alternativas muito caras, além de não se adequarem às 
reais necessidades da empresa. Laurindo e Rotondaro (2008) afirmam que são necessárias 
uma criteriosa análise dos processos em vigor e a verificação dos elementos comportamentais 
envolvidos para que este tipo de mudança seja realizado, dado que são relativamente comuns 
os relatos de experiências traumáticas na implementação de sistemas de informação. 
Neste contexto, o objetivo deste trabalho é analisar os processos financeiros da filial 
da empresa no Brasil, com uso de métodos e técnicas estudados durante o curso de 
Engenharia de Produção da Poli, para assim propor um novo modelo para o processo e, em 
seguida, definir os requisitos do sistema de informação que servirá de suporte ao novo 
processo. 
 
1.5 Organização do Trabalho 
Este trabalho está organizado da seguinte forma: 
O Capítulo 1 realiza uma introdução dos temas tratados neste trabalho, descrevendo, 
em linhas gerais, a empresa junto à qual foi realizado o trabalho, o estágio realizado pelo 
autor à época da elaboração deste estudo, as razões que levaram à sua execução e os objetivos 
deste trabalho. 
O Capítulo 2 apresenta o referencial teórico do estudo desenvolvido, com conceitos 
divididos em duas seções fundamentais: abordagem por processos e definição de requisitos de 
um sistema de informação. A motivação para escolha de tais tópicos se baseia na ideia de que 
estes abrangem um largo escopo de análise do problema a ser resolvido. 
O Capítulo 3 se propõe a apresentar o método adotado para a resolução do problema, 
seguindo a mesma divisão de seções do capítulo anterior. 
O Capítulo 4 contém o desenvolvimento do trabalho propriamente dito, com as 
análises elaboradas pelo autor com base no ferramental e nos métodos descritos nos capítulos 
anteriores. 
 31
Por fim, o Capítulo 5 fornece a conclusão do trabalho, a qual inclui uma discussão da 
importância deste estudo para e empresa estudada e sugestões para trabalhos futuros. 
 32
2. Fundamentos teóricos 
O entendimento adequado deste documento exige, inicialmente, que seja apresentado 
um referencial adquirido da literatura que sirva de base para o corpo do trabalho através do 
desenvolvimento de conceitos básicos e da definição das ferramentas que são utilizadas 
posteriormente. 
O referencial teórico a seguir, portanto, dá apoio ao conteúdo apresentado 
posteriormente. Neste capítulo, são descritos alguns dos principais conceitos pertinentes à 
análise e modelagem de processos de negócios, assim como à definição de requisitos para um 
sistema de informação. 
Desta forma, este capítulo está dividido em duas seções principais. A primeira delas 
trata de conceitos relativos à abordagem por processos, concentrando-se principalmente nas 
bases da análise de processos de negócios. A segunda seção é focada em conceitos 
relacionados às etapas necessárias para a definição de requisitos de sistemas de informação. 
 
2.1 Abordagem por processos 
Esta seção apresenta o princípio da abordagem por processos e o seu impacto sobre as 
organizações, dando destaque para o papel dos sistemas de informação como suporte aos 
processos. 
Para tal, é feita uma introdução em que o tema é contextualizado historicamente e, em 
seguida, discute-se o papel que esta abordagem tem nas organizações. Na sequência, é feita 
uma análise das transformações ocorridas nos processos organizacionais como consequência 
da evolução dos sistemas de informação e, por fim, o conceito de sistema BPM é apresentado. 
 
2.1.1 Introdução 
Davenport (1994), um dos criadores da reengenharia de processos, define processo da 
seguinte forma: 
“Processo é simplesmente um conjunto de atividades estruturadas e medidas, 
destinadas a resultar num produto especificado para um determinado cliente ou 
mercado. É, portanto, uma ordenação específica das atividades de trabalho no 
 33
tempo e no espaço, com um começo, um fim e inputs e outputs claramente 
identificados”. 
O estudo de processos nas organizações não é algo novo, e sua origem remonta ao 
início do século passado com o surgimento da administração científica, movimento cujos 
maiores representantes foram Frederick Taylor e Henry Ford. Estudos de Taylor introduziram 
conceitos de eficiência de processos, especialização, assim como de medição de desempenho. 
Segundo Zilbovicius (1998), o taylorismo se baseava na necessidade do 
aprofundamento do controle do processo de trabalho por parte dos capitalistas e/ou 
empresários. A eficiência de qualquer processo estaria associada ao aprofundamento da 
divisão do trabalho e deveria haver uma separação estrita entre as atividades de planejamento 
e de execução do trabalho direto. 
Zarifian (1992) considera que uma das virtudes de Taylor foi quebrar o monopólio 
detido pelos operários sobre a definição dos seus atos de trabalho. Nesta nova visão os 
engenheiros e técnicos dos departamentos de administração da produção tinham grande poder 
para definir e prescrever o processo de trabalho. Desta forma, o taylorismo instaura uma 
divisão entre a concepção e execução do trabalho. 
Desde o primeiro trabalho de Taylor no início do século passado até a proposta mais 
recente, muitos autores e organizações desenvolveram propostas de como compor um modelo 
de gestão de processos adequado. 
Posteriormente aos primeiros avanços da escola clássica, nos anos que vieramdepois 
das grandes guerras, surgiram as técnicas japonesas de administração, que apresentaram as 
ideias de produção enxuta. Por partir de muitas observações de sistemas utilizadores dos 
princípios da escola clássica, existem alguns pontos semelhantes à escola clássica. Woomack, 
Jones e Roos (1992) destacam que em ambos os sistemas há uma grande padronização do 
trabalho no chão de fabrica, porém com uma diferença marcante: onde no Fordismo o 
trabalho era controlado pelos gerentes, na produção enxuta da Toyota o controle era feito por 
equipes. Tal situação acabou por fortalecer uma característica pouco explorada na escola 
clássica, o trabalho em grupo, extremamente encorajado nas fabricas da Toyota, aumentando 
a qualidade do trabalho e a interação entre funcionários. 
Na segunda metade do século passado, emergiu a era da busca melhoria contínua 
caracterizada pela Total Quality Management, gestão da qualidade total, largamente adotada 
pelas organizações a partir da década de 80. 
 34
Em seguida, houve o movimento dos sistemas integrados de gestão ou ERP, que 
tinham a finalidade de implementar nas organizações sistemas integrados para promover a 
mudança de visão departamental para a abordagem a partir de processos nas empresas. Para 
atingir tal finalidade, se fazia necessária a aplicação de soluções integradas de software que 
contivessem todos os aplicativos necessários aos processos das organizações. 
 
2.1.2 Gestão de processos de negócio 
Ao longo do desenvolvimento das diferentes soluções para a abordagem por processo, 
houve o deslocamento do enfoque da dimensão vertical, em que as organizações eram 
observadas a partir das funções e das estruturas definidas nos organogramas, para um enfoque 
horizontal, em que o foco de estudo são os processos. 
Alvarenga Netto (2008) aponta a gestão por processos como resultado das 
transformações no panorama competitivo que acarretaram a necessidade de agilidade e novos 
conceitos e práticas de gestão. Ainda segundo o autor, a organização horizontal possibilita a 
agilidade nos processos internos, aumentando a velocidade de resposta ao mercado e a 
capacidade da organização de fornecer produtos de massa personalizados, aumentando a 
eficiência e a eficácia dos processos. 
 
 
Figura 5 – Estrutura funcional versus visão por processos 
Fonte: Adaptado de Alvarenga Netto (2008), elaborado pelo autor 
 
Para Davenport (1994), enquanto a organização funcional é caracterizada por ser 
fragmentada e estanque das responsabilidades e das relações de subordinação, a estrutura 
baseada em processos é dinâmica na forma como a organização gera valor. 
Direção
Departamento
jurídico
Departamento
técnico
Departamento
financeiro
Departamento
comercial
Processo
 35
Alvarenga Netto (2008) propõe que linhas de autoridade vertical (funcionais) e linhas 
de autoridade horizontal (processos) cruzem as funções organizacionais nas empresas que 
adotam a gestão por processos, caracterizando a necessidade de estruturas matriciais. Segundo 
o autor, o equilíbrio entre as diferentes autoridades, indo de uma estrutura predominantemente 
funcional à estrutura de processo puro, passando pela matricial equilibrada, depende de 
características internas de cada organização e do papel do “dono do processo”. No entanto, 
segundo Davenport (1994), existe uma dificuldade em definir a propriedade dos processos 
devido ao fato de raramente estarem dentro de limites de poder ou de autoridade 
organizacional. 
Segundo Valle e Oliveira (2009), o papel da gestão de processo de negócio é servir de 
instrumento de ligação entre tudo o que se desenvolve na organização e tem a finalidade de 
facilitar a comunicação e a cooperação entre os diferentes atores das organizações. 
Spanyi (2003) afirma que o gerenciamento de processos de negócio envolve a 
definição, a melhoria e a gestão dos processos de negócio de uma organização, envolvendo 
todos os departamentos e etapas, com apoio da tecnologia, a fim de alcançar três pontos de 
importância crucial para uma empresa: clareza na implementação da estratégia, alinhamento 
dos recursos e disciplina nas atividades cotidianas. 
 
2.1.3 O papel da tecnologia da informação nas organizações 
Para Laurindo e Rotondaro (2008), o papel da tecnologia da informação ganhou muito 
destaque com a globalização e os consequentes impactos deste fenômeno nas organizações. 
Segundo os autores, o novo capitalismo é marcado não só pela internacionalização das 
atividades, mas também pela forma global de organização dos processos. Como 
consequência, os fatos que ocorrem em um determinado local podem ter repercussão direta 
em outro local distante ou, até mesmo, no resto do mundo. Assim, as redes informatizadas 
surgem como agente viabilizador desta nova configuração de atividades ou como forma de 
potencialização das vantagens competitivas. 
Esta evolução do papel dos sistemas de informação pode ser resumida conforme o 
quadro 1. 
 
 
 36
Quadro 1 – Evolução do papel da TI ao longo do tempo 
 Era I – meados 
de 50 a meados 
de 70 
Era II – meados 
de 70 a meados 
de 80 
Era III – meados 
de 80 a meados 
de 90 
Era IV – meados 
de 90 até hoje 
Descrição Suporte 
operacional 
Suporte à 
administração e 
a trabalhos de 
conhecimento 
Suporte à 
transformação 
do negócio e à 
competição 
Computação 
onipresente 
Objetivo 
primário 
Suporte a 
operações 
Suporte à 
administração 
Melhoria na 
posição 
competitiva 
Integração 
eletrônica 
Clientes 
primários 
Grandes 
unidades 
corporativas 
Gerentes e 
profissionais 
Unidades de 
negócio 
Equipes 
colaborativas 
Justificativa Eficiência Eficácia 
gerencial 
Fatia de 
mercado e 
lucratividade 
Eficácia 
organizacional 
Fonte Processamento 
de dado 
individual ou 
departamento de 
sistemas de 
informação 
Unidades de 
sistemas de 
informação e 
usuários finais 
Coordenada 
dentro da 
organização / 
computação 
voltada ao 
usuário final 
Estrutura de 
computação 
própria e 
terceirizada 
Fonte: Adaptado de Zwass apud. Laurindo e Rotondaro (2008) 
 
Neste contexto, as organizações passaram a buscar soluções baseadas na tecnologia da 
informação para integrar processos, de maneira a otimizar os fluxos de trabalho e alinhar os 
conhecimentos gerados. 
Davenport (1994) aponta nove categorias diferentes de oportunidades para apoiar a 
reengenharia de processos com a tecnologia da informação, que têm como objetivos a redução 
de custos, eliminação de tempos e assim por diante. 
Quadro 2 – Impacto da TI sobre a reengenharia de processos 
IMPACTO EXPLICAÇÃO 
Automacional Eliminação do trabalho humano de um processo 
Informacional Captação da informação de processos com o objetivo de 
compreensão 
Sequencial Modificar sequência de processo ou impossibilitar o paralelismo 
De acompanhamento Monitoração rigorosa da situação e objeto do processo 
 37
Analítico Melhorar análise da informação e tomada de decisões 
Geográfico Coordenação dos processos à distância 
Integrativo Coordenação entre tarefas e processos 
Intelectual Captação e distribuição de bens intelectuais 
Desintermediação Eliminação de intermediários num processo 
Fonte: Davenport (1994) 
 
Valle e Oliveira (2009) ressaltam que por mais que pareça evidente, muitas 
organizações cometem o equívoco de primeiramente comprar uma solução pronta baseada em 
softwares antes mesmo de pensar no modelo de gestão por processos, quando o correto é o 
caminho inverso. 
Alvarenga Netto (2008) aponta que as mudanças tecnológicas avançam mais rápido do 
que a capacidade das organizações e dos homens de incorporar tais mudanças, fazendocom 
que, muitas vezes, as aplicações da tecnologia da informação estejam dissociadas dos projetos 
de melhoria da qualidade. Neste contexto, a gestão por processos se propõe a responder tais 
questões e aparece como base para a maioria das modernas ferramentas de gestão. 
 
2.1.4 Sistemas BPM 
Segundo Storch e Pêssoa (2008), nas últimas décadas, houve uma aceleração do 
fenômeno de ascensão e queda de ideias no campo da gestão, estando inseridas 
principalmente entre dois extremos: a inovação incremental de processos e o radicalismo do 
movimento de reengenharia. Porém, ambas convergem no sentido em que buscam soluções 
para as necessidades de revisões dinâmicas dos processos dentro das organizações. 
Concomitantemente, cresceu a incidência de problemas ligados à implementação de sistemas 
ERP, segundo os autores, principalmente devido ao fato de tais sistemas não conseguirem 
acompanhar a velocidade de evolução das organizações. Este contexto criou um campo fértil 
para o aparecimento de uma solução que não dependesse tão intensivamente de recursos 
humanos no desenvolvimento de linguagem de programação e na modelagem de processos da 
forma tradicional. Neste cenário, surgiram os sistemas BPM (ou BPMS, do inglês Business 
Process Management Systems), que transferem do analista de sistemas para o analista de 
negócios a maior parte do trabalho de adaptação incremental dos processos. 
 38
Os sistemas BPM surgiram da convergência das ferramentas de workflow, 
gerenciamento de imagem, GED, EDMS e ECM que apareceram desde o final dos anos 80. 
Storch e Pêssoa (2008) listam os avanços trazidos pelas tecnologias de workflow que foram os 
embriões dos conceitos do BPMS: 
• Formulários eletrônicos, permitindo suprimir documentos que só serviam como 
suporte físico para a transmissão de dados; 
• Uso de imagens digitalizadas, permitindo o início de processos sem papel; e 
• Regras de negócio que regulavam as alternativas de decisão dos operadores e 
permitiam automatizar alguns tipos de decisões mais padronizados. 
Os autores concluem que esses avanços tornaram mais fácil a interação entre homem e 
máquina, integrando tarefas automatizáveis com outras para as quais a participação humana é 
indispensável. No entanto, vale ressaltar que o objetivo dos sistemas BPM não é substituir o 
trabalho humano por máquinas, estando o foco apenas na eliminação de atividades que 
sacrificam o uso da inteligência humana e na eliminação de tempos mortos entre tarefas. 
Através da utilização de novas tecnologias, o BPM resolveu diversas limitações 
existentes nos sistemas de workflow, dentre as quais se destacam: 
• Integração com bancos de dados corporativos; 
• Integração direta com aplicativos sem intervenção humana; 
• Operação em tempo real; 
• Linguagem padronizada de descrição de processos; e 
• Redução do custo de licenças. 
 
2.2 Definição de requisitos para um sistema de informação 
Após a verificação da necessidade de um sistema de informação, é necessário estudar 
como desenvolvê-lo. Nesta seção são apresentadas as principais características do 
desenvolvimento de sistemas de informação, dando ênfase às etapas iniciais que estão no 
escopo deste trabalho. 
 
 39
2.2.1 Ciclo de vida de sistemas de informação 
Como para qualquer outro tipo de produto, é possível estabelecer modelos de ciclo de 
vida para os sistemas de informação em que eles são concebidos, desenvolvidos, utilizados e 
retirados de operação no término da vida útil. Segundo Moraes (2008), o ciclo de vida 
clássico, também conhecido como modelo cascata, é o que mais sofre influência de outras 
áreas de engenharia e se caracteriza pela realização sequencial de suas diferentes fases. 
Apesar de existirem diferenças entre a descrição das fases para cada autor que já abordou o 
tema, todos têm em comum o princípio de que o projeto é realizado de maneira sequencial. 
 
 
Figura 6 – Ciclo de vida clássico 
Fonte: Pressman (1995) apud Moraes (2008) 
 
Na primeira etapa do ciclo de vida clássico apresentado acima, é realizada a definição 
dos requisitos para todos os elementos do sistema. Em seguida, os requisitos do software são 
especificados. Na etapa de Projeto, as especificações de requisitos são transformadas em 
especificações técnicas de construção. Na quarta etapa, as especificações técnicas são 
traduzidas de forma que o hardware possa entendê-las. Na etapa de teste, busca-se a 
eliminação de erros e de não-conformidade do código desenvolvido. E, finalmente, na etapa 
de manutenção, os erros são identificados após a implementação. 
Moraes (2008) observa que apesar da grande popularidade deste modelo, ele não 
representa bem a realidade de muitos projetos, pois, em princípio, de acordo com este modelo 
Engenharia 
de sistema
Análise de 
requisitos
Projeto
Codificação
Teste
Manutenção
 40
uma etapa somente é iniciada após a conclusão da etapa imediatamente anterior. Na prática, 
em poucos casos o desenvolvimento ocorre de maneira linear, sendo inevitáveis alguns 
retrocessos. 
Em decorrência das críticas ao modelo clássico, foram propostos outros modelos com 
o objetivo de incorporar os retrocessos ao ciclo de vida dos sistemas de informação. Dentre os 
modelos propostos, destacam-se o modelo evolucionário, o modelo incremental e o modelo 
em espiral. 
Quadro 3 – Modelos de ciclo de vida de softwares 
MODELO PRINCIPAIS CARACTERÍSTICAS 
Evolucionário • O processo começa com um conjunto de objetivos para todo o sistema, 
sendo que a estrutura inicial deve ser simples e passível de alterações 
• Escolhe-se a forma mais fácil de implementar e que leve todo o projeto 
em direção aos objetivos globais 
• Após o desenvolvimento de uma parte do sistema, outra é selecionada e 
desenvolvida 
• Os objetivos globais e a estrutura geral do sistema podem ser alterados 
durante todo o ciclo de vida 
Incremental • As partes do sistema e os requisitos são desenvolvidos de forma 
incremental. 
• Uma vez que o usuário receba uma parte do sistema, este pode avaliá-la 
e fornecer feedbacks para as partes ainda a desenvolver. 
Em espiral • O projeto é desenvolvido em iterações sucessivas de complexidade 
crescente, sendo que cada é composta por 4 etapas 
• Planejamento: definição dos objetivos e estratégias a serem utilizadas no 
futuro 
• Análise de risco: Identificação e consideração formal de riscos 
associados ao projeto e alternativas de minimizá-los 
• Engenharia: geração do software 
• Avaliação pelo cliente: este feedback serve de apoio para a próxima 
iteração 
Fonte: Elaborado a partir de Moraes (2008) 
 
Recentemente surgiram as chamadas ferramentas de quarta geração, em que partes do 
ciclo de vida dos sistemas de informação são automatizadas. Estas ferramentas são capazes de 
gerar em minutos, através da definição de funcionalidades e interfaces necessárias, códigos de 
programação que levariam semanas para serem desenvolvidos se escritos manualmente. 
 
 41
 
Figura 7 – Aplicação de ferramentas de quarta geração 
Fonte: Moraes (2008) 
Para Moraes (2008), o ponto crítico para a utilização deste tipo de ferramenta é a 
identificação correta das funcionalidades do sistema. Assim, uma boa especificação de 
requisitos é parte essencial para obtenção de sistemas eficazes. 
Após a identificação das necessidades do sistema, a geração automatizada do código e 
a implementação do sistema, é feito o acompanhamento do uso de sistema e da percepção dos 
usuários. A qualidade do sistema de informação é avaliada através do monitoramento da 
satisfação das necessidades da organização. 
A utilização de ferramentas de geração de códigos faz com que a eficiência 
operacional dos sistemas seja consideravelmente maisbaixa comparativamente aos sistemas 
desenvolvidos manualmente. Assim, estas ferramentas estão limitadas a situações em que a 
eficiência operacional não seja crítica. 
 
Identificação das 
necessidades da 
organzação
Especificação dos 
requisitos do sistema
Geração automática 
do código e 
implementação do 
sistema Acompanhamento do 
uso do sistema e do 
usuário
Necessidades 
atendidas?
Encerramento
 42
2.2.2 Requisitos 
Como visto no item anterior, um dos pontos cruciais no desenvolvimento de softwares 
através de ferramentas de quarta geração, que é o caso de sistemas BPM, é a correta 
especificação dos requisitos. 
Para Paula Filho (2009), a disciplina de requisitos reúne as atividades necessárias para 
a definição completa, clara e precisa dos requisitos de um software. Sommerville (2003) 
define requisito de sistema de informação como sendo uma descrição de suas funções e 
restrições, buscando permitir a compreensão do problema a ser solucionado pelo sistema. 
Segundo o autor, a definição dos requisitos serve como base tanto para o desenvolvimento de 
sistemas de informação quanto para a aquisição. 
Engenharia de requisitos é o conjunto de técnicas para levantar, detalhar, documentar 
e validar os requisitos de um produto. Paula Filho (2009) afirma que uma boa engenharia de 
requisitos é essencial para o desenvolvimento de um bom produto e lista as principais 
características que devem estar descritas: 
Funcionalidade: o que o produto deverá fazer? 
Interfaces externas: como o produto interage com as pessoas, com o hardware do 
sistema, com outros sistemas e com outros produtos? 
Desempenho: qual a velocidade de processamento, o tempo de resposta e outros 
parâmetros de desempenho requeridos pela natureza da aplicação? 
Outros atributos: quais as considerações sobre portabilidade, manutenibilidade e 
confiabilidade que devem ser observadas? 
Restrições impostas pela aplicação: existem padrões e outros limites a serem 
obedecidos, como linguagem de implementação, ambientes de operação, limites de recursos 
etc.? 
De acordo com Sommerville (2003), existem requisitos associados a todo tipo de 
software e estes podem ser divididos em duas categorias: 
Funcionais: fazem parte daquilo que o usuário espera do sistema de informação. A 
definição de tais requisitos deve ser completa, no sentido de que sejam especificadas todas as 
funcionalidades requeridas pelos usuários, e consistente, no sentido que as especificações não 
sejam contraditórias. 
 43
Não-funcionais: são restrições ou condições de operação e os padrões a serem 
obedecidos pelo sistema de informação, não se referindo às funções específicas fornecidas 
pelo sistema. Como exemplos, podemos citar tempo de resposta, facilidade de uso, 
portabilidade, confiabilidade, suporte, manutenibilidade. 
Paula Filho (2009) define requisitos não funcionais como sendo os requisitos de 
desempenho e outros atributos de qualidade do produto. Segundo o autor, estes requisitos 
devem ser listados de maneira precisa e quantitativa e a sua determinação correta é essencial 
para o sucesso de um sistema de informação, pois têm grandes impactos na percepção que os 
usuários terão da qualidade e utilidade do produto. Mesmo que seja uma tarefa difícil por ser a 
primeira versão de um produto, os requisitos não funcionais devem ser enunciados de forma 
precisa e quantitativa. 
A pesquisa bibliográfica apresentada neste capítulo fornece subsídios para a adequada 
determinação do método a ser utilizado para a solução do problema proposto. O método 
adotado é descrito no próximo capítulo. 
 44
3. Método 
Após a apresentação do referencial teórico que é utilizado como base para a 
compreensão e o tratamento do problema, neste capítulo, abordaremos o método adotado a 
partir de diferentes proposições encontradas na literatura. 
Em linhas gerais, o trabalho desenvolvido segue as etapas descritas no esquema 
apresentado abaixo. 
 
Figura 8 – Etapas de desenvolvimento do trabalho 
Fonte: elaborado pelo autor 
 
Numa primeira etapa, como ponto de partida, realizaremos o levantamento de 
informações relacionadas aos processos existentes na empresa para compreender a situação 
atual ou, como tratada por alguns autores, a situação “as is”. 
Em segundo lugar, concluída a compreensão dos processos atuais, realizaremos 
estudos para identificar e classificar oportunidades de melhoria que permitam o aumento da 
eficiência operacional e da produtividade, a redução na ocorrência de erros e incoerências e a 
eliminação ou redução de retrabalhos. Esta análise nos permitirá elaborar e propor novos 
processos de negócio. 
E, finalmente, definiremos os requisitos do sistema de informação a ser desenvolvido, 
o qual servirá de suporte à implantação do novo processo. 
 
3.1 Mapeamento de processos de negócio 
Rotondaro (2008) considera a etapa de mapeamento do processo uma das mais 
importantes na gestão por processos, pois possibilita o conhecimento profundo e detalhado de 
todas as operações que ocorrem durante a execução de um serviço ou produto. O autor propõe 
Mapear os 
processos 
atuais
Analisar e 
redesenhar 
processos
Definir os 
requisitos do 
sistema de 
informação
Etapa 1 Etapa 2 Etapa 3
 45
que o primeiro passo para o mapeamento adequado seja a definição de fronteiras do processo 
a ser estudado, através da técnica FEPSC, acrônimo de fornecedores, entradas, processos, 
saídas e clientes, conforme figura 9. 
 
 
Figura 9 – Representação de FEPSC 
Fonte: Rotondaro (2008) 
 
Esta técnica aplica-se a qualquer tipo de trabalho e sua elaboração segue uma 
sequência lógica, apresentada no quadro 4. 
Quadro 4 – Sequência lógica da elaboração do FEPSC 
ETAPA • QUESTÕES 
Determinar o 
propósito 
• Por que existe este processo? 
• Qual é o propósito deste processo? 
• Qual é o resultado? 
Análise das saídas • Que produto faz este processo? 
• Quais são as saídas deste processo? 
• Em que ponto termina este processo? 
Dados dos clientes • Quem usa os produtos deste processo? 
• Quem são os clientes deste processo? 
Análise das entradas e 
fornecedores 
• De onde vem a informação ou material com o qual você 
trabalha? Quem são os seus fornecedores? 
• O que eles oferecem? 
• Como afetam o fluxo do processo? 
• Que efeito têm no processo e no resultado? 
Determinar os passos 
do processo 
• O que ocorre em cada input? 
• Que atividades de conversão acontecem? 
Fonte: Adaptado de Rotondaro (2008) 
Fo
rn
ec
ed
or
es
C
lie
nt
es
Entradas EntradasProcesso
 46
Valle, Oliveira e Braconi (2009) descrevem técnicas e procedimentos utilizados para o 
levantamento de informações para descrever os processos de negócio, apresentadas no quadro 
5. 
Quadro 5 – Técnicas de levantamento de processos 
TÉCNICAS CARACTERÍSTICAS 
Entrevista • Aplicada a um número reduzido de pessoas 
• Permite o diálogo interativo 
• Permite visualizar as reações dos entrevistados 
• Permite grande flexibilidade na estrutura organizacional 
Questionário • Aplicado a um número grande de pessoas 
• Necessita ser bem estruturado e dirigido para o problema que 
se quer analisar 
• Permite pouca flexibilidade na sua estrutura 
• Permite manusear grande número de informações 
Workshop • Aplicado a um número reduzido de pessoas 
• Permite a interação e discussão direta 
• Produz resultados imediatos e evolução na forma de interpretar 
e tratar os processos 
Observação • É a verificação no local de trabalho, com pequenas 
interferências do analista. 
• É aplicada para complementar o levantamento de informações 
sobre o processo, para garantir o entendimento sobre a situação 
analisada, ou quandoo assunto for muito complexo ou muito 
específico. 
Fonte: Valle, Oliveira e Braconi (2009) 
 
Segundo os autores, estas técnicas têm como meta promover a compreensão de 
processo sobre a ordem, a hierarquia e a sequência lógica das atividades necessárias a uma 
unidade organizacional para a produção de serviços ou bens. Destacam também, que a 
entrevista tem sido a mais utilizada. Para o estudo em questão, não será utilizada a técnica de 
questionário, dado o volume pequeno de intervenientes. 
Segundo Borysowich (2006) apud Valle, Oliveira e Braconi (2009), a condução de 
entrevistas deve ser realizada com as finalidades abaixo: 
• Reunir informações sobre o processo existente; 
• Determinar os requisitos de um novo processo; 
• Esclarecer especificações funcionais; 
 47
• Obter informações sobre a organização do cliente; e 
• Obter opiniões sobre a usabilidade. 
Especialmente quando a coleta de informações apresenta as características a seguir: 
• Se as informações podem ser obtidas de um número restrito de pessoas; e 
• Se o processo de coleta de informação requer privacidade; 
 
3.2 Modelagem de processos 
Segundo Oliveira e Almeida Neto (2009), “a modelagem visa criar um modelo a partir 
de processos por meio da construção de diagramas operacionais sobre o seu comportamento.” 
Os autores listam as principais atividades ou ações necessárias para a otimização através da 
modelagem de novos processos: 
• Obter sugestões dos profissionais que atuam no processo para que contribuam 
na otimização; 
• Eliminar ou modificar as atividades que não agreguem valor ou que sejam 
explicitamente retrabalho; 
• Identificar e implementar melhorias na sequência das atividades, evitando 
repetições ou retrocessos desnecessários; 
• Selecionar e designar o melhor executor para cada atividade; 
• Agrupar as atividades complementares; 
• Transferir as decisões operacionais para o nível do processo 
• Racionalizar os controles mantendo apenas os essenciais 
• Reduzir o tempo da atividade com a substituição do recurso manual por 
máquinas ou sistema informatizado; e 
• Eliminar os pontos de retenção ou gargalos. 
Rotondaro (2008) também propõe questões para a análise crítica das unidades 
funcionais com o objetivo de melhorar as etapas do processo. 
A atividade pode ser suprimida? Deve ser analisado o valor que esta atividade 
agrega para o cliente e o efeito da supressão sobre o processo. 
 48
A atividade pode ser comprimida / acumulada? Um dos benefícios na melhoria do 
processo é o de condensar várias atividades em uma só, principalmente com ferramentas de TI 
adequadas. 
A atividade pode ser feita em um nível hierárquico mais baixo? O uso de 
ferramentas de TI possibilita que funcionários de posições mais baixas executem algumas 
atividades que aconteciam, historicamente, em níveis superiores, pois as informações são 
padronizadas e disponibilizadas adequadamente. 
Atividades em série podem ser executadas paralelamente? É necessário avaliar se 
o encadeamento atual é um requisito do processo e se atividades podem ser iniciadas logo no 
início do processo. Deve-se avaliar, também, se existem gargalos no processo. 
 
3.3 Business Process Modeling Notation (BPMN) 
A modelagem de processos é usada tanto para desenhar e analisar processo quanto 
para desenvolver novos, e deve ser capaz de comunicar uma série de informações aos 
diferentes intervenientes dos processos. 
A literatura apresenta inúmeras técnicas de modelagem de processos, dentre as quais 
se destacam BPMN (Business Process Modeling Notation), UML (Unified Modeling 
Language), IDEF (Integrated Definition), EPC (Event-driven Process Chain), dentre outras. 
Após a análise destas diferentes ferramentas, o autor optou pela utilização do BPMN neste 
trabalho por se tratar de uma das técnicas mais largamente aceitas e de ser uma das mais ricas, 
apesar de sua simplicidade. Almeida Neto (2009) apresenta uma lista de vantagens e 
desvantagens do BPMN: 
• Padronização e gestão feitas pelo OMG, um grupo de empresas-membro, 
consolidadas e com boa reputação no mercado de padrões abertos; 
• Oferece um padrão de notação com suporte em várias ferramentas de 
modelagem; 
• Permite evoluir para o padrão XPDL 2.0, que é explicitamente uma linguagem 
de descrição de workflow; 
• Visando reduzir a lacuna existente entre o desenho de processo de negócio e a 
sua implementação, o BPMN permite a conversão de seus BPD para 
 49
linguagem de execução de processo de negócio BPEL – Business Process 
Execution Language; 
• Incorpora facilidades de técnicas consagradas de padrões de modelagem, como 
UML; 
• Controle dos intercâmbios com o mundo externo da organização através da 
capacidade de enviar mensagens, esperar respostas ou ser interrompido por 
mensagens. 
O BPMN foi desenvolvido pela Business Process Management Initiative (BPMI) e 
sua primeira versão foi lançada em maio de 2004, após mais de dois anos de trabalho da 
BPMI. Segundo White (2005), o objetivo principal do BPMN era fornecer uma notação que 
fosse facilmente compreensível por todos os usuários, desde os analistas de negócio que criam 
os desenhos iniciais dos processos, até as pessoas que irão gerenciar e monitorar os processos 
no cotidiano. O projeto do BPMN objetivava também a criação de um modelo que permitisse 
a geração de softwares sem a necessidade do desenvolvimento de códigos. Assim, o BPMN 
cria uma ponte para o intervalo entre a concepção de processos de negócios e o processo de 
execução. 
 
3.3.1 Elementos básicos 
O BPMN usa a técnica de fluxograma adaptada para a criação de modelos gráficos de 
processos de negócio através do Diagrama de Processos de Negócio (DPN) ou na versão 
original em inglês, Business Process Diagram (BPD). 
Existem apenas três elementos básicos na notação, apresentados no quadro 6. 
 
Quadro 6 – Elementos básicos do BPMN 
ELEMENTO DESCRIÇÃO FIGURA 
Eventos Um evento é representado por um círculo e 
é algo que ocorre no decorrer de um 
processo de negócio. Estes eventos afetam 
o fluxo do processo e normalmente têm um 
disparador ou um resultado. Existem três 
tipos de eventos, baseados em quando eles 
afetam o fluxo: início, meio e fim. 
50
Atividades
Gateways 
 
E tr
 
CONECT
Direção da
sequência 
fluxo 
Direção do
fluxo de 
mensagem
Associação
de elemen
 
Me
uma infinid
entendimen
 
3.3.2 Sw
O c
atividades 
s Uma 
execu
de a
proce
Gatew
para 
intera
rês tipos de 
TOR DESC
a 
do 
É usa
em qu
proce
o 
m 
É usa
entre 
separ
entre 
o 
tos 
É usa
artefa
conec
outpu
esmo com a
dade de mo
nto e usabil
wimlane 
conceito de 
em categor
atividade 
utado no pr
atividade s
esso. 
ways são f
controlar c
age dentro d
Fonte: Ad
conectores
Q
CRIÇÃO 
ado para mo
ue as ativid
esso. 
ado para mo
dois partici
rados que en
si 
ado para ass
atos com ob
ctor é usado
uts de ativid
Fonte: Ad
a aparente 
odelos e pro
lidade um d
swimlanes 
rias separad
represent
rocesso. Os
são tarefa, 
filtros de de
como a seq
do processo
aptado de W
, conforme 
Quadro 7 – T
ostrar a orde
dades devem
ostrar o flux
ipantes do p
nviam e rec
sociar dados
bjetos do flu
o para mostr
dades 
aptado de W
simplicidad
ocessos com
de seus gran
é utilizado 
as para ilus
a um tra
s diferentes 
subproces
ecisão utiliz
quência do 
o. 
White (2005) e 
quadro 7. 
Tipos de conec
em, ou sequ
m ser realiza
xo de mensa
processo 
ebem mens
s, texto e ou
uxo. Este tip
rar inputs e 
White (2005) e 
de destes el
m esta ferram
des diferenc
como um m
trar diferent
balhotipos 
sso e 
zados 
fluxo 
Braconi e Ol
ctores do BPM
uência, 
adas no 
agens 
sagens 
utros 
po de 
Braconi e Ol
lementos bá
menta, send
ciais. 
mecanismo 
tes capacida
liveira (2009)
MN 
FIG
liveira (2009)
ásicos, é po
do esta carac
para organ
ades, divisõ
 
) 
GURA 
) 
ossível con
cterística de
nizar visualm
ões funciona
 
 
 
 
 
nstruir 
e fácil 
mente 
ais ou 
 51
responsabilidades. No BPMN trabalha-se com duas raias principais. Os dois tipos de 
swimlane no BPD são piscina (pool) e raia (lane), conforme figura 10: 
 
Figura 10 – Swimlanes do BPD 
Fonte: Adaptado de White (2005) 
 
3.3.3 Artefatos 
O BPMN foi projetado para permitir que os desenvolvedores de processos tenham 
certa flexibilidade para estender a notação de base, fornecendo a capacidade adicional de 
adequar situação ao contexto específico de modelagem. Podem ser adicionados ao diagrama 
infinitos tipos de artefatos para adequar a notação ao contexto dos processos de negócio que 
são modelados. A versão atual do BPMN pré-define apenas três tipos de artefatos, 
apresentado no quadro 8. 
Quadro 8 – Artefatos do BPMN 
ARTEFATO DESCRIÇÃO FIGURA 
Objeto de 
dado 
Serve para mostrar como os dados são 
requeridos ou produzidos pelas atividades. 
São conectados às atividades através dos 
conectores do tipo associação 
 
Grupo O artefato de grupo não afeta o fluxo do 
processo, mas pode ser usado para fins de 
documentação e análise. 
 
Anotação A anotação serve para que quem modele o 
processo com o BPMN possa fornecer mais 
informações ao leitor do diagrama 
 
Fonte: Adaptado de White (2005) e Braconi e Oliveira (2009) 
Pi
sc
in
a
(p
oo
l)
R
ai
a(
la
ne
)
R
ai
a(
la
ne
)
 52
Os usuários podem criar seus próprios tipos de artefatos que acrescentem mais 
detalhes sobre como o processo é realizado, muitas vezes para mostrar as entradas e saídas 
das atividades no processo. No entanto, a estrutura básica do processo, conforme determinada 
pelas atividades, gateways e conectores, não é alterada com a adição de artefatos no diagrama. 
 
3.4 Método para definição de requisitos 
 
3.4.1 Requisitos do BPMS 
Storch e Pêssoa (2008) propõem uma taxionomia para a avaliação dos requisitos de 
um sistema BPM. Esta taxionomia agrupa funcionalidades para fins de análise de produtos, 
nas categorias de requisitos de um BPMS e é resumida no quadro 9. 
 
Quadro 9 – Taxionomia de requisitos de um BPMS 
 Categoria Comentários 
1 Tecnologia e 
arquitetura de 
software e 
integração com 
outros sistemas 
É a base para as demais categorias de requisitos. 
Incluem os elementos que permitem integrar e entender os 
diversos conjuntos de funções para atender as necessidades 
específicas. 
São críticos os modelos de dados que relacionam processos, 
atividades, pessoas e documentos entre si e os requisitos de 
flexibilidade de suas bibliotecas de funções, orientadas para 
objetos, para atender a cada uma das funcionalidades de workflow, 
ou GED, ou integração com outros sistemas. 
2 Automação de 
fluxos de trabalho 
(workflow) 
Inclui todos os requisitos referentes à tramitação de processos, 
anexação de documentos e formulários de disparos de alarmes e 
notificações. 
Fazem parte desta categoria o controle de tempos de execução, 
tanto de tarefas humanas quanto de tarefas de sistemas, como 
instrumento para o gerenciamento de processos por parte dos 
donos de processos. 
3 Modelagem gráfica 
de processos 
Inclui os requisitos para desenho de fluxos de trabalho, agregados 
às funcionalidades que permitem embutir inteligência nos 
elementos gráficos. 
Esta capacidade deve possibilitar fortalecer o papel dos analistas 
de processos, separando o seu papel dos analistas de sistemas. 
 53
 Categoria Comentários 
4 Recursos para 
gerenciamento dos 
processos 
Inclui o conjunto de requisitos para que os atores do processo com 
acesso permitido às informações dos processos possam monitorar 
o desempenho dos processos, através da visualização do 
cumprimento de suas atividades e dos indicadores de tempo de 
execução e atrasos. 
5 Gerenciamento 
eletrônico de 
documentos e 
conteúdos 
Baseada nos GED inclui as funcionalidades de arquivamento de 
documentos e imagens, a estruturação de sistemas de pastas, a 
atribuição de metadados específicos para cada tipo de documento, 
a recuperação de informações em full text e em metadados, o 
controle de visualização de versões, o armazenamento em 
periféricos específicos. 
Tem papel importante com relação a questões de governança 
corporativa e processo de compliance. 
6 Formulários 
eletrônicos 
Compreende requisitos ligados à criação e uso de formulários em 
meio digital. 
7 Captura, 
processamento e 
impressão de 
documentos 
Inclui requisitos ligados à necessidade de acolher documentos em 
papel, que necessitam de recursos de digitalização por scanner 
para poderem ser convertidos em imagem digital. 
8 Integração e 
interoperabilidade 
com outros 
sistemas 
Poderia estar incluída na primeira categoria, mas é destacada por 
ser um dos elementos que diferenciam o BPMS dos antigos 
sistemas de workflow. 
Compreende os requisitos de aderência aos padrões estabelecidos 
e emergentes para interoperabilidade de sistemas que são aqueles 
que permitem ao BPMS interfacear com os mais diversos 
sistemas. 
9 Segurança lógica e 
garantia de 
privacidade 
Inclui requisitos destinados a assegurar a autenticidade e a 
segurança do acesso a informações e documentos que afetam as 
transações e documentos tratados nas funcionalidades, além do 
registro de todas as transações para garantir rastreabilidade e 
responsabilidade do processo. 
Fonte: Adaptado de Storch e Pêssoa (2008) 
 
3.4.2 Outros requisitos não funcionais 
Os requisitos apresentados acima apresentam tanto requisitos funcionais quanto 
requisitos não-funcionais. No entanto, alguns aspectos tratados na norma ISO-9126, no que 
diz respeito á especificação de requisitos não funcionais, não são tratados na taxionomia 
apresentada no item anterior. 
 54
Os requisitos não funcionais que correspondem a aspectos da qualidade descritos pela 
norma ISO-9126 são apresentados por Paula Filho (2009). Estes requisitos são divididos em 
subcategorias conforme o quadro 10. 
Quadro 10 – Propostas da ISO-9126 para requisitos não-funcionais 
CATEGORIA SUBCATEGORIA DESCRIÇÃO 
Funcionalidade 
Acurácia Correlação dos resultados 
Interoperabilidade Capacidade de interação com outros produtos especificados 
Segurança do 
acesso Resistência ao acesso não autorizado 
Confiabilidade 
Maturidade Frequência de falhas 
Tolerância a falhas Capacidade de operação parcial em presença de 
falhas 
Recuperabilidade Tempo e esforço necessários para restabelecer 
níveis de desempenho especificados 
Usabilidade 
Inteligibilidade Esforço para reconhecimento do conceito lógico 
Apreensibilidade Esforço para aprendizado da operação do produto 
Operacionalidade Esforço para operação do produto 
Manutenibilidade 
Analisabilidade Esforço necessário para diagnosticar problemas 
Modificabilidade Esforço necessário para modificar, adaptar ou 
corrigir problemas 
Estabilidade Riscos de efeitos inesperados por ocasião das 
modificações 
Testabilidade Esforço para validação do produto modificado 
Portabilidade 
Adaptabilidade Capacidade de adaptação a ambientes específicos 
Capacidade para ser 
instalado 
Esforço para instalação em ambiente especificado 
Conformidade Obediência a padrões de portabilidade 
Capacidade para 
substituir 
Esforço para substituir outro produto especificado 
Desempenho