Tecnologia em Processos Gerenciais

SISTEMA DE INFORMAÇÃO

Levantamento e
Modelagem de Processos
 10
Sistema de Informação
Levantamento e
Modelagem de Processos

Objetivos da Unidade de aprendizagem

Conhecer como levantar e modelar processos empresariais.

Competências
Compreender modelagem descritiva, analítica e execu-
tável, bem como os modelos de processos empresariais.

Habilidades
Identificar regras de negócio, modelos de processo, dia-
grama de processo e mapas de processo.
Apresentação
Nessa unidade você vai aprender como levantar e mo-
delar processos empresariais e compreender as mode-
lagens descritiva, analítica e executável, além de identifi-
car regras de negócio, modelos de processo, diagramas
e mapas de processos empresariais.

Para Começar
Olá, na aula três discutimos os modelos de processos
de TI, nesta aula vamos estudar o levantamento e a mo-
delagem de processos de negócios que são utilizados
pelo departamento de TI, essa integração entre os de-
partamentos de TI e os departamentos administrativos
(algumas vezes chamados pelos profissionais de TI de
departamentos funcionais).
Uma frase muito interessante apresentada por Bill
Gates sobre os processos é a seguinte: “A primeira regra
de qualquer tecnologia utilizada em negócio é que a au-
tomação aplicada a uma operação eficiente ampliará a
eficiência. A segunda é que a automação aplicada a uma
operação ineficiente ampliará sua ineficiência”.
Obrigado e sucesso!

Fundamentos
1. Modelagem de Processos
Segundo TURBAN (2007) as empresas possuem dimen-
sões verticais e horizontais, a dimensão vertical é o ní-
vel de especialização funcional da organização, como
por exemplo, marketing, recursos humanos, produção,
vendas dentre outras, nem sempre essa verticalização é
efetiva, pois grande parte dos departamentos possuem
processos e procedimentos que são compartilhados en-
tre as áreas funcionais.
 Vamos imaginar nossa vertical de produção, e a integração com as ou-
tras áreas ou verticais da organização. Um gerente de vendas ou gerente
de negócios de determinada empresa visita um cliente e faz uma grande
venda (observe que aqui temos o departamento de vendas ou vertical de
vendas em ação), mas para que essa venda seja finalizada com sucesso
necessitamos da interação de outros departamentos, como por exemplo,
o departamento financeiro verificará a “saúde financeira” de nosso cliente,
identificando se este possui reais condições de realizar o pagamento da
compra. Após essa análise, se constatado que o cliente atende as neces-
sidades aplicadas pela empresa, existe a interação com o departamen-
to de produção que produzirá os produtos que serão entregues para o
cliente. Em determinado momento, o gestor de produção detecta que se
sua equipe continuar trabalhando em sua carga horária convencional, os
produtos não serão entregues no prazo contratado, então esse gestor da
produção faz uma interação com o departamento de recursos humanos/
departamento pessoal que irá aprovar, por exemplo, um plano de traba-
lho diferenciado para os colaboradores do referido setor/departamento.
Tudo foi produzido no prazo correto, temos mais departamentos que
temos interação, como por exemplo o departamento de logística que é
o responsável pela entrega dos produtos fabricados e devidamente fa-
turados (emissão de notas fiscais e outros documentos – aqui tivemos a
interação do departamento de faturamento da empresa) para a entrega.
Uma vez que a entrega é realizada, o cliente confirma o recebimento dele
por meio da assinatura de um documento de recebimento da mercadoria.
Esse comprovante segue para o setor de Logística, responsável pelo con-
trole de entregas na empresa.
Como podemos observar, um simples processo de venda, envolveu
diversos departamentos e diversos procedimentos internos de cada um
desses departamentos. E na criação, compra ou implementação de um
sistema computacional para a automatização desses processos todos os
departamentos envolvidos devem ser “ouvidos” para poderem explicar
os processos e as necessidades de cada um dos departamentos. O que
exemplificamos é a estrutura horizontal. CBOK (2009)

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 4

