Apostila_do_workshop_Analista_d

Prévia do material em texto

Material do Aluno 
2 Formando Analistas de Negócios 
Observação Importante:
O conteúdo desta apostila é uma versão preliminar de um livro em desenvolvimento. 
Atribuição-Uso Não-Comercial-Compatilhamento pela 
mesma licença 2.5 Brasil
Você pode: 
x copiar, distribuir, exibir e executar a obra 
x criar obras derivadas 
Sob as seguintes condições:
x Atribuição. Você deve dar crédito ao autor original, da forma especificada pelo 
autor ou licenciante.
x Uso Não-Comercial. Você não pode utilizar esta obra com finalidades comerciais.
x Compartilhamento pela mesma Licença. Se você alterar, transformar, ou criar 
outra obra com base nesta, você somente poderá distribuir a obra resultante sob 
uma licença idêntica a esta.
x Para cada novo uso ou distribuição, você deve deixar claro para outros os termos 
da licença desta obra. 
x Qualquer uma destas condições podem ser renunciadas, desde que Você 
obtenha permissão do autor. 
x Nothing in this license impairs or restricts the author's moral rights. 
Termo de exoneração de responsabilidade
Qualquer direito de uso legítimo (ou "fair use") concedido por lei, ou qualquer outro 
direito protegido pela legislação local, não são em hipótese alguma afetados pelo 
disposto acima.
Este é um sumário para leigos da Licença Jurídica (na íntegra).
Versão Draft/Apostila (Jun/07) 3 
Formação para Analistas de Negócios 
Draft 0.5 (18/jun/2007)
Paulo Fernando Vasconcellos Nogueira 
www.pfvasconcellos.eti.br
finito@pfvasconcellos.eti.br
Skype:pfvasconcellos
4 Formando Analistas de Negócios 
Sumário
O Analista de Negócios 7
Entendendo o Negócio 25
Modelando Processos de Negócio 47
Analisando o Negócio 69
Entendendo os Requisitos 81
Desenvolvendo Requisitos 105
Gerenciando Requisitos 143
Viabilizando o Projeto 153
Versão Draft/Apostila (Jun/07) 5 6 Formando Analistas de Negócios 
CAPÍTULO 1 
O Analista de 
Negócios
ƒ Quem é o Analista de Negócios?
ƒ A Formação de um Analista de Negócios 
ƒ Passivo ou Pró-Ativo? 
ƒ Habilidades
à Técnicas
à Sociais
à A Lista do BABoK 
ƒ Responsabilidades
à Em um Projeto 
à Na Organização de TI 
ƒ Analista X Arquiteto de Negócio 
ƒ A Crescente Importância da Função 
Versão Draft/Apostila (Jun/07) 7 
O analista de negócios não existe. No Brasil, a profissão não é regulamentada. Aliás, como quase 
todas as outras do mundo da tecnologia da informação (TI). Mas no caso do analista de negócios
a situação é um pouco pior. Ao contrário dos coordenadores de projetos e analistas de sistemas,
ele também não existe em diversas organizações e projetos.
Quando o analista de negócios existe, não há consenso sobre sua localização: ele é um 
profissional da área de TI ou das diversas áreas de negócio? É tão pequena a experiência de sua 
utilização em projetos para desenvolvimento de sistemas que muitos questionam sua 
necessidade. Para algumas escolas, “superprogramadores” deveriam executar todas as atividades
requeridas em um projeto. Para que serviria um analista de negócios? 
Afinal, não conseguimos definir nem mesmo sua formação e suas responsabilidades em um 
projeto. No BABoK 1 (Guide to Business Analysis Body of Knowledge), por exemplo, o analista 
de negócios praticamente só cuida dos requisitos. Já no RUP temos vários chapéus para ele: 
Analista de Processos de Negócios, Designer do Negócio, Especificador de Casos de Uso etc. 
Como contraponto, o OpenUP/Basic oferece um único boné: Analista. 
Entretanto, parece que a demanda por analistas de negócios tem aumentado nos últimos anos. 
Apesar das indefinições e questionamentos, organizações comprometidas com o alinhamento de 
TI com o negócio depositam parte de suas apostas nas figuras do Analista de Negócios (AN) e do 
Arquiteto Corporativo. Novas ondas, como BPM (Business Process Management) e SOA 
(Service-Oriented Architecture), reforçam a necessidade de profissionais que naveguem com 
desenvoltura os dois lados da moeda: o Negócio e a Tecnologia da Informação. 
Neste capítulo tentaremos definir o perfil, as habilidades requeridas, a formação e as 
responsabilidades de um AN. Veremos também uma sugestão sobre onde devem morar os 
AN's. Ou, colocando de outra forma, quem manda nos AN's. Apesar da ênfase na participação 
do AN em projetos para desenvolvimento de sistemas, veremos que seu perfil e habilidades 
podem ser bastante úteis em outras demandas da organização.
8 Formando Analistas de Negócios 
Quem é o Analista de Negócios? 
O AN é o profissional responsável pela análise de negócios. Segundo o BABoK, a análise de 
negócios é “oo conjunto de tarefas, conhecimentos e técnicas requeridas para a identificação das 
necessidades do negócio e para determinar as soluções para os problemas do negócio. Soluções 
incluem o desenvolvimento de sistemas de informação, mas também podem consistir em 
melhorias dos processos de negócios ou mudanças organizacionais”.
Uma definição tão ampla pode gerar confusão. Vão pensar que “superanalistas” estão sendo 
inventados para brigar contra os “superprogramadores”. O principal problema está no trecho que 
diz que o AN também seria responsável por “determinar as soluções”. Neste livro veremos que 
o AN participa da equipe que cuidará do desenho e implementação da solução, mas não 
determina nada. Não sozinho.
Como a definição do BABoK tende a ser a definição formal e reconhecida, vale a pena destacar 
também a forma como a profissão AN é apresentada: “OO Analista de Negócios funciona como 
uma ligação entre os stakeholders para levantar, analisar, comunicar e validar requisitos de
mudanças em processos de negócios, políticas ou sistemas de informação. O AN entende os 
problemas do negócio e as oportunidades no contexto dos requisitos e recomenda soluções que 
possibilitam que a organização alcance seus objetivos”.
Agora ficou mais claro que o AN “recomenda soluções”, não as determina. Também é 
interessante notar que o trabalho do AN, segundo o BABoK, não se limita a sistemas de 
informação. Melhorias em processos de negócios e mudanças organizacionais também podem 
compor seu escopo de trabalho.
No entanto, na maioria das vezes, o AN é um perfil em um projeto, não uma posição (ou cargo) 
em uma organização. Sendo assim, é comum encontrar improvisações. Coordenadores de 
projetos, donos de produtos e, mais freqüentemente, analistas de sistemas e desenvolvedores 
são destacados para executar as tarefas de coleta e análise de requisitos. Neste livro será 
defendido que o AN seja uma função (cargo) fixo da organização. Justificativas serão apresentadas,
mesmo para empresas ou equipes de pequeno porte. 
Versão Draft/Apostila (Jun/07) 9 
A Formação de um Analista de Negócios 
Até o momento da publicação deste livro, não existia no Brasil um curso reconhecido para a 
formação de AN's. Espera-se que o IIBA2 (International Institute of Business Analysis) seja para os 
AN's o que o PMI3 (Project Management Institute) é para os Coordenadores de Projetos. A 
consolidação de um “corpo” de conhecimentos – no caso o BABoK, possibilitará a criação de 
cursos e de um processo de certificação. Apesar dos questionamentos que giram em torno desse 
tipo de certificação 4, trata-se de um marco que pode ajudar no reconhecimento da função e da 
necessidade do AN pelas organizações. Mas, hoje - quando uma busca no Google retorna 
apenas 14 resultados para BABoK em língua portuguesa – nenhum deles relacionado com o guia 
do IIBA - qual é a formação de um AN? 
Podemos dizer que a formação de um AN é um sub-conjunto ou sub-produto da formação de 
um analista de sistemas. Existem dois problemas que se tornaram mais nítidos nos últimos 
tempos: a ênfase no desenho e documentação da solução e a mistura com disciplinasde 
implementação, como a modelagem de bancos de dados e até mesmo programação. Pouco 
esforço e tempo são destacados para a análise do problema e para os dois principais conjuntos de 
disciplinas que definem o conhecimento de um AN: Engenharia de Requisitos e Modelagem de 
Negócios.
Não é o caso de propor uma alteração nos currículos, até porque os problemas com nossos 
cursos superiores de TI são bem maiores e mais críticos do que uma boa formação de AN's.
Espera-se que, novamente seguindo o exemplo do que ocorreu com os gerentes de projetos, a 
formação de AN's seja oferecida como cursos de extensão, pós-graduação e afins.
Como foi dito anteriormente, o BABoK cobre quase que exclusivamente as atividades de 
gerenciamento, levantamento, análise e negociação de requisitos. Apesar do seu segundo 
capítulo tratar da Análise Corporativa (Enterprise Analysis), pouco se fala sobre a modelagem de 
negócios e de processos de negócios. Desta forma, o AN é posicionado como um profissional 
que se limita a coletar, traduzir e comunicar necessidades. Como veremos no decorrer deste 
livro, o AN pode e deve assumir mais responsabilidades. 
10 Formando Analistas de Negócios
Passivo ou Pró-Ativo?
Quando destacado para ouvir os stakeholders, documentar suas necessidades e traduzi-las para 
uma equipe de desenvolvimento, o AN assume um papel passivo. Colocado apenas como uma 
ponte, não é de se estranhar que muitos questionem sua utilidade. Aliás, em algumas propostas, 
o AN foi simplesmente extinto. Solução encontrada: o cliente ou usuário senta-se ao lado dos 
desenvolvedores. Não é preciso ir muito longe para perceber que se trata de uma prática de 
difícil aplicação. Afinal, quantos usuários-chave podem se dar o luxo de abandonar suas 
atribuições cotidianas durante semanas ou meses? E mesmo que uma flexível agenda seja
montada de forma a viabilizar a prática, até que ponto é salutar a participação do cliente na 
construção de um produto? Quais indústrias já adotaram essa transparência total? E quantos 
clientes pedem por ela? 
Muitas vezes o problema não está na distância (física) entre usuários e desenvolvedores, mas sim 
na comunicação. Tanto em sua forma quanto no conteúdo e na sua freqüência. Nos capítulos 5, 
6 e 7 essas questões são discutidas em detalhes. Neste momento, o que importa é a definição do 
perfil do AN. 
Em muitos projetos, particularmente naqueles que lidam com processos estratégicos ou grandes 
mudanças, um AN pró-ativo pode agregar considerável valor. Um AN pró-ativo caracteriza-se 
por:
ƒ Não se limitar aos requisitos coletados junto aos clientes. Ele pesquisa alternativas, tanto 
na organização quanto em seus concorrentes ou similares; 
ƒ Avaliar e questionar requisitos e processos de negócio, sempre de uma forma construtiva; 
ƒ Antecipar riscos e mudanças; 
ƒ Ter grande capacidade de negociação.
Mas nem sempre um cliente precisa ou aceita a atuação de um palpiteiro. Um bom AN pró-ativo 
é sensível a isso. E tem bom senso. Aliás, é um bom momento para definirmos as habilidades que 
devem fazer parte do arsenal de um AN. 
Versão Draft/Apostila (Jun/07) 11 
Habilidades
Nos acostumamos a dividir as habilidades em dois grandes grupos: i) Habilidades Técnicas (hard
skills); e, ii) Habilidades Sociais (soft skills). “Social” foi o melhor termo que encontrei até o 
momento. Poderia ser também “habilidades pessoais e inter-pessoais”. São tão ruins que é 
grande a tentação de utilizar apenas os termos na língua inglesa. Mas procurarei evitá-los. 
Habilidades Técnicas 
Aprendidas em treinamentos ou adquiridas através da observação e prática. Caracterizam-se por 
serem facilmente repassadas para uma equipe, em relativo curto espaço de tempo.
O quadro abaixo sumariza as principais disciplinas e técnicas que o AN deve dominar. Há uma 
breve descrição de cada uma delas. No restante do livro várias delas serão mostradas de maneira 
mais detalhada. 
Habilidade Descrição
Modelagem Capacidade de transcrever para uma linguagem visual a 
descrição de um problema ou solução. Apesar da 
capacidade de abstração ser uma habilidade soft, o domínio
de linguagens de modelagem é uma habilidade técnica. 
Modelagem de Negócios Habilidade de transcrever em diversas visões e diagramas o 
modelo do negócio.
Modelagem de 
Processos de Negócio 
Derivada da habilidade acima, trata especificamente da 
transcrição de processos de negócio para a forma de 
modelos visuais. O AN deve dominar uma ou mais 
linguagens de modelagem.
Técnicas de Entrevistas 
e Pesquisas 
Domínio de técnicas para a realização ou facilitação de 
entrevistas com stakeholders, workshops, sessões de 
brainstorming e similares.
Tabela 1.1 – Habilidades Técnicas.
12 Formando Analistas de Negócios
Habilidades Sociais 
De transferência mais difícil, são aquelas habilidades que muitos chamam de 'dons'. Muitas 
pessoas nascem com elas ou têm facilidade para desenvolvê-las. Mesmo assim, boa parte delas 
pode ser adquirida através de treinamentos e prática. 
Como este é um livro técnico, não espere dicas sobre como falar em público, facilitar workshops, 
liderar equipes ou escrever bem. No máximo, o texto destacará onde e quando a presença de 
uma pessoa com aquelas habilidades pode facilitar o trabalho. O quadro abaixo apresenta as 
principais habilidades sociais: 
Habilidade Descrição
Observar, Ouvir e 
Entender
Como se diz no popular, “temos dois ouvidos e apenas 
uma boca”. Também temos dois olhos.
Boa parte do trabalho de um AN depende de sua 
capacidade de observação e da sua atenção. 
Comunicar Como o AN é uma “liga” entre stakeholders, é fundamental 
que ele se comunique muito bem, em todas as formas e 
meios. Faz parte da comunicação sua capacidade de 
adequar o vocabulário utilizado de acordo com o perfil do 
seu público-alvo. 
Pensar Sistemicamente É a tal “Quinta Disciplina”5, que consiste em: 
ƒ ver inter-relacionamentos, em vez de cadeias lineares
de causa-efeito; e 
ƒ ver os processos de mudança, em vez de simples fotos 
instantâneas.
Negociar e Vender No meio do caminho, não serão poucas as vezes em que o 
AN terá que vender para um grupo de stakeholders as 
idéias e sugestões de outro grupo. Isso quando não estiver
negociando suas próprias idéias. 
Versão Draft/Apostila (Jun/07) 13 
Criticar e Criar Um AN sem visão ou espírito crítico é quase um garoto de
recados. Ele deve saber criticar requisitos ou processos de
negócio, sempre de forma construtiva. Daí o “criar” 
colocado ao lado do “criticar”. 
Modelar e Organizar O AN deve conseguir traduzir em diversas formas as 
informações que ele coleta. E de organizá-las. Afinal, na 
maioria das vezes, ele receberá conjuntos difusos e 
confusos de dados e informações. Se não agregar nenhum
valor, ele simplesmente estará repassando a bagunça. 
Tabela 1.2 – Habilidades Sociais.
Existem várias outras habilidades sociais, tão ou ainda mais óbvias que as listadas acima, que 
devem marcar o perfil de um bom AN. Saber trabalhar em equipe; saber lidar com a diversidade
cultural que enfrentará; auto-gerenciar seu trabalho; dentre outras. Se cruzarmos a lista com 
aquelas elaboradas para gerentes de projetos, por exemplo, perceberemos uma grande 
similaridade. É que, no final das contas, estamos falando de habilidades que esperamos que todos 
na equipe possuam. 
14 Formando Analistas de Negócios
A Lista do BABoK
O BABoK, ainda incompleto no momento em que este texto era escrito, apresenta uma extensa 
lista de habilidades do AN. A lista ainda carece de uma apresentação detalhada. Mesmo assim, ela 
é parcialmente reproduzida abaixo: 
ƒ Habilidades Básicas 
à Habilidades de Análise 
‚ Técnicas de Análise 
Estruturada(?)
‚ Gerenciamento de 
Problemas
‚ Habilidades de Comunicação 
‚ Habilidades de 
Aprendizagem
‚ Usabilidade
à Conhecimento do Domínio / 
Negócio
‚ Produtos
‚ Processo
‚ Mercados
‚ Sistemas
à Conhecimento de TI 
‚ Paradigmas
‚ Metodologias
ƒ Habilidades Avançadas 
à Gerenciamento de Reuniões 
à Habilidades para Apresentações 
à Habilidades para Tomada de 
Decisões
à Facilitação
à Comunicação
à Resolução de Conflitos 
à Negociação
à Relacionamentos
à Questionamento / Entrevistas
à Pensamento Sistêmico 
à Lógica
à Amplitude Cultural
ƒ Habilidades de Liderança 
à Arquitetura de TI 
ƒ Habilidades Periféricas 
à Vendas
Versão Draft/Apostila (Jun/07) 15 
Responsabilidades
Se o AN é dotado de todas as habilidades e conhecimentos apresentados no capítulo anterior, 
onde, como e quando ele pode ser melhor aproveitado pela organização? Outra questão que
tentaremos responder neste tópico é: quem gerencia o trabalho do AN? Dúvida relevante, 
particularmente naqueles momentos em que o AN não está alocado em nenhum projeto. A 
resposta mais fácil para o primeiro grupo de perguntas diz respeito aos projetos. Trata-se da 
forma que está melhor documentada.
Em um Projeto 
As responsabilidades de um AN em um projeto podem variar bastante. Dependem muito do 
tipo de projeto e da metodologia utilizada. Entretanto, de uma maneira geral podemos dizer que 
o AN recebe as seguintes atribuições: 
ƒ Análise e Modelagem do Negócio: compreende a assimilação do negócio, de uma forma 
geral e dos problemas específicos que o projeto deve solucionar. Normalmente a 
complexidade e abstração do negócio devem ser simplificadas e traduzidas na forma de 
modelos. Os capítulos 2, 3 e 4 tratarão especificamente deste conjunto de atividades. 
ƒ Engenharia de Requisitos: envolve desde o planejamento das atividades de coleta até a 
validação e documentação dos requisitos. Por documentação devemos entender a 
confecção de modelos que devem facilitar o entendimento do projeto pela equipe de 
construção. Este grupo é estudado em detalhes nos capítulos 5, 6 e 7. 
Reparem que os dois grupos de atividades acima não se limitam a projetos para desenvolvimento 
ou implantação de sistemas de informação. São atividades requeridas em qualquer tipo de 
projeto que envolva a implementação de mudanças em processos de negócios. O grupo que 
trata dos requisitos também é utilizado, de maneira isolada, no desenvolvimento de novos 
produtos ou serviços. 
Um AN pode ser melhor aproveitado em projetos. Limitando-o aos dois grupos de atividades 
listados acima, damos a impressão de estarmos adotando um processo de desenvolvimento
baseado no modelo waterfall (cascata). Considerações acerca do modelo do ciclo de vida 
16 Formando Analistas de Negócios
adotado para o projeto serão apresentadas posteriormente. Neste ponto é preciso destacar que 
um AN também pode assumir as seguintes atribuições em um projeto: 
ƒ Validação e Viabilização do Projeto: com o correto domínio do negócio e suas necessidades,
é factível supor que o AN pode dar uma grande contribuição na validação e viabilização de 
um projeto. Produtos desta etapa podem ser: estudo de viabilidade; solicitações de propostas 
(ou RFP's – Request for Proposal); propostas técnicas e comerciais. O capítulo 8 trata deste 
assunto.
ƒ Gerenciamento de Mudanças: trata-se de uma responsabilidade que deve ser compartilhada 
por todos os membros da equipe de projeto. Mas as contribuições do AN, particularmente 
quando este estiver representando os interesses dos demais stakeholders, não podem ser 
desconsideradas. Esta responsabilidade, em conjunto com o gerenciamento dos requisitos, é 
estudada no capítulo 6. 
Quando o projeto envolver, em algum nível, o redesenho (ou reengenharia6) de processos de 
negócios, o AN também pode ser destacado para executar: 
ƒ Modelagem de Processos de Negócio: gerando modelos mais ricos em detalhes do que 
aqueles gerados na modelagem do negócio (acima). Além dos projetos de reengenharia de 
processos de negócios (BPR – Business Process Reengineering6), iniciativas como BPM 
(Business Process Management7) e SOA (Services-Oriented Architecture8) também devem 
requerer a execução deste conjunto de atividades. Este tema é abordado no capítulo 3. 
ƒ Análise do Negócio: seqüência natural das atividades acima. Envolve a avaliação dos 
processos de negócio de acordo com vários critérios e indicadores. É normal que este 
conjunto de atividades seja executado por um consultor de negócios. No entanto, um AN 
bem preparado e experiente pode se responsabilizar por elas, pelo menos parcialmente.
Maiores detalhes no capítulo 4. 
Todo o conhecimento absorvido pelo AN deve estar disponível para a equipe de 
desenvolvimento durante todo o ciclo de vida do projeto. Desta forma ele substitui os usuários, 
configurando-se uma alternativa para aquela sugestão comentada anteriormente neste capítulo. E, 
de uma forma mais freqüente, o AN participa do desenho e implementação da solução, 
conforme é mostrado no capítulo 9. 
Versão Draft/Apostila (Jun/07) 17 
Figura 1.1 – Modelo de equipe de projeto.
O diagrama acima mostra um modelo para formação de uma equipe de projeto de 
desenvolvimento. Ele mostra a posição do AN em relação aos demais membros da equipe.
Clientes e usuários, se presentes, estariam no lado esquerdo do diagrama. Desta forma 
indicamos que o relacionamento com todos os demais stakeholders é responsabilidade do 
gerente do projeto, do arquiteto e do AN (Negócio). O que não significa, obviamente, que o 
restante da equipe nem conhece a cara do freguês.
O diagrama também ilustra que o AN está no mesmo nível de todos os demais membros da 
equipe de construção. Responde, como os demais, para um gerente e para o arquiteto. Trata-se 
de uma proposta que valoriza a especialização9. No capítulo 9 falaremos um pouco mais sobre a 
convivência do AN em uma equipe de projeto. 
18 Formando Analistas de Negócios
Na Organização de TI 
Se estiver subordinado ao gerente de TI, o AN pode acabar de transformando num excelente RP 
(relações públicas) para o departamento. Afinal, na maior parte do tempo, ele estará se 
relacionando com todas as outras áreas da empresa. Daí a criticidade das habilidades pessoais e 
inter-pessoais apresentadas anteriormente. É fundamental que o AN transite com desenvoltura
por toda a empresa.
No entanto, dados o conhecimento que este profissional deve ter do negócio e a possível 
amplitude de seu escopo de atuação, podemos supor que acontecerá com ele o mesmo que 
ocorreu com os gerentes de projetos. Seu deslocamento para um pool relativamente 
independente.
No caso dos gerentes de projetos, foram criados os escritórios de projetos (PMO – Project
Management Office). Não é o caso de propor a criação de “escritórios de análise de negócios” 
(algo como BAO – Business Analysis Office). Não se justifica. Talvez seja mais fácil supor um 
redesenho dos PMO's - uma evolução natural. 
Na realidade, se gerenciados pela própria área de TI, esses escritórios poderiam se transformar
em um núcleo de especializações. Seu desenho seria idêntico àquele apresentado na figura 1.1.
Talvez devêssemos incluir “Operações” logo abaixo do “Arquiteto”. Cada especialização contaria 
com um “dono”. Além de atender as demandas por profissionais, este “super-escritório de 
projetos” teria duas grandes responsabilidades: 
ƒ Promover o aprendizado contínuo; 
ƒ Avaliar todos os projetos e solicitações das outras áreas da empresa.
Mas este é um tema que foge do escopo deste livro. Resta apenas reafirmar a certeza de que os 
PMO's podem ser muito mais eficazes se não ficarem limitados apenas a treinar e “fornecer” 
gerentesde projetos. A inclusão dos AN's pode ser um primeiro passo. 
Versão Draft/Apostila (Jun/07) 19 
Analista X Arquiteto de Negócio 
O termo “arquiteto de negócio” ou “arquiteto corporativo” (Enterprise Architect 10) não é assim 
tão novo, mas, nos últimos tempos, vem ganhando espaço na mídia. Seria um novo artifício à 
disposição das organizações para a promoção do alinhamento estratégico de TI com o negócio. É 
uma figura ainda raríssima nas organizações, particularmente nas brasileiras. A novidade ainda gera 
discussões básicas. Por exemplo, o arquiteto de negócio deveria pertencer à área de TI? 11
Naquele “super-PMO” sugerido acima, todos os membros, com exceção dos gerentes de 
projeto, seriam “arquitetos”. Teríamos então: 
ƒ Arquiteto de Negócios ou Arquiteto Corporativo 
ƒ Arquiteto de Serviços (Arquiteto SOA) ou de Aplicações 
ƒ Arquiteto de Informações
ƒ Arquiteto de Tecnologia 
A intenção com a nomenclatura nem é tanto diferenciá-los dos engenheiros, mas enfatizar que 
esse grupo cuida da manutenção da integridade arquitetônica de tudo o que se refere a TI. Daí a 
discussão em torno da correta localização do arquiteto de negócios. Sendo sua principal 
responsabilidade a ligação da área de TI com o restante da empresa, faz sentido que ele responda 
diretamente para o gerente ou diretor de TI. 
O cargo de arquiteto de negócios seria então uma possível evolução do AN12. Apesar de parecer 
um caminho natural, ainda é cedo para dizer se isso realmente acontecerá nas empresas. 
20 Formando Analistas de Negócios
A Crescente Importância da Função 
Houve um tempo em que a área de TI parecia totalmente independente do negócio. Um tipo de 
caixa-preta que era tida como um mal necessário. As coisas começaram a mudar na medida em 
que TI deixou de ser um mero fornecedor de relatórios. As coisas ganharam tons de criticidade 
quando TI passou a ser percebida como um potencial gerador de vantagens competitivas. As 
linhas entre o negócio e a tecnologia foram desaparecendo, forçando que ambos os lados
aprendessem “na marra” uma forma de conviver pacificamente. E, mais importante, 
produtivamente.
Foi no meio da transição que reparamos quanta diferença existia entre os dois mundos: 
vocabulário, objetivos e metas, estilo gerencial, senso de urgência, noção de certo e errado, 
hobbies, gosto culinário etc. Tudo era muito diferente. Natural que conflitos brotassem em todos 
os cantos, a todo momento.
Para complicar, os prazos dos projetos ficaram mais curtos. Assim como a paciência dos usuários. 
Em um ambiente de hiper-competição não é fácil justificar “um delay de 2 semanas”, que vez por 
outra viram 2 meses, 2 anos. Em muitos casos, não se trata do usuário esperar. Acontece que o 
mercado não espera. Ou seja, se TI não se converteu num centro de lucros, com certeza ela é, 
para a maioria das organizações, um grande risco de prejuízos e oportunidades perdidas.
É por isso que 8 em cada 10 produtos ou serviços lançados no mercado de computação 
corporativa prometem promover ou facilitar o alinhamento estratégico de TI com o negócio.
Promessas que raramente são cumpridas. Não porque sejam desonestas. Na maioria das vezes 
elas realmente poderiam ajudar TI a se aproximar de seus usuários. O problema costuma estar 
na própria estrutura de TI, na sua falta de padrões e processos. 
Nasceram nesta década duas propostas que podem promover consideráveis mudanças (positivas) 
no relacionamento de TI com o negócio. BPM7, ou Gestão de Processos de Negócio, é descrita
na Wikipedia7-1 como “um campo do conhecimento que fica na inserção entre o gerenciamento
e TI, compreendendo métodos, técnicas e ferramentas para o desenho, implementação,
controle e análise de processos de negócio operacionais que envolvem pessoas, organizações, 
aplicações, documentos e outras fontes de informação. O termo 'processos de negócio 
Versão Draft/Apostila (Jun/07) 21 
operacionais' refere-se a processos repetitivos executados pelas organizações no seu dia-a-dia,
diferentes dos processos de tomadas de decisão que são executados pelo alto escalão”. 
BPM não se limita a fornecer meios para o gerenciamento de processos de negócio. Quando 
necessário, ela possibilita também a melhoria dos processos. Seus propositores costumam 
enfatizar que se trata de um enfoque diferente daquele proposto pela reengenharia de processos
de negócio6. Enquanto a reengenharia sugeria, de certa forma, uma “revolução” - o redesenho 
do zero dos processos, BPM aposta na contínua “evolução” dos processos. Mais sobre este 
assunto será tratado nos próximos capítulos. 
A outra proposta que aproxima TI do negócio é SOA8, ou Arquitetura Orientada a Serviços. 
Segundo a Wikipedia (em 10/mai/200713), ainda não há consenso sobre a definição do termo. 
Sigo defendendo uma que registrei em um artigo de julho/200514: “SOA é uma estratégia que 
propõe a organização dos ativos de software de forma que eles possam representar Processos, 
Atividades ou Tarefas de Negócio de forma direta. Tais representações são chamadas de 
Serviços, que devem ser baseados em padrões e facilmente combinados e reutilizados visando a 
satisfação dos requisitos do negócio.” 
A representação direta de processos e atividades de negócio, proporcionada por uma SOA, 
significa inclusive a adoção, sem restrições, do vocabulário do negócio. Em um cenário ideal, ao 
enxergar a SOA em funcionamento, o usuário estaria enxergando uma clara representação do 
negócio. Uma representação viva. Não é necessário dizer que a realidade ainda está muito 
distante desse cenário. Mas a ambição é positiva – o alvo está correto.
BPM e SOA são duas propostas independentes. Mas são totalmente complementares. Apesar de 
não depender ou exigir a existência de uma SOA, uma iniciativa BPM seria muito favorecida com 
sua existência. Isso porque todos os blocos de construção requeridos por ela, os processos de 
negócio e suas subdivisões, estariam disponíveis de uma forma flexível e bastante inteligível. SOA 
e BPM apresentam outra semelhança, mais relevante no contexto deste livro: ambas requerem 
um trabalho de (re)desenho e modelagem do negócio e seus processos. Ou seja, as duas 
iniciativas são bastantes favorecidas pela atuação de AN's. Em outros trechos deste livro serão 
destacadas particularidades e requisitos das duas propostas. 
22 Formando Analistas de Negócios
Notas, Bibliografia e Referências 
1. GGuide to Business Analysis Body of Knowledge – Version 1.6 Draft
IIBA (International Institute of Business Analysis), 2006 
2. IIIBA (International Institute of Business Analysis
http://theiiba.org
3. PPMI (Project Management Institute)
http://www.pmi.org
4. Nota sobre Certificações!
5. AA Quinta Disciplina
Peter M. Senge. Editora Best Seller, 2000. 
6. Nota sobre Reengenharia!
7. BBPM (Business Process Management)
http://en.wikipedia.org/wiki/Business_Process_Management
8. Nota sobre SOA 
9. Nota sobre Especialização 
10.DDef Arquiteto de Negócio
http://en.wikipedia.org/wiki/Enterprise_architect
11.DDiscussão sobre Arquiteto de Negócio
http://knowledgecrisis.blogspot.com/2006/09/business-architecture-
anyone.html
http://knowledgecrisis.blogspot.com/2006/11/business-architect-whatever.html
12.FFrom Business Analyst to Business Architect 
http://blogs.ittoolbox.com/bi/analyst/archives/advance-from-business-analyst-
to-business-architect-13686
13.DDefinição de SOA na Wikipedia 
http://en.wikipedia.org/wiki/Service-oriented_architecture
14.LLet's Talk About SOA
http://finito-log.blogspot.com/2005/07/soa-1-introduo.html
Versão Draft/Apostila (Jun/07) 23 
Notas
24 Formando Analistas de Negócios
CAPÍTULO 2 
Entendendo
o Negócio 
ƒ Conceitos Básicos 
ƒ A Estratégia e os Planos 
ƒ Modelagem de Negóciosà A Composição de um Modelo de Negócio 
ƒ Utilizando a UML para a Modelagem de Negócios
ƒ A Visão do Negócio 
à Representando a Estratégia 
ƒ A Visão da Estrutura do Negócio 
Versão Draft/Apostila (Jun/07) 25 
Negócio (do latim, negotiu) é definido em vários dicionários como “comércio; transação 
comercial; tráfico; empresa; contrato; qualquer assunto que envolve lucro ou interesse; qualquer 
coisa”. Na língua inglesa chamamos de business. Na Wikipedia1, tratando de economia, business
é definido como “a ciência social do gerenciamento de pessoas para organizar e manter 
produtividade coletiva de forma a satisfazer objetivos, geralmente para gerar lucros”.
Para simplificar, vamos adotar a seguinte definição: NNegócio é toda entidade, pública ou privada, 
que visa atender seus clientes através do fornecimento de produtos e / ou serviços.
O negócio, qualquer negócio, é a matéria-prima do trabalho do AN. E mesmo que a diversidade
dos negócios seja quase infinita, é possível elencar um conjunto de fatores comuns que permitem 
que o AN atue em qualquer tipo de negócio, em qualquer ramo de atividade. Todo negócio tem 
uma razão para existir – uma Razão Social. Inserido num ambiente composto de clientes, 
concorrentes, fornecedores e parceiros, o negócio executa uma estratégia. Ele possui uma 
estratégia, mesmo que ela seja informal e mal conhecida. Por fim, todo negócio possui objetivos, 
recursos, processos e regras. E nenhum negócio está livre de problemas. 
Conhecer o negócio e o ambiente que o cerca é pré-requisito para que o AN execute um bom 
trabalho. Mesmo quando sua atuação é pontual em um pequeno projeto, o conhecimento sobre 
o negócio em questão pode ser importante ou até mesmo crucial. E quando o AN atende sua 
empresa, e não projetos para terceiros, é fundamental que ele domine todo o negócio. Trata-se 
de um processo de aprendizado que não acaba. Afinal, o negócio é um organismo vivo. Uma 
entidade dinâmica que influencia e é influenciada pelo ambiente que a cerca.
Neste capítulo veremos quais são os elementos fundamentais que definem um negócio. 
Estudaremos também os conceitos básicos da modelagem de negócios. E veremos como a 
UML2 (Unified Modeling Language) pode ser utilizada para representar todos os elementos que 
compõem um negócio. 
26 Formando Analistas de Negócios
Conceitos Básicos 
Na legislação brasileira, todo negócio possui uma Razão Social. Na maior parte das vezes, esse
atributo é utilizado apenas para exprimir o nome oficial da empresa. Mas, quando foi criada e nas 
vezes em que ela é bem utilizada, a razão social diz qual é a principal motivação do negócio, qual 
a sua razão de existir. Toda empresa também é obrigada a formalizar seu ramo de atuação3.
Normalmente, essas são as duas primeiras informações que o AN recebe sobre um negócio.
Nenhum negócio é um fim em si mesmo. Ele existe para prover produtos ou serviços para uma 
comunidade. E pode depender de outros negócios, fornecedores e parceiros, para cumprir seus 
objetivos. O negócio deve operar de acordo com normas e leis fixadas por entidades externas. 
Portanto, quando falamos em “análise de negócios”, estamos nos referindo ao trabalho de
estudar e apoiar todo um ambiente, e não apenas uma empresa. É esperado que o AN tenha
sempre essa visão ampla do negócio.
Todo negócio é único, mas existe um conjunto de conceitos básicos que podemos utilizar para 
representar as estruturas e operações de qualquer tipo de empresa. O quadro abaixo apresenta 
os 4 conceitos fundamentais4:
Conceito Descrição
Recursos É tudo o que a empresa utiliza, consome ou produz. São as 
pessoas, materiais, informações e produtos. Recursos são 
manipulados através de processos. E podem ser categorizados 
como: recursos físicos, abstratos e de informação. 
Processos São as atividades realizadas pelo negócio. Eles descrevem como 
o trabalho é executado na empresa, e são delimitados por regras. 
Regras Definições ou restrições de algum aspecto do negócio. Regras 
determinam como um negócio deve ser gerenciado ou como os 
recursos são estruturados. Elas podem ser criadas na própria 
empresa ou ser impostas por entidades externas.
Versão Draft/Apostila (Jun/07) 27 
Objetivos Representam a razão da empresa, ou os resultados que o 
negócio como um todo espera atingir. Objetivos podem ser
divididos em objetivos mais específicos ou metas, que são 
distribuídos entre os processos da empresa. Objetivos expressam 
o estado desejado de determinados recursos, e são atingidos 
através dos processos.
O conjunto dos objetivos de alto nível (e de médio e longo prazos) 
é compilado para formar a estratégia da empresa.
Tabela 2.1 – Conceitos Básicos que definem um Negócio.
Esses 4 conceitos se inter-relacionam para fechar a definição de um negócio. De uma forma 
simplificada, podemos dizer que: Os objetivos do negócio são atingidos através da execução de 
processos que usam, transformam e geram recursos, sempre respeitando e seguindo um
conjunto de regras. 
O diagrama abaixo representa graficamente os relacionamentos entre os quatro conceitos:
Figura 2.1 – Meta-modelo dos Conceitos Básicos do Negócio.
28 Formando Analistas de Negócios
A Estratégia e os Planos 
Como vimos no primeiro capítulo, o AN é convocado para atuar quando a empresa inicia um 
processo de mudança em seus processos, estruturas ou sistemas de informação. Toda mudança 
tem uma motivação e esta normalmente é expressa na forma de um plano. O formato do plano 
pode mudar consideravelmente de empresa para empresa. Do papel de pão até sofisticados 
sistemas que implementam o Balanced Scorecard 5.
Mudanças de médio ou grande porte podem significar alterações na estratégia da empresa. Ou 
seja, alterações nos grandes objetivos. Por isso, além de conhecer os 4 elementos básicos que 
definem o negócio, o AN também deve conhecer a estratégia da empresa. No mínimo, a parte 
da estratégia que gerou as necessidades de mudanças que motivaram o seu envolvimento no 
projeto. Torna-se importante, então, que criemos uma visão comum do que é uma estratégia e 
como ela é apresentada.
Estratégia, segundo a Wikipedia 6, “é um plano de ações de longo prazo desenhado para atender 
um objetivo específico”. Quando falamos de estratégia no mundo dos negócios a coisa se 
complica um pouco. Segundo alguns dos maiores especialistas na área, não há uma definição clara 
para o termo “estratégia de negócio” 7. Existiriam cinco definições (e uma dezena de escolas): 
ƒ Estratégia é um plano (é pretendida); 
ƒ Mas também é um padrão – “uma consistência em comportamento ao longo do tempo”7
(realizada);
ƒ Estratégia é uma posição, ou “a criação de uma posição única e valiosa”8;
ƒ Mas também uma perspectiva, ou seja, “a maneira fundamental de uma organização fazer as 
coisas”7;
ƒ E, por fim, estratégia também pode ser um truque, uma manobra específica para enganar os 
concorrentes.
Versão Draft/Apostila (Jun/07) 29 
Robert Kaplan e David Norton, criadores do balanced scorecard e dos mapas estratégicos, são 
mais práticos9: “A estratégia de uma organização descreve como ela pretende criar valor para 
seus acionistas, clientes e cidadãos”. E afirmam que “a estratégia baseia-se em proposição de valor 
diferenciada para os clientes”.
Uma proposição de valor nítida seria, para os dois autores, a dimensão mais importante da 
estratégia. E existiriam apenas quatro grandes proposições de valor: 
ƒ Baixo custo total; 
ƒ Liderança do produto (Inovação); 
ƒ Soluções completas; e 
ƒ Aprisionamento.
Qual a importância disso tudo no contexto daqueles 4 conceitos básicos apresentados no início 
deste capítulo? Acontece que o perfil estratégico da empresa, sua proposição de valor:
ƒ Determina o desenho deseus processos de negócio. Afinal, é através deles que ela cria valor; 
ƒ Influencia diretamente a forma como ela administra seus recursos; 
ƒ Caracteriza suas regras de negócio; e 
ƒ Direciona seus objetivos e metas. 
O assunto é espinhoso, complexo. E o AN não precisa ser um especialista em estratégias para 
compreender a visão de futuro de uma empresa. No contexto de um projeto específico, o mais 
importante é que o AN entenda as motivações da empresa: 
ƒ Por que o projeto é necessário? 
ƒ Quais mudanças ele implementa? Quem ele afeta? 
ƒ Quais objetivos de negócio ele deve satisfazer? 
ƒ E como esses objetivos contribuem para a realização da estratégia da empresa?
30 Formando Analistas de Negócios
Modelagem de Negócios 
O detalhamento de todos os elementos que compõem um negócio (Objetivos, Processos,
Recursos, Regras e a Estratégia) é uma atividade extremamente complexa. Modelamos um 
negócio com o objetivo de simplificá-lo – de facilitar sua compreensão. Criamos abstrações ou 
analogias de uma forma que facilite a documentação e a comunicação de todos os aspectos do 
negócio. A lista abaixo apresenta outras justificativas para a modelagem de negócios 4:
ƒ Fornecer uma base que apóie a criação de sistemas de informação; 
ƒ Criar um ponto de partida para iniciativas de melhoria da estrutura e dos processos de 
negócios;
ƒ Experimentar novos conceitos e desenhos;
ƒ Identificar oportunidades de outsourcing.
Tratando especificamente de projetos de sistemas de informação, podemos fixar que a 
modelagem de negócios serve para 12:
ƒ Entender a estrutura e a dinâmica da organização; 
ƒ Garantir que clientes, usuários e desenvolvedores compartilham uma mesma visão do 
negócio; e 
ƒ Compreender como a entrega de novos sistemas pode melhorar a produtividade da 
empresa e como os sistemas em uso serão afetados. 
Versão Draft/Apostila (Jun/07) 31 
Como afirmam Eriksson e Penker 4 , “se os requisitos são baseados em um bom modelo de 
negócios, há uma chance muito maior do sistema de informação suportar o negócio
adequadamente”. Podemos destacar outras vantagens obtidas com a modelagem do negócio 4:
ƒ sistema de informação fica mais aderente ao negócio, melhor alinhado; 
ƒ Torna-se mais fácil a integração de sistemas;
ƒ custo de manutenção dos sistemas é reduzido, já que o melhor alinhamento deve significar
mais flexibilidade e facilidade para implementação de mudanças; 
ƒ A lógica do negócio pode ser reutilizada em vários sistemas. 
A Composição de um Modelo de Negócio 
Um modelo de negócio é composto por três partes principais, apresentadas no quadro abaixo 4: 
Parte Descrição
Visões É impossível descrever completamente um negócio sob um 
único ponto de vista. Portanto, um bom modelo de negócio é 
composto por várias Visões (ou Views).
Existem 4 categorias de visões: 
ƒ Visão do Negócio: visão geral do negócio, que inclui sua 
estratégia.
ƒ Visão dos Processos: representa toda a parte dinâmica 
da empresa. 
ƒ Visão da Estrutura: representa a organização de todos os 
recursos utilizados, manipulados e gerados pelo negócio. 
ƒ Visão do Comportamento: o comportamento individual
de determinado processo ou recurso. 
Toda visão é representada por um ou mais diagramas. 
32 Formando Analistas de Negócios
Diagramas Representam partes específicas da estrutura ou da 
dinâmica do negócio. Diagramas contém ou expressam os 
objetivos, processos, recursos e regras do negócio. 
Objetos e Processos São todos os itens representados nos diagramas. Objetos
representam todos os recursos, enquanto os processos 
representam qualquer atividade ou função executada no 
negócio.
Tabela 2.2 – A composição de um Modelo de Negócios.
Utilizando a UML para a Modelagem de Negócios 
A UML (Unified Modeling Language)2 foi criada para servir como um padrão de notação para a 
modelagem de sistemas orientados a objetos (OO10). Lançada em 1997, encontra-se em sua 
segunda versão. Uma das principais características da linguagem é sua extensibilidade. Ou seja, ela 
pode ser incrementada e modificada para utilização em domínios mais específicos.
Uma das primeiras e mais relevantes extensões para a UML disponibilizada trata exatamente da 
utilização da UML para a modelagem de negócios. Chama-se EPBE (Eriksson-Penker Business 
Extensions) e foi publicada no livro Business Modeling with UML4 , de Hans-Erik Eriksson e 
Magnus Penker. Os autores justificam a utilização da UML para a modelagem de negócios: 
ƒ “CConceitos Similares: um negócio pode ser descrito em termos de processos que satisfazem
objetivos através da colaboração de diferentes tipos de recursos. Regras definem condições e 
restrições sobre como os processos e recursos devem se relacionar e como devem se 
comportar. Tudo isso pode ser mapeado em objetos, relacionamentos entre objetos e 
interações entre objetos.”
ƒ Técnicas Maduras: já é comprovado que a OO pode lidar com sistemas grandes e 
complexos.
ƒ Notação Padrão: UML serviu para padronizar a linguagem de modelagem utilizada em OO. 
A modelagem de negócios carece de um padrão. UML é muito indicada já que promoveria 
Versão Draft/Apostila (Jun/07) 33 
também a adoção de uma mesma linguagem para o estudo dos problemas e para o desenho
das soluções. 
ƒ Aprendizado Rápido: Os mesmos conceitos básicos utilizados para descrever sistemas de 
informação (objetos, classes, etc) podem ser usados para a modelagem do negócio.
ƒ Novas maneiras de ver o Negócio: o uso da UML é mais uma forma de fazer com que as 
organizações entendam que, mais do que os organogramas, o que as define são os seus 
processos. (Mais sobre essa discussão no próximo capítulo). 
No restante deste livro serão apresentados diversos exemplos do uso da UML para representar 
conceitos do negócio. Neste momento vamos apenas conhecer os principais tipos de diagramas,
seu uso e principais elementos. 
Diagrama de Classes 
Os diagramas de classes são utilizados, principalmente, para a representação de recursos e dos 
objetivos e metas da organização. Também são utilizados para o desenho de um modelo 
conceitual do negócio. Abaixo o exemplo de um diagrama de classes:
Figura 2.2 –Diagrama de Classes.
34 Formando Analistas de Negócios
Diagrama de Atividades 
A EPBE propõe duas versões adaptadas do diagrama de atividades: o Diagrama de Processos 
(que representam diretamente um processo de negócio ou workflow11); e o Diagrama de Linha 
de Montagem (ou Assembly Line, útil para demonstrar como os recursos são manipulados e 
gerados durante a execução dos processos). Os exemplos abaixo apresentam as duas variações 
do diagrama de atividades, além de um desenho tradicional, baseado unicamente na UML 2.0: 
Figura 2.3 – Variações do Diagrama de Atividades.
Diagramas de Estado, Seqüência e Comunicação
Os Diagramas de Estado, Seqüência e Comunicação são utilizados para representar a Visão do 
Comportamento do negócio. Enquanto os diagramas de atividades representam o 
comportamento geral de um processo, os diagramas de seqüência, colaboração e estado são 
úteis para a análise do comportamento individual de um recurso (objeto) ou processo. Os 
diagramas de estado são particularmente úteis para a representação da transição de estado que 
Versão Draft/Apostila (Jun/07) 35 
ocorre em determinado recurso (objeto). Já os diagramas de seqüência e colaboração servem 
para que possam ser modeladas as interações entre recursos e processos. Como esta também é 
uma responsabilidade dos diagramas de atividades, é importante notar que utilizamos os 
diagramas de seqüência e colaboração para expor detalhes que normalmente não são 
representados naqueles. Abaixo exemplos dos três diagramas: 
Figura 2.4 – Diagramas de Seqüência, Comunicaçãoe Estado.
Variações do Uso da UML 
O enfoque da EPBE no uso da UML para a modelagem de negócios é bastante diferente de
outras alternativas, particularmente daquela apresentada no RUP (Rational Unified Process13) e 
em títulos como Managing Software Requirements – A Use Case Approach12. Nestes prega-se o 
uso da UML de uma forma mais tradicional. Os dois principais diagramas gerados nas atividades 
de modelagem de negócio seriam o Diagrama de Casos de Uso e o Diagrama de Objetos de 
Negócios. O diagrama abaixo mostra o uso desses diagramas e seu relacionamento com outros 
artefatos gerados em outro momento no ciclo de vida de um projeto.
36 Formando Analistas de Negócios
Figura 2.5 – Outra visão do uso da UML para a modelagem de negócios.
Esses diagramas não oferecem todos os recursos necessários para o completo mapeamento do 
negócio e seus principais elementos. Isso não quer dizer que eles não sejam úteis. Os diagramas
de casos de uso, como veremos no capítulo 6, são bastante úteis para guiar e auxiliar na 
documentação dos requisitos funcionais de um sistema. Mas eles não agregam praticamente nada 
para a modelagem de negócios, e por isso não fazem parte da EBPE. Já os diagramas de objetos
de negócios são substituídos neste momento pelos diagramas de classes devidamente 
customizados, como foi apresentado anteriormente. A correta representação da estrutura dos 
recursos, objetivos e regras requer vários diagramas distintos, e não apenas um diagrama de 
objetos de negócios. 
Versão Draft/Apostila (Jun/07) 37 
A Visão do Negócio 
A construção da visão do negócio é o ponto de partida para todas as outras atividades de 
modelagem do negócio. É nela que documentamos a estratégia da empresa, seus principais 
objetivos e problemas. Se o escopo do trabalho do AN for um projeto específico, então ele
desenvolverá neste momento um documento que normalmente é chamado de Business Case – 
uma apresentação executiva das motivações do projeto. Este trabalho será tratado em detalhes 
no capítulo 8. Aqui veremos a descrição geral da visão do negócio, desenvolvida de maneira
independente dos projetos.
A descrição da visão do negócio deve contemplar os seguintes fatores4:
Fator Descrição
Missão Os grandes objetivos da empresa. 
Objetivos Objetivos e metas mais específicos, que podem ser 
mensurados em determinado intervalo de tempo.
Forças Os pontos fortes (diferenciais) do negócio. 
Fraquezas Os pontos fracos da empresa. 
Oportunidades Áreas em que a empresa pode obter considerável vantagem 
competitiva.
Ameaças Áreas de atuação que podem ser afetadas de forma negativa 
por fatores externos (concorrência, legislação, novas 
tecnologias, etc.) 
Fatores Críticos Requisitos do negócio que devem ser atendidos para que os 
objetivos sejam atingidos, as oportunidades sejam aproveitadas
e as ameaças não se concretizem.
Estratégias Planos para que os objetivos sejam atingidos. 
Competências
Principais
Áreas mais importantes do negócio. 
Perfis As funções que as pessoas executam na empresa. 
38 Formando Analistas de Negócios
Unidades de Negócio Departamentos e demais grupos que formam a estrutura da 
empresa.
Processos-Chave Os principais processos de negócio da empresa, que 
normalmente são chamados de Core Business. 
Tabela 2.3 – Principais fatores que descrevem a Visão do Negócio.
É possível desenvolver um grande modelo conceitual que represente todos os fatores listados 
acima. No entanto, a probabilidade dele ficar poluído – de difícil leitura - dado o grande volume 
de informações, deve ser considerada. Como veremos no capítulo seguinte, os processos-chave 
devem ser documentados em um diagrama específico. O organograma da empresa, que pode 
ser uma nova versão construída através do diagrama de classes, pode ser utilizado para
apresentar as unidades de negócio, perfis e competências principais. Os demais fatores podem
ser documentados em forma textual. Um modelo conceitual, como o exemplo abaixo, deve ser 
utilizado apenas para documentar os principais aspectos do negócio. 
Figura 2.6 – Exemplo de um Modelo Conceitual.
Versão Draft/Apostila (Jun/07) 39 
Representando a Estratégia 
A representação da estratégia da empresa é uma atividade um tanto complexa. Complicada pela 
inexistência de um padrão consistente. É fato que uma boa descrição da estratégia deve 
contemplar, no mínimo, as seguintes informações: 
Fator Descrição
Clientes Quem é o cliente da empresa. Quais são as suas 
características? A empresa busca um novo perfil de 
clientes? Qual é? 
Concorrentes Quais são os principais concorrentes da empresa? Quais 
são seus principais pontos fortes e fracos? 
Porte e Posicionamento no 
Mercado
Como o negócio está posicionado no mercado? Esta 
informação complementa ou é completada pelas
informações sobre Pontos Fortes e Fracos apresentados
na tabela anterior. 
Lucratividade e 
Crescimento
Uma comparação com os indicadores dos concorrentes e 
uma perspectiva de crescimento. 
Ambiente Como o macro-ambiente deve influenciar na realização 
dos objetivos do negócio? 
Percepção Como o mercado, particularmente os clientes e clientes 
em potencial, percebem a empresa? Há necessidade de 
mudar essa percepção? 
Nível dos Serviços Qual o nível de serviço oferecido para os clientes? Ele 
deve ser modificado para atender novas expectativas?
Tabela 2.4 – Principais fatores que descrevem a Estratégia do Negócio.
40 Formando Analistas de Negócios
Existem diversas ferramentas e propostas que auxiliam na descrição da estratégia do negócio. 
Uma alternativa que ganhou muitos adeptos nos últimos tempos é o conjunto formado por
Balanced Sco ecardsr
r
5 e Mapas Estratégicos15. Os primeiros ajudam a empresa a planejar e 
monitorar sua performance. O mapa estratégico “é a representação visual da estratégia” 9, que 
normalmente é consolidada em uma única página. A figura 2.7 apresenta um exemplo do 
balanced sco ecard e do mapa estratégico, destacando o relacionamento de ambos. 
Figura 2.7 – Exemplo do Balanced Scorecard e de um Mapa Estratégico.
Versão Draft/Apostila (Jun/07) 41 
Há também uma alternativa para apresentar os grandes objetivos da empresa na forma de um 
diagrama UML, no caso um diagrama de classes. A sugestão faz parte da EPBE. Abaixo um 
exemplo:
Figura 2.8 – Exemplo de um diagrama de Objetivos.
42 Formando Analistas de Negócios
A Visão da Estrutura do Negócio 
Representamos a organização de todos os recursos da empresa através de diagramas que 
compõem a Visão da Estrutura do Negócio. Relembrando: recursos podem ser físicos, abstratos
ou informacionais. Recursos são as pessoas, unidades de negócios, materiais, produtos e serviços 
da organização.
Utilizamos especializações do diagrama de classes para representar a estrutura dos diversos 
recursos de uma empresa. Um organograma, por exemplo, pode facilmente ser transcrito na 
forma de um diagrama de classes, como ilustra a figura 2.9:
Figura 2.9 – Exemplo de um organograma segundo a EPBE.
Recursos também podem ser as informações que a empresa detém. Não todas, com alto grau 
de detalhamento, mas aquelas consideradas estratégicas. De certa forma esse diagrama é 
equivalente aos modelos conceituais de bases de dados. Mas devemos nos lembrar que, 
enquanto conceituais, esses diagramas não manifestam a menor preocupação com a forma ou o 
local onde as informações estão armazenadas. 
Versão Draft/Apostila (Jun/07) 43 
Com a Visão do Negócio e a Visão da Estrutura do Negócio encerramos o mapeamento do 
negócio e sua estrutura. Para completar a visão do todo, falta agora a parte dinâmica da 
organização, ou seja, a Visão dos Processos e a Visão do Comportamento. Elas são o tema dopróximo capítulo. 
44 Formando Analistas de Negócios
Notas, Bibliografia e Referências 
1. Business – Def na Wikipedia
http://en.wikipedia.org/wiki/Business
2. Definição de UML 
3. No decorrer do livro pode ser utilizado o termo “Domínio”. [REVER] 
4. BBusiness Modeling with UML – Business Patterns at Work 
Hans-Erik Eriksson e Magnus Penker. Wiley / OMG Press (2000). 
5. Definição de Balanced Scorecard 
http://en.wikipedia.org/wiki/Balanced_scorecard
6. Estratégia na Wikipedia 
http://en.wikipedia.org/wiki/Strategy
7. Safári de Estratégia 
Henry Mintzberg, Bruce Ahlstrand e Joseph Lampel 
Bookman (2000).
8. What is Strategy?
Michael Porter. Harvard Business Review (1996).
9. Mapas Estratégicos
Robert S. Kaplan e David P. Norton. Editora Campus (2004).
10.Definição de Orientação a Objetos (OO)
http://en.wikipedia.org/wiki/Object_oriented
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
11.DDefinição de Workflow 
http://en.wikipedia.org/wiki/Workflow
12.Managing Software Requirements – A Use Case Approach
Dean Leffingwell e Don Widrig. Addison-Wesley 
Segunda Edição (2003).
13.Definição do RUP 
http://en.wikipedia.org/wiki/Rup
14.DDefinição de Matriz SWOT 
http://en.wikipedia.org/wiki/SWOT_analysis
15. Definição de Mapas Estratégicos
http://en.wikipedia.org/wiki/Strategy_maps
Versão Draft/Apostila (Jun/07) 45 
Exercícios para o Workshop 
1. Pedir que os alunos descrevam seus negócios, usando apenas os 4 conceitos 
básicos.
2. Ilustrar na forma do meta-modelo?
3. Proposição de Valor. Qual é a proposição das empresas representas no 
workshop?
Notas
46 Formando Analistas de Negócios
CAPÍTULO 3 
Modelando
Processos de 
Negócio
ƒ A Visão dos Processos 
ƒ Tipos de Processos
ƒ Características Básicas dos Processos de Negócio 
ƒ Partes de um Processo de Negócio 
ƒ Modelagem de Processos de Negócio 
à Mapas de Processos
à Diagrama de Processo 
à Diagrama de Linha de Montagem 
à Relações Complexas entre Processos 
à Diagrama de Atividades 
à BPMN
ƒ O Enfoque “Meet in the Middle” – Considerando os sistemas existentes 
Versão Draft/Apostila (Jun/07) 47 
A visão dos processos de negócio é a parte principal e mais complexa da modelagem de 
negócios. Por isso ela merece um capítulo em separado. No capítulo anterior vimos conceitos 
básicos da modelagem de negócios e analisamos a visão do negócio e a visão da sua estrutura.
Aqui estudaremos as duas outras visões: dos processos e do comportamento do negócio.
É milenar a cultura que determina como as empresas se estruturam e se apresentam. Vem dos 
antigos exércitos a estrutura hierárquica. Pessoas e os mais diversos recursos são distribuídos em 
departamentos funcionais ou áreas de negócio que são semi-autônomos. Organogramas são 
utilizados para formalizar essa distribuição, destacando os responsáveis e respectivos 
subordinados. Normalmente, uma visão conceitual lembra uma pirâmide. 
No início dos anos 1990 ganhou força uma série de propostas que pregavam que os processos 
de negócio eram mais importantes e críticos do que os departamentos de uma empresa. 
Entendendo que o organograma impõe uma visão vertical da organização, os processos, por sua 
vez, significam uma visão horizontal da empresa. Os processos são, de fato, a forma como as 
empresas funcionam. 
Podemos definir um processo de negócio de uma forma extremamente simples, como na 
Wikipedia1: “é um conjunto de atividades inter-relacionadas que recebem entradas, agregam 
valor, e geram saídas”. 
Não se engane com a simplicidade da definição: um processo de negócio pode ser 
extremamente complexo, compreender uma série de objetivos, seguir um grande número de 
regras e utilizar um volume considerável de recursos. Mas uma das maiores dificuldades que o 
AN encontrará será exatamente a falta de uma 'cultura' de processos. Diversas empresas 
simplesmente ignoram seus processos e os benefícios que o gerenciamento deles pode gerar.
Neste capítulo veremos os conceitos básicos e os tipos de processos que existem em todas as 
empresas. Veremos também o uso da UML para a modelagem de processos, bem como da 
BPMN. O capítulo 4 tratará da análise dos processos, ou seja, mostrará como efetuar uma 
avaliação crítica e o redesenho dos processos de negócios. 
48 Formando Analistas de Negócios
A Visão dos Processos 
A visão dos processos de negócio pode ser muito diferente da visão de sua estrutura. 
Conseqüência natural da forma como as empresas organizam seus recursos. Departamentos e 
seções foram criados para tratar de partes específicas do negócio. Acontece que, na maioria das 
vezes, um processo ultrapassa as fronteiras de um departamento. Um processo de vendas, por 
exemplo, pode envolver os departamentos de vendas, financeiro, logística e outros.
Figura 3.1 – Visão Vertical X Visão Horizontal.
Perceberemos que a complexidade é ainda maior se atentarmos para o fato de que apenas um 
conjunto dos processos pode satisfazer os grandes objetivos da organização. Cada processo, de 
maneira isolada, tem um propósito. No entanto, isolado ele não significa muita coisa.
Quando atuando em um projeto específico, pode ser que o trabalho do AN se limite ao 
mapeamento de um ou alguns poucos processos. Não raro, um projeto pequeno pode tocar 
apenas uma parte de um processo. Ainda assim, por razões que serão explicadas neste e no 
capítulo seguinte, é importante que o AN procure entender o processo como um todo. Quando 
alocado em atividades de larga escala, o AN deverá mapear um grande número de processos. É 
importante, então, que ele consiga diferenciar os tipos de processos. 
Versão Draft/Apostila (Jun/07) 49 
Tipos de Processos 
Na definição clássica2, existem três tipos principais de processos de negócios3:
Tipo de Processo Descrição
Primários São aqueles que lidam diretamente com o cliente. Sendo 
assim, se houver algum problema com um processo primário, 
o cliente perceberá imediatamente. Alguns exemplos de 
processos primários são: vendas, atendimento, contas a 
receber, desenvolvimento de novos produtos, logística. 
Os processos primários podem ser classificados em 4 grandes 
grupos4:
ƒ Operacional: produção e entrega de bens e serviços para 
os clientes; 
ƒ Gestão de Clientes: todas as atividades ligadas ao 
relacionamento com o cliente; 
ƒ Inovação: pesquisa e desenvolvimento de novos produtos, 
serviços ou processos. 
ƒ Regulatórios e sociais: conformidade com as expectativas 
regulatórias e sociais. 
De Apoio São todos os processos que suportam ou são necessários 
para a execução dos processos primários. São exemplos de 
processos de apoio: contratação e gestão de recursos
humanos, gerenciamento do ativo imobilizado, contabilização 
e compras. 
De Gestão São todos aqueles processos necessários para coordenar a 
execução dos processos primários e de apoio. Definição da 
estratégia de atuação e o planejamento orçamentário são 
exemplos de processos de gestão. 
Tabela 3.1 – Tipos de Processos 
50 Formando Analistas de Negócios
O diagrama abaixo ilustra o relacionamento entre os três tipos de processos e destes com o 
mundo exterior.
Figura 3.2 – Visão Geral dos tipos de processos. 
É fundamental que o AN saiba diferenciar os tipos de processos. Cada tipo costuma merecer um 
tratamento totalmente diferente por parte das empresas. Processos de apoio, por exemplo, são 
administrados para que gerem o menor custo possível. Não raro, são os primeiros processos a
serem terceirizados. Processos de gestão são executados por pouquíssimas pessoas, a maioria do 
alto escalão da empresa. Neles a preocupação não é com custo, mas com agilidade e 
disponibilidade de informações. E, por fim os mais importantes: os processos primários.Eles são 
os mais sensíveis à proposição de valor da empresa. Como vimos no capítulo anterior, existem 4 
proposições de valor: i) Baixo Custo Total; ii) Inovação; iii) Soluções Completas; e, iv) 
Aprisionamento. O perfil dos processos primários é ditado pela proposição de valor5. Por
exemplo: a empresa oferece bens ou serviços de baixo custo total? Então ela deve valorizar a 
eficácia e eficiência dos processos de faturamento e entrega. Eficácia e eficiência são algumas 
características básicas de um processo de negócio.
Versão Draft/Apostila (Jun/07) 51 
Características Básicas dos Processos de 
Negócio
Todo processo de negócio é formado por 5 características básicas, apresentadas na tabela 
abaixo6:
Característica Descrição
Fluxo A seqüência de atividades e tarefas que são executadas para 
transformar entradas em saídas. 
Eficácia É “fazer a coisa certa”, ou seja, essa característica mostra até 
que ponto o processo atende as expectativas dos clientes 
(externos ou internos). 
Eficiência É “fazer certo”, ou seja, medimos aqui o grau de utilização de 
recursos para produzir uma saída.
Tempo de Ciclo Indica o tempo total necessário para a execução completa de 
um ciclo do processo, ou seja, para a geração de uma saída. 
Custo O custo total do processo, para geração de uma saída 
(execução de um ciclo). 
Tabela 3.2 – Características Básicas dos Processos de Negócio. 
É o conjunto dessas 5 características que determina a qualidade geral de um processo de 
negócio. Como veremos no próximo capítulo, é a análise dessas características que permite a 
descoberta de possibilidades de melhoria. Neste momento nos interessa a primeira característica, 
o fluxo de um processo.
Um processo de negócio pode ser quebrado em várias unidades, que por sua vez também 
podem ser divididas. Essa divisão objetiva obter o melhor uso possível dos recursos e, na maioria 
das vezes, no menor tempo possível. Quando mapeamos ou modelamos um processo de 
negócio, estamos criando uma abstração para essas divisões e a sua seqüência de execução.
52 Formando Analistas de Negócios
Antes de falarmos na modelagem propriamente dita, é importante conhecermos as partes de um 
processo de negócio. 
Partes de um Processo de Negócio 
Existem algumas diferenças de nomenclatura e conceitos quando tratamos das partes de um 
processo de negócio. Neste livro será utilizado o seguinte padrão: 
Parte Descrição
Sub-Processo Um processo é formado por dois ou mais sub-processos. Partimos 
do princípio de que sempre haverá, no mínimo, duas grandes 
partes: a entrada e a saída. No entanto, na maior parte dos
casos, veremos que um processo pode ser formado por vários
sub-processos.
Atividade Cada sub-processo é formado por uma ou mais atividades. Uma 
atividade, por sua vez, é uma seqüência de tarefas.
Tarefas É a menor unidade de execução de um trabalho em um processo.
Tabela 3.3 – Partes dos Processos de Negócio. 
A figura abaixo apresenta um exemplo de um processo de negócio e suas diversas divisões:
Figura 3.3 – Exemplo das divisões de um processo de negócio.
Versão Draft/Apostila (Jun/07) 53 
Modelagem de Processos de Negócio 
Todo negócio é muito complexo. Devemos nos lembrar sempre que a principal motivação para 
se criar modelos é a simplificação. É criar visualizações que facilitem o entendimento do negócio 
por todos os envolvidos. O AN deve ter bom senso para entender qual nível de detalhamento é 
necessário em determinado momento, num dado modelo. São os modelos que servirão de base 
para tomadas de decisões, para a definição ou priorização de objetivos e alocação de recursos.
Como foi colocado anteriormente, a modelagem dos processos de negócio é a parte central da 
modelagem do negócio. São esses modelos que devem mostrar como o negócio funciona. E se 
a motivação para a criação de modelos for a implantação ou melhoria de sistemas de informação, 
o AN deve entender que está lidando com algo extremamente sensível. Afinal, o sistema deve 
alterar a forma como o processo é executado. Na realidade, ele pode alterar a forma e todas as 
características do processo.
Não estão no escopo deste livro as questões sociológicas e psicológicas que surgem com esse 
tipo de mudança. Mesmo que essas questões não existissem, ainda assim o AN estaria lidando
com algo sensível e crítico. Um pequeno detalhe que tenha sido capturado e modelado de forma 
errada pode condenar o trabalho. Ou seja, um mapa pode ser simplificado, pode ser resumido,
mas ele nunca pode nos levar para a direção errada. Nem nos deixar em dúvidas com relação ao 
caminho correto.
Na grande maioria dos casos o trabalho do AN envolverá a geração de dois conjuntos de 
modelos para cada processo de negócio. O primeiro representando o desenho atual do 
processo (“as is”, ou “como ele é”), e o segundo conjunto desenhando como o processo deverá 
ficar (“to be”). O primeiro conjunto deve ser extremamente fiel à realidade atual do negócio, 
totalmente isento de suposições e livre de dúvidas. Se uma informação não é bem mapeada 
neste momento, podemos condenar todo o trabalho de redesenho dos processos.
Neste capítulo veremos apenas a captura e modelagem dos processos em seu estado atual. O 
capítulo seguinte, “Analisando o Negócio”, mostrará como o AN executa o redesenho de 
processos.
54 Formando Analistas de Negócios
Mapas de Processos 
O primeiro artefato gerado pelo AN, útil para guiar todas as atividades seguintes, é um grande 
mapa dos processos. É o projeto ou iniciativa que determinará o escopo deste mapa. Ele pode 
contemplar todos os processos principais da empresa, se o AN estiver envolvido em um grande 
programa de mudanças ou na implantação de sistemas de grande porte7. Ou o mapa envolverá 
apenas os processos tocados direta e indiretamente pelo projeto ou iniciativa.
Este grande mapa pode ser uma derivação do modelo conceitual do negócio, apresentado no 
capítulo anterior. A figura abaixo apresenta um exemplo de um mapa de processos: 
Figura 3.4 – Exemplo de um Mapa de Processos.
Versão Draft/Apostila (Jun/07) 55 
O mapa de processos mostra o relacionamento entre os diversos processos de negócio e a 
relação destes com todo o ambiente de negócios. Grande parte das demandas atuais costuma se 
concentrar nos processos primários. Isso porque os processos de apoio, quando não estão 
terceirizados, já estão maduros e devidamente informatizados. De qualquer maneira, não se trata 
de uma restrição. O mapa pode contemplar processos de qualquer tipo. Por isso, é importante
que além do nome do processo, o AN indique seu tipo no mapa. Mesmo que essa identificação 
seja óbvia pela simples observação do mapa ou dos nomes dos processos. 
O mapa deve guiar todas as atividades seguintes do AN. Ou seja, é a partir do mapa que serão 
selecionados e priorizados os processos a serem mapeados e analisados. O mapa de processos é 
uma extensão do Diagrama de Processo, apresentado abaixo. 
Diagrama de Processo 
Selecionado o processo que deve ser mapeado, o AN deve levantar informações básicas que 
possibilitem a geração do Diagrama de Processo. Em Business Modeling with UML8 os autores 
sugerem a adoção de um pattern9, um padrão de desenho, para o diagrama de processo. Este 
padrão é chamado de Estrutura Básica do Processo e é baseado no padrão IDEF0 (Integration
Definition for Function)10. A figura abaixo mostra uma visão genérica deste diagrama: 
Figura 3.5 – Diagrama de processos genérico.
56 Formando Analistas de Negócios
No diagrama de processos indicamos os recursos e os objetivos que se relacionam com o 
processo. Ou seja, dos quatro elementos básicos que definem um negócio, o único não 
contemplado neste momento são as regras. A tabela abaixo explicaos cinco elementos que, além 
do processo propriamente dito, compõe o diagrama de processo: 
Elemento Descrição
Objetivos São os objetivos ou metas do processo. Se anteriormente o AN 
optou por mapeá-los na forma de um diagrama de objetivos 
(figura 2.8), é de lá que este elemento deve ser trazido11.
Entradas Recursos que são consumidos ou refinados pelo processo. É 
importante lembrar que os recursos podem ser pessoas, 
informações, físicos ou abstratos.
Saídas Recursos que são gerados pelo processo. São o resultado do 
trabalho executado (valor agregado) nas Entradas.
Suportes Recursos que participam do processo, mas não são consumidos, 
refinados ou gerados por ele.
Controles São os recursos que controlam ou executam o processo. 
Tabela 3.4 – Elementos do Diagrama de Processo.
Reparem que neste momento não estamos preocupados em desenhar o fluxo, as partes e 
características do processo de negócio. Apenas seus objetivos e todos os recursos envolvidos na 
sua execução. Na figura abaixo inserimos a estrutura da organização, ou seja, os departamentos
envolvidos na execução do processo. Neste segundo tipo de diagrama podemos ilustrar o 
relacionamento do processo com outros ou já indicar o primeiro nível de quebra, ou seja, os 
sub-processos.
Versão Draft/Apostila (Jun/07) 57 
Figura 3.6 – Exemplos do Diagrama de Processos.
Diagrama de Linha de Montagem 
Os diagramas de linha de montagem (Assembly Line), uma radical variação do diagrama de
atividades da UML, são particularmente úteis quando o AN está envolvido com um projeto para 
desenvolvimento ou implantação de um sistema de informação. Eles indicam como os processos 
de negócio consomem e geram informações. Além disso, de todos os diagramas propostos na 
EPBE, é o único que possibilita uma ligação direta com o domínio da solução.
Abaixo de um ou mais processos o diagrama apresenta pacotes (packages padrões da UML) 
horizontais que são utilizados para agrupar recursos. Esses pacotes são as “linhas de montagem”. 
Através de linhas verticais indicamos como os processos consomem ou geram informações 
(recursos de informação). Abaixo um diagrama genérico e um exemplo de utilização do diagrama 
de linha de montagem: 
58 Formando Analistas de Negócios
Figura 3.7 – Diagramas de Linha de Montagem.
Como foi dito anteriormente, o diagrama de linha de montagem permite uma ligação direta do 
negócio com sistemas de informação. Observe o exemplo abaixo: 
Figura 3.8 – Diagrama de linha de montagem e casos de uso.
Versão Draft/Apostila (Jun/07) 59 
Os pacotes de linhas de montagem no diagrama acima representam objetos em um sistema de 
informação. As linhas verticais indicam como o processo consome ou gera esse objetos. Elas 
representam a interface entre o negócio e o sistema. Um conjunto de referências (linhas) 
normalmente identifica um caso de uso que o sistema deve atender. Mapeamos assim os 
processos de negócio para casos de uso que descrevem os requisitos funcionais dos sistemas de 
informação. Portanto, os diagramas de linha de montagem configuram uma boa técnica para 
descobrir e validar os casos de uso do negócio.
No capítulo 6 serão apresentados outros exemplos de utilização deste diagrama para guiar a 
geração de casos de uso e para guiar os trabalhos de coleta e validação de requisitos funcionais.
Relações Complexas entre Processos 
Diagramas de linhas de montagem também podem ser utilizados para o mapeamento de 
processos e suas relações. Se tentarmos detalhar o mapa de processos, podemos ter um 
diagrama de difícil leitura. O desenho dos objetivos, recursos e relacionamentos entre diversos 
processos pode ser simplificado com o uso dos diagramas de linhas de montagem. Esta sugestão
aparece como mais um pattern – chamado Process Interaction - do livro Business Modeling with 
UML.
Ao invés de traçar linhas entre os processos, indicamos apenas como dois ou mais processos 
consomem e geram informações em diversos pacotes de linhas de montagem, ou seja, em 
diversos sistemas de informação. Mostramos suas relações indiretamente, através dos recursos
que compartilham.
60 Formando Analistas de Negócios
Diagrama de Atividades 
Os diagramas vistos até aqui são adaptações de diagramas de atividades da UML, sugeridas pela 
EPBE. Alguns autores12 sugerem a utilização dos diagramas de atividades em sua forma padrão 
para a modelagem de processos de negócio. Trata-se de uma opção interessante, já que na EPBE 
esse detalhamento só é obtido através da utilização de outro diagrama, uma derivação do
diagrama de seqüência. A forma padrão dos diagramas de atividades também são mais facilmente 
mapeados ou comparados com diagramas que utilizam o padrão BPMN (Bu iness Process 
Modeling Notation)
s
13, que será apresentado posteriormente neste capítulo. A figura abaixo 
apresenta um exemplo de um diagrama de atividades em seu formato tradicional: 
Figura 3.9 – Diagrama de Atividades tradicional.
Versão Draft/Apostila (Jun/07) 61 
Enquanto os diagramas de processos e de linhas de montagem são úteis no mapeamento dos 
processos como um todo, seus componentes e relacionamentos, os diagramas de atividades em 
seu formato tradicional devem ser utilizados para a documentação de partes específicas de um 
processo. Eles permitem o estudo daquilo que chamamos de “casos de uso”. Maiores detalhes 
no capítulo 6.
62 Formando Analistas de Negócios
BPMN
BPMN, ou Business Process Modeling Notation, é um padrão que foi desenvolvido pela BPMI 
(Business Process Management Initiative)15. Recentemente ele foi incorporado pelo OMG 
(Object Management Group)16, mesmo órgão que cuida do padrão UML. Acredita-se que essa 
fusão se refletirá nos padrões. Ou seja, é grande a possibilidade da BPMN ser, de alguma 
maneira, anexada ao padrão UML17.
São grandes as semelhanças entre BPMN e os diagramas de atividades tradicionais da UML17. A
figura abaixo apresenta um exemplo de um diagrama BPMN: 
Figura 3.10 – Exemplo de um diagrama BPMN.
Versão Draft/Apostila (Jun/07) 63 
Meet in the Middle 
As maneiras como o AN deve capturar as informações necessárias para a modelagem do negócio 
serão discutidas posteriomente. No entanto, cabe aqui a colocação de uma sugestão que deve 
ser útil na grande maioria dos projetos. Será difícil encontrar um processo de negócio que não 
esteja, pelo menos parcialmente, amparado por sistemas de informação. Esses sistemas serão, na 
maioria dos casos, a melhor documentação disponível sobre os processos de negócio. Trata-se
de uma informação que não pode ser desconsiderada pelo AN, mesmo que o projeto em 
questão envolva a total substituição dos sistemas existentes.
Meet in the Middle é um método de levantamento e análise de processos de negócios que 
considera a utilização de duas fontes de informações. A primeira é o processo propriamente dito, 
mapeado a partir da observação e de entrevistas com os participantes (mais sobre o tema no 
sexto capítulo). A segunda fonte são os sistemas existentes. As duas frentes de levantamento 
podem ou devem ser executadas em paralelo, “se encontrando no meio do caminho”.
Figura 3.11 – Se encontrando no meio do caminho.
64 Formando Analistas de Negócios
Se possível, os dois levantamentos realmente deveriam ocorrer em paralelo, executados por 
diferentes AN's. Sendo assim, é maior a possibilidade de identificar inconsistências e problemas 
com os processos de negócio.
Versão Draft/Apostila (Jun/07) 65 
Notas, Bibliografia e Referências 
1. Processo de Negócio – Def na Wikipedia
http://en.wikipedia.org/wiki/Business_process
2. Explicar “clássica” - Anos 90! 
3. Sinais Vitais 
Steven M. Hronec – Makron Books / Arthur Andersen (1993). 
4. MMapas Estratégicos
Kaplan e Norton