Figura 1. Processos
de negócios por
fornecedores empresa clientes
meio das áreas
funcionais e limites
Distribuição Compras Finanças P&D Produção Vendas Distribuição Logística,
organizacionais Serviço
Fonte: Adaptado
de TURBAN (2007)
desenvolvimento de produto

atendimento de pedido

planejamento, suprimento e controle

serviço ao cliente

Conforme TURBAN (2007) a integração funcional deve acontecer entre

os departamentos e para termos uma integração efetiva essa integração
deve alcançar nossos fornecedores e clientes.

1.1. Modelo de processo

Segundo CBOK (2009), um modelo de processo é uma representação dos
processos empresariais, podendo conter representações gráficas, narrati-
vas ou de outras formas, o modelo de processo de negócio devem conter
as informações apresentadas a seguir (essas informações podem compor
modelos de processos):

→→ Informações sobre o negócio;

→→ Informações operacionais;
→→ Informações específicas do processo;
→→ Informações técnicas.

Um modelo de processo considerado completo é o que contempla diver-

sas perspectivas do negócio, atendendo diversos propósitos.

1.2. Diagrama de processo

Segundo CBOK (2009), o diagrama de processo é uma representação mais
elementar e inicial sobre um determinado processo, é o primeiro passo
para a representação e compreensão mais complexa dos processos em-
presariais, usualmente o diagrama de processo é comporto apenas por
fluxos simples de atividades, e diversas vezes representa o melhor cami-
nho que o processo deve “seguir”, ou seja, representamos as situações

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 5

 de sucesso na realização do processo (não é considerado as exceções e
falhas que não são fortemente evidenciadas).

Figura 2. Exemplo
de Diagrama
de Processo. Sim
Atividade 1 Atividade 2
Fonte: Autor.
processo 1

Atividade 3

Figura 3. Diagrama
de Processo de
recebimento

Recebimento de
Mercadoria. Receber Cadastrar Notificar
mercadoria nota fiscal recebimento
Fonte: Autor.

Como podemos observar em nosso diagrama de processo demonstra-

do anteriormente, marcamos o início do processo com o recebimento
da mercadoria no setor de recebimento da empresa, cadastramos nossa
nota fiscal dos produtos recebidos, notificamos o recebimento para os
departamentos necessários e finalizamos o processo (utilizamos um Pool
para nossos processos, o conceito de pool será demonstrado mais a se-
guir, mas é importante observar que temos um Pool de processos).

1.3. Mapa de processo

Segundo o CBOK (2009), um mapa de processo leva em consideração
atividades, informações e restrições de maneira simultânea, a represen-
tação de um mapa de processo é feita por setas e linhas que são decom-
postas com maiores detalhes de forma sucessiva, esta decomposição
tem a finalidade de garantir a validade dos mapas de processos finais, os
mapas de processo são representados por uma linguagem gráfica que
tem por finalidade:

→→ Demonstrar os detalhes do processo de modo gradual e controlado;

→→ Definir com precisão a descrição do processo;
→→ Focar a atenção nas interfaces do mapa do processo;

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 6

 →→ Fornecer uma análise de processos consistente.

Conforme o CBOK (2009), sua representação inicia-se do sistema inteiro

de processos como uma única unidade modular, que será expandida em
diversas outras unidades mais detalhadas, que, conectadas por setas e
linhas, serão decompostas em maiores detalhes de forma sucessiva. Esta
decomposição é que garantirá a validade dos mapas finais. Assim sendo,
o mapa de processos deve ser apresentado em forma de uma linguagem
gráfica que permita uma melhor compreensão dos processos.
A seguir um exemplo de processo de recebimento de materiais, conside-
rando-se que pode existir problemas no recebimento, em nosso exemplo
temos de realizar a comparação com o pedido de compra com a nota fiscal
enviada, como podemos observar no mapa de processos a seguir. (Neste
mapa de processos utilizamos o conceito de Lane, que veremos a seguir.)

Figura 4. Mapa
de Processo de
Área 1

Recebimento de Receber Comparar Devolver Notificar

Mercadoria. mercadoria com pedido mercadoria problema
recebimento

Fonte: Autor.

Cadastrar Notificar
Área 2

nota fiscal recebimento

2. Domínios da modelagem de processos

A modelagem de processos é dividida em três grandes domínios, por sua
vez esses domínios são subdivididos, conforme podemos observar na
ilustração a seguir:
Figura 5. Domínios
da modelagem
de processos.
Fonte: Adaptado pelo domínio • Corporativo (representa o portfólio de processos)
autor de CBOK (2009). do negócio • Negócio (redesenho do negócio)

domínio das • Operações (representa as melhorias de processos)

operações • Sistemas (requisitos sistêmicos)

domínio da • Construtor (representa as especificações de uso)

tecnologia • Operador (sistemas e métodos de trabalho)

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 7

No domínio do negócio podemos afirmar que a modelagem corporativa
tem o objetivo de transcrever como a organização realiza seu trabalho (pro-
cessos) num alto nível, sendo o nível corporativo considerado como uma
modelagem de processos com uma visão “executiva”, sendo muito utilizada
para apresentações e discussões com os diretores da organização.
Nos outros níveis que vem logo abaixo, o nível de detalhamento au-
menta, e é utilizado por funcionários de menor nível hierárquico da orga-
nização, nos próximos tópicos vamos discutir os três domínios de forma
mais abrangente.
Apesar dos domínios serem estabelecidos formalmente, pode existir
muita variação dependendo das iniciativas de modelagem de processos
que estamos participando, para sua adoção é necessário estabelecer pro-
cedimentos claros e lógicos para que seu uso tenha real significado para
as equipes envolvidas.

2.1. Domínio do Negócio

O domínio de negócio é a perspectiva ideal para descrever as necessi-
dades da organização, descreve as razões pelas quais um projeto foi
iniciado, oferecendo aos donos de processos métricas para medir a qua-
lidade do desempenho dos processos, é uma visão de negócio dos pro-
cessos empresariais.
O exemplo de um evento de domínio de negócio é a venda de um pro-
duto para um cliente, uma requisição de informação por um executivo
sênior ou uma falha ao completar uma transação. Os eventos podem ser
ações tomadas por uma pessoa, regras que para ações a serem tomadas
ou a passagem de um período de tempo. (BABOK, 2011).

2.2. Domínio de Operações

O domínio de operações é a perspectiva ideal quando temos a neces-
sidade entender e apresentar características e detalhes de operação do
processo, é muito utilizado para trabalhos que envolvem análise e melho-
ria de processos, e também fornecem suporte para os responsáveis pela
qualidade do desempenho operacional. (BABOK, 2011).

2.3. Domínio da Tecnologia

O domínio da tecnologia é a perspectiva ideal quando temos a necessida-
de de entender e apresentar sistemas de apoio dos trabalhos que devem
ser executados pelos processos. (BABOK, 2011).

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 8

 3. Níveis de Modelagem
Segundo o CBOK (2009), em modelagem de processos de negócios, te-
mos três níveis de modelagem, esses níveis de modelagem são orienta-
dos para a utilização do modelo, os modelos em seus diferentes níveis de
representação buscam “refletir” as diferentes representações do que e de
como o modelo significa para os três tipos de usuários da modelagem.

3.1. Modelagem Descritiva

Conforme o CBOK (2009), a modelagem descritiva é o primeiro nível e é
ideal para a representação e descrição de processos para os profissionais
que estão envolvidos com o que é chamado de camada de negócio da
organização. Este modelo tem a função de representar o fluxo dos pro-
cessos de forma simples, utilizando um conjunto de elementos gráficos
para isso.
Lista dos elementos essenciais de modelagem que são descritas na notação:

elemento descrição notação

Tabela 1. Elementos
de modelagem Um evento é o que ocorre durante o curso de
Fonte: CBok (2009). um processo de negócio. Esses eventos afetam
o fluxo do processo e normalmente tem uma
Eventos causa ou um impacto. Existem três tipos eventos:
(Events)
• Inicio
• Intermediário
• Final

objetos Atividade é um termo para o trabalho que é

de fluxos realizado. Uma atividade pode ser atômica ou
(flow composta. Os tipos de atividades que fazem
objects) Atividades parte de um processo de negócio são:
(Activities)
• Processos
• Subprocessos e
• Tarefas.

Decisões
Uma decisão é utilizada para controle de fluxos.
(Gateways)

Fluxo de sequência O fluxo de sequência é utilizado para demonstrar

(Sequence Flow) a ordem em que as atividades são processadas.
objetos
de conexão Fluxo de Um fluxo de mensagem é utilizado
(connecting Mensagem para demonstrar o fluxo de uma
objects) (Message Flow) mensagem entre dois participantes.

Associação Uma associação é utilizada para fazer a relação

(Association) entre as informações com os objetos de fluxo.

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 9

 elemento descrição notação

nome
Piscina Um pool representa um participante
(Pool) dentro do processo.

raia de
piscina
(swinlanes)

Nome
nome
Raia Uma lane é uma partição de um pool que tem
(Lane) a finalidade de ampliar o tamanho de um pool.

Nome
Os objetos de dados fornecem informações
Objeto de Dados
sobre o que a atividade necessita para ser
(Data Object)
executada ou/e o que essas atividades produzem.

É um agrupamento de atividades.
Grupo Representado por uma caixa que
artefatos
(Group) circunda um grupo de objetos para
(artifacts)
propósito de documentação.

Uma anotação é um mecanismo para

Anotação fornecer informações adicionais para
(Annotation) facilitar a leitura do diagrama.
Utiliza-se ligada com uma associação.

3.2. Modelagem Analítica

A modelagem analítica é de segundo nível, e contém mais detalhes, mas
esta ainda ignora exceções que não são frequentes nos processos empre-
sariais, neste nível de modelagem é necessário descrever o que realmente
acontece e sob que condições o processo irá “funcionar”, neste nível de
modelagem fazemos unificações de processos e tratamento de exceções.

evento evento evento

Tabela 2. Elementos descrição
de início intermediário de fim
da modelagem
analítica. Mensagem Mensagem Mensagem Uma mensagem de início chega de um participante
de início de fim ou gatilho de início do processo, ou continua o
Fonte: CBok (2009).
processo, neste caso um evento intermediário.
Uma mensagem de fim denota a mensagem
que será gerada ao fim do processo.

Temporizador Temporizador
de início O temporizador Um tempo específico ou ciclo pode ser ajustado para
não pode ser um realizar o início de um processo, ou a continuação
evento de fim do processo, no caso de evento intermediário.

Regra de início Regra

A regra não
O evento é iniciado quando a condição
pode ser um
da regra for verdadeira.
evento de fim

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 10

 evento evento evento
descrição
de início intermediário de fim

Ligação
A ligação não A ligação não É usado para conectar atividade de um
pode ser um pode ser um mesmo processo com a finalidade de
evento de Início evento de fim deixar o diagrama mais limpo.

Para um evento de múltiplo início, existem múltiplas

maneiras de desencadear o processo, ou de continuar
Múltiplo Início Múltiplo Múltiplo fim o processo, no caso do evento intermediário.
Somente uma delas é necessária. O atributo do
evento define qual gatilho é acionado. Para Múltiplo
Fim, existe múltiplas consequências na finalização
do processo, todos os quais irão ocorrer, como
por exemplos, múltiplas mensagens enviadas.

Exceção Exceção no fim Um evento de exceção no fim informa ao mecanismo

A exceção não do processo que um erro deverá ser criado. Este
pode ser um erro deverá ser um evento e exceção intermediária.
evento de Início No evento de exceção intermediária ele só poderá
ser usado conectado na borda de uma atividade.

Compensação Compensação
A compensação no fim Um evento de compensação de fim
não pode ser um informa ao mecanismo do processo que
evento de Início uma compensação é necessária.

Cancelamento Cancelar no fim

O cancelamento O evento de fim significa que o usuário decidiu
não pode ser um cancelar o processo. O processo é finalizado
evento de Início com um tratamento de evento normal.

Terminar
Este tipo de fim indica que todas as atividades dentro
Não se aplica Não se aplica do processo deverão ser imediatamente finalizadas.
Isto inclui todas as instâncias das múltiplas instâncias.

Sinal de Inicio Sinal Sinal no fim

Um sinal é usado para gerar comunicação
dentro ou por meio de níveis de processos,
Pools e entre diagramas de processos.

Uma atividade representa o trabalho realizado dentro de um processo.

Uma atividade normalmente levará algum tempo para ser realizada, en-
volverá pessoas e recursos (sistema de informática - Aplicação) e normal-
mente produzirá algum tipo de saída.

Tabela 3. Atividades Esta atividade é frequentemente

– Tarefa. nenhuma utilizada durante a criação do
Fonte: CBok (2009). processo (no seu estágio inicial).

É a representação de uma tarefa não-

manual automática realizada por uma pessoa.

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 11

 Esta tarefa espera a chegada de uma mensagem
de um participante externo. Quando essa
receber mensagem mensagem é recebida, a tarefa é completada.

Realiza um Script (conjunto de tarefas).

script

Envia uma mensagem a um participante

externo, quando a mensagem é
envia mensagem enviada, a tarefa é completada.

3.3. Modelagem Executável

Conforme CBOK (2009), a modelagem executável é uma forma mais mo-
derna de modelagem que contempla a execução do modelo criado de
forma sistêmica. Essa modelagem está fortemente atrelada a capacidade
de entendimento do negócio e a notação BPMN (Business Process Mode-
ling Notation), este nível de modelagem define os atributos internos dos
elementos utilizados na notação, onde são geridas as definições gráficas
(são utilizadas notações gráficas para serem de mais fácil entendimento
do que se fosse codificado em uma linguagem de programação, tendo em
vista que essa notação é voltada para o gestor empresarial).
É muito importante que seja especificado claramente o tratamento de
dados, os serviços, mensagens e interação humana com os processos. Esta
modelagem se vale de recursos e capacidades modernas para definição de
escopo e nível de tratamento e fluxo das informações empresariais.
Quando utilizamos a modelagem executável, temos a garantia de que
facilitaremos o trabalho de definição do escopo e o nível de detalhamento
dos processos.

4. Atividades para Modelagem de Processos

Em modelagem de processos de negócios temos algumas atividades que
são essenciais, essas atividades são: levantamento das informações, mo-
delagem dos processos e aprovação dos modelos, vamos ver mais deta-
lhes dessas atividades nos tópicos a seguir.

4.1. Levantamento das informações

Segundo CBOK (2009), o levantamento das informações é considerado
um dos trabalhos mais importantes para a modelagem de processos em-
presariais, é crucial que se inicie o trabalho realizando o levantamento e
coleta de informações sobre o processo e seus recursos, dependendo da

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 12

complexidade de processo que estamos realizando o levantamento, da
quantidade de áreas ou departamentos que o processo envolve, o traba-
lho de levantamento pode ser muito complexo.
Quando temos um excesso de pessoas envolvidas em um processo,
temos grande chance de encontrar uma série de dificuldades para con-
seguirmos realizar o processo de levantamento de processos, uma das
dificuldades principais é a compatibilização de agendas dos envolvidos e
o quanto cada um dos envolvidos realmente entende do processo.
Certa vez em um cliente fui realizar o levantamento do processo de
chegada de materiais, esse processo é de grande complexidade, pois en-
volvemos vários departamentos, e percebemos que alguns dados esta-
vam sendo contabilizados de maneira incorreta pelo sistema contábil.
Chegando na empresa fui encaminhado para o funcionário que realiza-
va a recepção dos materiais na portaria da empresa, o caminhão (ou outro
meio de transporte terrestre) chegava na recepção de entregas e apresen-
tava a nota fiscal para a pessoa da recepção, que digitava no sistema os
dados dessa nota e a conta contábil, fiquei muito interessado nesse pro-
cesso, e perguntei para o porteiro que realizava essa digitação, “Como você
faz a classificação contábil? Você consegue achar todas as classificações?
Seu treinamento foi bom, parabéns!”. O porteiro me respondeu: “Não foi
bom, aliás, nem tive treinamento, um amigo me falou algumas contas que
eu posso tentar para colocar, a primeira que entrar fica aquela mesma”.
Com essa declaração do porteiro fiquei mais preocupado ainda, deram
uma tarefa muito importante e não deram o devido treinamento para
a pessoa, essa é uma das principais falhas em processos empresariais.
Conseguimos detectar esse problema fazendo um levantamento dos pro-
cessos que estavam com problemas.
O levantamento das informações deve envolver ao menos um repre-
sentante de cada área envolvida no processo, pois esses representantes
de cada uma das áreas são as pessoas que vão comunicar as informações
sobre as necessidades de cada uma dessas áreas (necessidades de entra-
da e o qual será a saída em cada uma das fases do processo).

4.2. Modelagem dos Processos

Conforme CRUZ (2008), nesta atividade realizamos a modelagem dos pro-
cessos atuais e os novos, é muito importante realizarmos a modelagem
dos processos atuais para conseguirmos detectar onde estão os proble-
mas e como poderemos melhorá-los por meio de novos processos, com
vistas a gerar uma documentação clara dos processos criados, visando
uma melhoria contínua dessa atividade para que nossa empresa seja
mais competitiva.

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 13

 Devemos evitar o levantamento de informações excessivas no mo-
mento errado, nas reuniões de levantamento de processos, devemos nos
concentrar em coletar as atividades, fluxos, desvios comuns, exceções, os
atores e sistemas envolvidos, um modelo contendo essas informações já
está em um nível de refinamento para que possa contemplar os detalha-
mentos específicos de cada atividade.
O ideal é estabelecer os limites do detalhamento antes da reunião, e
sempre que possível, informar com antecedência aos participantes quais
os temas que serão tratados na reunião.
Conforme CBOK (2009), as duas abordagens que podemos usar no tra-
balho de levantamento e modelagem dos processos empresariais são o
top-down (de cima para baixo) e o bottom-up (de baixo para cima), vamos
estudar o que compreende cada uma dessas abordagens.

→→ Top-down (de cima para baixo): nesta abordagem iniciamos o tra-

balho de levantamento e detalhamento dos processos por uma vi-
são mais abstrata e genérica, e gradativamente vamos refinando as
informações e detalhando cada vez mais o processo que estamos
analisando ou modelando, normalmente essa abordagem é realiza-
da quando o trabalho inicia com entrevistas com os níveis hierárqui-
cos superiores);
→→ Bottom-up (de baixo para cima): nesta abordagem o levantamento
das informações para os processos é realizado ouvindo e coletando
informações dos atores das atividades (quem realmente as desem-
penha) operacionais, temos uma grande dificuldade nesta aborda-
gem, pois devemos agrupar essas atividades operacionais para reali-
zar a validação nos níveis superiores desses processos operacionais.

4.3. Aprovação dos Modelos

Conforme CBOK (2009), a aprovação dos modelos de negócios é um ato
formal onde é apresentado o modelo e validado pelas partes, algumas
pessoas consideram redundante propor a aprovação dos modelos, mas
devemos sempre ter as aprovações formais do trabalho realizado, e tam-
bém tem a finalidade de ratificar o entendimento sobre os processos e
o consenso da equipe entrevistada sobre a representação que foi apre-
sentada, para essa aprovação devemos ter presente o dono do processo
(como vimos na UA 3) e os departamentos que estão relacionamos dire-
tamente com esse processo (que realizam entrada ou se beneficiam das
saídas do mesmo).

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 14

5. Regras de Negócios
Segundo CBOK (2009) e BABOK (2011), regra de negócio é um conjunto de
condições para a realização de determinado trabalho, atividades ou ações
que compõe um processo.
Esse conjunto de regras ou condições muitas vezes estão “espalhados”
em diversos formulários, sistemas e procedimentos corporativos, quando
necessitamos criar as regras de negócios de maneira documentada, deve-
mos coletar todas essas informações para podermos organizá-la.
Essa organização das regras aceitas em nosso negócio é muito impor-
tante para não termos a regra de negócio holística (que é aquela que você
sabe como é, mas não sabe o motivo ou razão dessa regra).

papo técnico
Regras de negócios definem as normas que “governam” as
decisões em uma organização, que definem, restringem ou
possibilitam as operações organizacionais (BABOK, 2011).

Nessa etapa do trabalho, é realizado o levantamento de informações so-

bre o processo que é necessário modelar, é muito importante que sejam
levantadas informações sobre as regras de negócio, essas informações
estão “diluídas” na organização em formulários, sistemas computacionais,
bancos de dados, procedimentos corporativos e no “dia a dia” dos traba-
lhos dos colaboradores (pessoas) da organização.
As regras de negócios são tipos de requisitos de como uma organização,
incluindo suas ferramentas devem operar. Regras são leis regulamenta-
doras estabelecidas pelas empresas como forma de melhorar a qualidade
de seus sistemas.
Essas regras declaram e apresentam a maneira de como o negócio está
sendo feito, apresentando diretrizes e restrições com respeito a estados
e processos em uma organização. Com isso surge a necessidade de mo-
delar regras de negócios, dando importância em um esquema conceitual.
Segundo Cruz (2008), regras de Negócio possibilitam a execução corre-
ta das tarefas que, por qualquer motivo, sejam críticas num procedimen-
to. É necessário analisar cada tarefa e descobrir os detalhes que possam
fazer a criação de regras de negócio imprescindível para a correta execu-
ção da tarefa. São as regras de negócio que dizem quando fazer e como
fazer determinada tarefa.

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 15

 Políticas e Regras direcionam e restringem a organização e sua opera-
ção. Uma política de negócio é uma diretiva não acionável que apoia um
objetivo de negócio (BABOK,2011).
Uma regra de negócio é uma diretiva (instrução) destinada a influenciar
ou guiar o comportamento do negócio, como suporte a política de negó-
cio que é formulada em resposta a uma oportunidade.
Regras particulares complexas, ou regras com uma qualidade razoável
de dependências inter-relacionadas, podem ser expressas como uma ta-
bela de decisão, que expressa em forma de tabela o conjunto de decisões
que é necessário ocorrer para que um determinado conjunto de ações
seja executado ou como uma árvore de decisão, que apresenta de manei-
ra gráfica as consequências de decisões atuais e futuras, como eventos
aleatórios relacionados, permitindo controle.
Segundo o BaBok (2011), as regras de negócio devem ser:

→→ Declaradas em terminologia apropriada para permitir que especia-

listas no assunto validem as regras;
→→ Documentadas independentemente de como elas são impostas;
→→ Declaradas em nível atômico e em formato declarativo;
→→ Separadas dos processos que a regra apoia ou restringe;
→→ Mantidas de forma que permita que a organização monitore e adap-
te as regras conforme as políticas do negócio mudam.

As regras de negócio podem ser operativas e estruturais. A seguir va-

mos verificar como esses dois tipos de regras de negócio são utilizadas
nas organizações.

5.1. Regras operativas

Segundo BABOK (2011), regras operativas são regras que a organização
escolhe para impor como uma questão de política. Elas são destinadas
a guiar as ações das pessoas que trabalham dentro da organização. Elas
podem obrigar as pessoas a tomar certas ações, evitar que as pessoas
tomem certas ações ou prescrever condições sob as quais uma ação deve
ser tomada. Por definição, deve ser possível para as pessoas violar uma
regra operativa, mesmo quando não há circunstancias sob as quais a or-
ganização aprovaria este ato.
Exemplos de regra operativa:

→→ Um pedido realizado pelo cliente de uma loja virtual deve ser entre-
gue em um endereço não constante no cadastro do cliente, e este
mesmo cliente está realizando compras consideradas fora de seu

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 16

 perfil de compra. – Quando este tipo de “regra” operativa ocorre
em uma loja virtual, o departamento de gerenciamento de riscos do
negócio entra em ação para verificar a possibilidade de algum tipo
de  fraude;
→→ Não desligar o projetor multimídia antes que o ventilador tenha pa-
rado de funcionar. (Isso diminui a vida útil da lâmpada do projetor,
sempre muito cara);
→→ Uma vez que é possível violar uma regra operativa, uma análise pos-
terior pode ser conduzida para determinar quais tipos de sanções
devem ser impostas quando uma regra é violada, permitir que uma
regra seja desconsiderada (antes ou depois do fato) ou as circuns-
tâncias nas quais uma exceção à regra é apropriada. Isso pode levar
a definição de regras adicionais.

5.2. Regras estruturais

Segundo BABOK (2011), regras estruturais são destinadas a auxiliar na
determinação de quando algo é, ou não, verdadeiro, ou quando as coisas
se encaixam dentro de uma categoria específica. Elas são expressas como
regras porque elas descrevem categorizações que podem mudar ao longo
do tempo. Uma vez que elas estruturam o conhecimento da organização,
e não o comportamento das pessoas, elas não podem ser violadas (po-
rém, podem ser mal aplicadas). Exemplo de regra estrutural:

→→ Um pedido deve ter relacionado apenas um método de pagamento

(cartão de crédito, cartão de débito, boleto, transferência eletrônica
de fundos, etc);
→→ Contas a receber: títulos vencidos em D+1, cobrar multa de R$10,50
por atraso, mais juros de mora de R$ 1,50 por dia de atraso.

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 17

antena
parabólica
O levantamento e modelagem de processos é consi-
derado um dos principais elos de ligação entre os de-
partamentos administrativos (muitas vezes citados nas
bibliografias como áreas funcionais) e as áreas técnicas
(uma das principais é a área ou departamento de infor-
mática), esse levantamento e modelagem de processos
tem como principal finalidade realizar a documentação
de como os processos empresarias devem realmente
funcionar, para que não tenhamos pessoas ou sistemas
executando processos de maneira diferente. Podemos
observar processos executados de maneira diferente em
várias empresas, como por exemplo, quando vamos ou
ligamos para uma empresa cada um dos funcionários
passam informações e requisitos diferentes para conse-
guirmos realizar uma determinada tarefa.
Isso se deve pela falta de padronização, ou ainda pela
falta do levantamento e modelagem dos processos, mui-
tas vezes essas informações “desencontradas” não se
devem pela “má vontade” dos colaboradores, mas pela
falta de padronização (ou modelagem dos processos) e
cada uma das pessoas envolvidas comunicam informa-
ções diferentes, e isso pode gerar descontentamento
dos clientes.
Imagine em um processo de realização de matrícula
em um curso: se o processo não estiver bem documen-
tado (ou modelado) cada um dos atendentes pode nos
solicitar mais documentos que os necessários, outro
pode nos solicitar menos documentos que os necessá-
rios e um terceiro os documentos realmente necessá-
rios, essa divergência pode ocorrer principalmente pelo
tempo de experiência do atendente na empresa e o que
está presente mais tempo nessa empresa, considera
esse procedimento “automático”, mas não existe uma
documentação formal, ou seja, os novos funcionários
não sabem exatamente o que devem solicitar. Essa é
uma das situações ou cenário que o levantamento e a
modelagem de processos é necessário, aqui exemplifica-
mos um cenário simples, que não causa muito impacto,
mas em outras situações, a falta dessa documentação
pode causar grandes prejuízos financeiros e para a ima-
gem da organização.
Esse levantamento e modelagem de processos é rea-
lizado por profissionais da área administrativa, principal-
mente por esses profissionais terem um conhecimento
amplo da empresa, e passam essas informações para os
profissionais de informática para que esses realizem a
automatização dos processos.

E agora, José?
Nesta unidade vimos a importância do levantamento e
da modelagem de processos empresariais, na próxima
unidade, vamos tratar dos conceitos relacionados ao e-
-commerce, assim conseguiremos ter nas empresas um
sistema de informações efetivo e globalizado, utilizando
o meio internet para isto, que é de suma importância em
nosso dia a dia empresarial.
Até a próxima aula e bons estudos!
Referências
Babok. Um guia para o Corpo de Conheci-
mento de Analise de Negócios
BOK). Versão 2.0, versão PT_BR, 2011.
CBOK, BPM. G
 uia para o Gerenciamento de
Processos de Negócio – Corpo Comum de
Conhecimento, Brasil, 2009.
CRUZ, Tadeu. B
 PM &BPMS – Business Process
TM
(Guia BA- Management & Business Process Mana-
gement Systems. Rio de Janeiro: BRAS-
PORT, 2008.
TURBAN, Efraim et. al. I ntrodução a Siste-
mas de Informação. Rio de Janeiro: Cam-
pos, 2007.

Sistemas de Informação  /  UA 10  Levantamento e Modelagem de Processos 20