Gerenciamento de Processos de Negócios - Modelagem de processos (CEFET-ES)

Prévia do material em texto

Gerenciamento de 
Processos de 
Negócios
Modelagem de processos
Material Complementar
Prof. D. Sc. Roquemar Baldam
Pós Graduação em 
Engenharia de Produção
BPMN
Componentes básicos dos diagramas 
de modelagem BPMN 
A seguir são apresentadas apenas as simbologias básicas para interpretação dos 
diagramas em BPMN.
Elemento Descrição Notação 
Evento Um Evento é algo que “ocorre” 
durante o curso de um processo. 
Estes eventos o fluxo do processo e 
usualmente possuem uma causa 
(gatilho) ou um impacto (resultado). 
Três tipos são possíveis: início 
(inicia o processo), intermediário e 
final (finaliza o processo). 
Eventos com 
designação de tipos 
Os eventos podem ter designados a 
causa de sua existência. 
Tarefa (atômica) Uma tarefa é uma atividade de 
pouca abrangência (atômica). É 
usada quando o trabalho no 
processo não será mais detalhado 
em níveis inferiores de detalhamento 
gráfico. 
Subprocesso 
comprimido 
Os detalhes do subprocesso não 
estão visíveis no diagrama. Um sinal 
“+” indica que este subprocesso 
possui níveis adicionais de 
detalhamento. 
1
Subprocesso 
expandido 
As fronteiras do subprocesso é 
expandida e os detalhes do mesmo 
são visíveis dentro da fronteira. 
Note que a seqüência do fluxo não 
poderá cruzar a fronteira do 
subprocesso. 
Portal (gateway) É usado para controlar a divergência 
ou convergência de múltiplas 
seqüências de fluxos. Determinará a 
geração de ramificações, 
bifurcações e uniões de diversos 
caminhos do fluxo. 
Portal – tipos de 
controles 
Os ícones com o losango indicarão o 
tipo de comportamento do gateway:
XOR: Decisão ou união exclusiva 
OR: Decisão ou união inclusiva. 
Uma ou outra opção podem ser 
aceitas 
Complexa: Múltiplas opções são 
aceitas. 
AND: junção ou separação paralelas 
Seqüência de fluxo 
normal 
Refere-se ao fluxo originado a partir 
de um evento e continua através de 
atividades até o evento final, não 
dependente de condições. 
Seqüência de fluxo 
condicional 
O fluxo seguirá dependendo de 
condições estabelecidas. Somente 
usada este representação quando 
não for usada a representação 
condicional com o losango. 
Seqüência de fluxo 
condicional padrão 
(default) 
Usado quando a opção de decisão é 
a predominantemente mais usada, 
ou seja, é uma resposta padrão. 
Exceção em fluxo Ocorre quando algo ocorre fora do 
planejado para o fluxo e é baseado 
em um evento intermediário que 
ocorre durante a execução do 
processo 
2
Fluxo de 
mensagem
É usado para mostrar fluxo de 
mensagens entre duas entidades 
que podem enviar e recebê-las. No 
BPMN, duas piscinas (pools) 
separadas num diagrama 
representarão duas entidades, 
Associação de 
compensação 
Ocorre fora do fluxo normal e é 
baseado em evento que é acionado 
por uma falha de transação. O 
objetivo da associação (atividade) 
deve estar marcada com tal, com 
setas de retorno. 
Objeto de dados São considerados artefatos por que 
não possuem qualquer efeito direto 
sobre o fluxo de atividades ou 
mensagens, mas provê informação 
sobre o que atividades requerem 
para serem executadas e/ou o que 
produzem. 
Distribuição (Fork – 
AND) 
Usado para dividir um caminho em 
dois ou mais caminhos paralelos. A 
tarefa passará a ser executada de 
modo concorrente. 
Pode ser representada de dois 
modos,conforme ao lado. 
Junção (Join – 
AND) 
Usado para juntar dois caminhos 
paralelos em um único caminho, 
como forma de sincronização. 
Decisão baseada 
em dados 
A alternativa a seguir depende do 
atendimento às condições expostas. 
Somente um caminho poderá ser 
seguido. 
3
Decisão baseada 
em evento 
A alternativa a seguir dependerá do 
evento que ocorre no processos. 
Normalmente um tipo de mensagem 
seria o evento que determinará o 
caminho a seguir. Outros tipos de 
eventos, como Cronômetros, podem 
ser usados. Somente uma 
alternativa é possível. usados. 
Decisão inclusiva Representa ponto onde as 
alternativas são baseadas em 
expressões condicionais. 
Uma condição padrão (default) pode 
ser usada. 
Junção (OR – Join) Combinação de dois ou mais 
caminhos em um único caminho, 
mas não em paralelo, ou seja, 
bastará vir de uma das direções 
para encaminhar o processo. 
Atividade em 
repetição (looping)
Indica que uma atividade deve ser 
repetida uma ou mais vezes, se uma 
condição interna não for atendida. 
Um símbolo de repetição é colocado 
na parte central inferior da atividade. 
Seqüência em 
repetição (looping)
Repetição pode ocorrer em 
seqüências de atividades. 
Instâncias múltiplas Determinará se instâncias múltiplas 
da atividade podem ocorrer em 
paralelo. Um indicador com duas 
linhas em paralelo indica esta 
condição. 
Interrupção de 
processo (algo fora 
do controle do 
processo faz o 
mesmo parar) 
Mostra quando é esperado um 
período de espera dentro de um 
processo. Um evento intermediário é 
usado. 
4
Transação É um subprocesso que é suportado 
por um protocolo especial que 
garante que todas as partes 
envolvidas tenham concordado que 
a atividade foi completada ou 
cancelada. 
Uma linha dupla indica que o 
subprocesso é uma transação, 
Grupo Um grupo de atividades que são 
marcadas dentro de um retângulo 
para fins de documentação ou 
análise. Não afeta o andamento do 
processo. 
Conector de 
páginas 
Geralmente usado em impressão, 
este objeto é utilizado para indicar 
onde o fluxo deixa uma página e 
inicia em outra. Um evento 
intermediário de ligação é usado 
como conector de páginas. 
Associação É usado para associar informações 
com objetos do fluxo. Textos e 
objetos que não sejam do fluxo 
podem ser associados com objetos 
do fluxo. 
Anotação de texto É um mecanismo para adicionar 
informação complementar ao 
diagrama. 
Piscina (pool) Representa a porção maior do 
processo e contém as raias (lanes) 
que conterão por sua vez as 
atividades, eventos, etc. 
Em um contexto de B2B pode-se ter 
mais de uma pool para descrever o 
processo como um todo. 
Raias (lanes) É uma partição da piscina e se 
estende por toda sua extensão. 
Pode ser vertical ou horizontal (mais 
comum). 
Normalmente, o nome que encabeça 
cada raia é o papel funcional que 
executará as atividades nela contida. 
5
Ilustrações básicas para 
acompanhamento da aula 
6
7
8
9
10
11
12
EPC
Event-driven Process Chain 
DAVIS, Rob; BRABÄNDER, Eric. Aris design platform. Getting 
Started with BPM. London: Springer-Verlag, 2007. Capítulo 7.
13
Chapter 7 The Event-driven Process Chain 
In this chapter we look at the Event-driven process chain that forms the core 
of the ARIS Method. We explore how it is built using events, functions and 
rules and how to model decisions, parallel paths, loops and process flows.
7.1 Introduction 
The Event-driven process chain (EPC) is the main ARIS model for representing 
processes. It is a dynamic model bringing together the static resources of the business 
(systems, organisation, data, etc.) and organising them to deliver a sequence of tasks 
or activities (‘the process’) that adds business value. There are several varieties of 
the EPC (row, column, etc.), but in this book we will concentrate on the basic 
EPC. The majority of other models in ARIS give views of the basic information 
and relationships presented in the EPC. 
7.2 The EPC Objects 
Essentially there are four types of objects used in the EPC: 
x Events,
x Functions,
x Rules,
x Resources (data, organisation, system, etc.). 
Fig. 7.1 shows an example EPC model of a process fragment using the four object 
types above. In this chapter we will look at the first three types and show how they 
areused to model process flow. In Chapter 11 we will see that by adding resource 
objects we can show how the process interacts with its environment.
7.2.1 Events 
ARIS Events represent the changing state of the world as a process proceeds: 
x External changes that trigger the start of the process 
(e.g. “customer order received”),
x Internal changes of state as the process proceeds 
(e.g. “product manufactured ”),
x The final outcome of the process that has an external effect 
(e.g. “order delivered to customer”).
14
106 The Event-driven Process Chain 
To borrow a software engineering term: events represent the ‘pre-conditions’
and ‘post-conditions’ for each step in the process. Pre-conditions are those things 
that must be present, or must have happened, before an activity can start. Post-
conditions represent what has changed as a result of doing the activity. Events can 
occur as a result of things people do or as a result of an IT system operation. The 
final event in one process can be the trigger for another process and in that way we 
can link sections of processes together to form a larger ‘end-to-end’ process. 
To describe events, we typically use the convention ‘noun–verb’ or, more spe-
cifically in an IT environment, ‘information item – action’ (see Table 7.1). 
Description Noun (information item) Verb (action)
“Order Entered” Order Entered
“Cost Calculated” Cost Calculated
is evaluated byis evaluated by
Event
Inquiry is
received
activates
XOR Rule
Event
Inquiry to
be created
activates
creates Event
Customer
inquiry is
opened
creates Event
Car is
configured
Function
Open
customer
inquiry
Function
Configure
product
system type
Organizational
unit
executescan support
Entity type
is input for
Document
creates output to
Application
Resources
Event
Rule Operator
Function
Fig. 7.1 Typical EPC Process Model 
Table 7.1 Naming Events 
15
7.3 The Event-driven Process Chain 107
7.2.2 Functions 
ARIS Functions represent the activities or tasks carried out as part of a business 
process; ideally with each one adding some value to the business. Functions may be 
carried out by people or by IT systems. They have inputs (information or material), 
create outputs (different information or a product) and may consume resources.
In Chapter 11 we shall look in more detail at the exact nature of processes, acti-
vities and functions. We shall see they are in fact ‘transformations’, but for the 
moment we can just think of functions as ‘doing something’.
To describe functions we use the convention ‘verb–noun’ or more specifically, 
‘action – information item’ (see Table 7.2). 
Description Verb (action) Noun (information item)
“Enter Order” Enter Order
“Calculate Cost” Calculate Cost
“Sell Product” Sell Product
Expert Tip – it is quite common to use terms such as “sales” or “mar-
keting” to represent high-level business operations. However, it is too 
easy to confuse these with the names of business departments. It is bet-
ter to use the ‘verb–noun’ approach to describe what is really done (e.g. 
“Sell Product”).
It is important not to use ambiguous or long-winded descriptions for functions. 
In more detailed process models functions will represent specific, well-under-
stood, activities (e.g. “Enter Order”). However, when modelling high-level opera-
tions it can be tempting to have long descriptions (e.g. “Receive order, validate, 
process and inform customer”). It is better to have one succinct title or split the 
function into several separate functions. 
7.3 The Event-driven Process Chain 
Functions are triggered by one or more events. In ARIS terminology an event 
“activates” a function and a function will always “create” one or more new 
events. So events trigger functions, and functions produce new events which in 
turn trigger further functions, and so on, to produce a chain of functions and 
events – the Event-driven process chain (Fig. 7.2). In fact the Event-driven pro-
cess chain should really be called the Event-driven function chain.
Table 7.2 Naming Functions 
16
108 The Event-driven Process Chain 
Hint – in the previous chapters we showed example EPC fragments 
exactly as they appear in the Designer Module. We will be looking at 
many EPC examples in this chapter so to make them easier to read on 
the printed page we have turned off the background colours of the objects 
and made the connecting lines bolder.
In reality processes are not a simple chain of events 
and functions and we need to introduce the concept 
of process flow. Process flows are built around deci-
sions and parallel paths.
Decisions that change the process flow are always 
taken by functions, but to represent the logic of the 
possible outcomes we need to introduce ‘Rules’. We
briefly introduced those in Chapter 5, but we shall 
People who are used to other modelling methods 
and tools that don’t have the concept of the Event-
driven process chain often wonder about the value of 
introducing events. They are more used to just string-
ing functions together one after another. We shall see 
in Section 7.3.2 that the addition of events to the pro-
cess model introduces a degree of rigour that makes 
ARIS models a more accurate representation of the 
‘real world’ and hence increases their value.
The important rules to bear in mind when using 
the Event-driven process chain are:
x Every model must have at least one start event 
and one end event, 
x Functions and events always alternate. 
Functions should not normally connect to another function and events should 
never connect to other events. With simple models it is easy to ensure the ‘greens’
and ‘purples’ always alternate, but in larger models, with many rules, it can be a 
bit trickier to ensure this rule is followed. The easiest way to do this is just to fol-
low each path, ignore the rules, and check that the functions and events alternate.
Expert Tip – creating an appropriate Method Filter can be used to 
enforce modelling conventions such as not allowing functions to con-
nect to other functions. 
7.3.1 Naming Events in the EPC 
The naming of events in the EPC requires some additional explanation. The way 
we view the events depends to a large extent on whether they are at the start of the 
process, the end of the process, or in the middle (Fig. 7.3). 
Event
Order
Received
Event
Order
Entered
Event
Cost
Calculated
Function
Enter
Order
Function
Calculate
Cost
Fig. 7.2 Event-driven 
look at them in more detail in Section 7.4. 
Process Chain 
17
7.3 The Event-driven Process Chain 109
Start Event 
The event at the top of a process represents the change in the external world that 
causes the entire process to be initiated. It triggers the first function in the process 
and its name is normally chosen to be something meaningful and significant to the 
process as a whole, rather than just something relevant for the first function. Thus 
we might call the event “Customer Order Received ” rather than “Envelope in Post 
Tray ”.
End Event 
The event at the end of the process represents the completion of the whole process 
(or that part of it described in the model). The end event may often be the trigger 
for a further process in another model, so it is wise to choose a name that is mean-
ingful when viewed at the end of the model or at the start of another. Its name is 
not, therefore, necessarily directly related to the function that created it which may 
be of little importance.
In the example shown in Fig. 7.2, the last event was Cost Calculated. In real-
ity, therewould probably be further functions and events after this step, but if it 
really were the end of the process, we would probably give it a more significant 
name such as “Order Entry Complete”.
Event
Start
Event
Event
Middle
Event
Event
End
Event
Function
Function
Function
Function
Name as trigger for 
entire process
Name as outcome of 
preceding function
Name as outcome of 
entire process
Fig. 7.3 Naming Events 
18
110 The Event-driven Process Chain 
Internal Events 
Events in the middle of a process, those connecting the sequence of functions 
together, are both trigger events for the following function and outcome events for 
the preceding function. That gives us a problem; do we label them to reflect what 
has just happened or what is about to happen? The normal convention is to name 
them to reflect the outcome of the previous function. As we shall see below, this 
helps us to establish that we have correctly described what the functions do and 
how the process flows.
In processes where there is a long sequence of functions and events without any 
change in control flow, the names of the intervening events will be trivial and will 
not add much value. Some people are tempted to miss these events out, but this 
can be dangerous as we shall see later. However, occasionally, an event may denote 
that a significant stage in the process has been reached. In this case, it is perfectly 
acceptable to give the event a more significant name, just as we did with the ‘end
event’. Such naming should be used sparingly to create more effect.
7.3.2 Why Use Events? 
People new to ARIS, especially those who have used other flowcharting or model-
ling tools, often wonder about the value of adding events between every function. 
Why not just connect functions directly together as shown in Fig. 7.4a? In ARIS it 
is possible to connect functions together, if this is enabled in the Method Filter. 
However, there are good reasons not to do this because adding and naming events 
is:
x a good check of correct definition of the function, 
x a good check of correct process flow. 
The first reason for not directly connecting functions together is that the disci-
pline of working out what event follows a function is an extremely good check 
that the function has been correctly described: 
x Does the function really occur as a consequence of the event? 
x Does the event always trigger the function or are there other conditions that 
must also be met? 
Also look at the event following the function: 
x Does it describe what has changed as a result of executing the function? 
x Is it the only outcome or are there several alternatives? 
If you can’t work out what has changed, it is likely that the definition of the 
function is not correct. If rather a lot seems to have changed, did all this change as 
a result of this one activity? It may be that what the function is representing is not 
really just one activity, but a number of activities (parallel or sequential) wrapped 
up together that would be better shown separately. Check if the granularity and 
importance of this function is similar to those in the rest of the model.
19
7.3 The Event-driven Process Chain 111
The second reason for using events is that the careful consideration of the event 
following a function will make it clear where decisions are being made that affect 
process flow. Look again at the process just using functions in Fig. 7.4a. The process 
looks like a straightforward chain of activities: Enter Order, Check Order and 
Manufacture Product. But now look at the process in Fig. 7.4b where events have 
been added between the functions. In particular, look at the event following the 
function Check Order. What should this be called? It is tempting to label it “Order
Checked ”. At first sight this looks correct, but look again; does it really make 
sense? What has changed as a result of checking the order? It is too simplistic to 
say the order has been checked. Why has the order been checked?
The step adds no value unless there is a reason for checking the order and hence 
more than one possible outcome. People often make this mistake when first starting 
to use ARIS. If asked “why was the order checked?” modellers nearly always know 
why (e.g. to see if the order is valid or if it is above a certain monetary value) yet 
they have not reflected this knowledge in the model. As a result, they miss the obvi-
ous fact that there is more than one outcome from executing the function. The 
function not only carries out the check, but also makes a decision about what should 
happen next. 
Order
Received
Order
Entered
?
Enter
Order
Check
Order
Enter
Order
Check
Order
Manufacture
Product
Order
Received
Order
Entered
Order
Valid
Enter
Order
Check
Order
XOR
Manufacture
Product
Order
Reject
Order
Invalid
(a) Process just 
with functions
(b) Process with 
events added
(c) Correctly 
modelled process
But what is 
this event 
called?
Actually 
there are two 
events
This 
function 
makes a 
decision
Rule
Fig. 7.4 The Benefit of Events 
20
112 The Event-driven Process Chain 
If we now look at the correct process model in Fig. 7.4c we can see there is a 
rule after the function which is followed by two events. These events now repre-
sent the two possible outcomes of the decision taken by the Check Order func-
tion. The rule represents the logic of the outcome (e.g. with an XOR only one of 
them can occur at any one time). We will look at rules in detail in Section 7.4. 
In the simple example above we assumed there was only one outcome from 
Enter Order, but two outcomes from Check Order. Of course, it is also possible 
there may be more than one outcome from Enter Order. For instance, order entry 
might fail and alternative action may be necessary. It is a matter of judgement how 
much detail you will need to model. Remember: 
“Don’t model the universe!”
“Know when you have done enough.”
“Define standards and stick to them.”
Thus, far from being an unnecessary effort, the addition of events between 
functions adds a degree of rigour to process modelling. This helps ensure the 
models are a more accurate reflection of what really happens. The disadvantage is 
the models become larger, which makes concise presentation more difficult. 
If you really must, you can remove the ‘trivial’ events between strings of func-
tions, particularly in high-level models. However, we would strongly recommend 
you initially build your models with all the events in place. Only once you are 
confident the model is correct should you delete the trivial events 
7.4 Rules and Process Flow 
As we said above, real processes do not just consist of sequential steps. The need 
to cope with parallel paths, decisions, multiple triggers and complex flows is the 
reason we use modelling tools to represent processes. To model a process flow we 
add ‘Rules’ to the functions and events previously described. We saw an example of 
this in the previous section (Fig. 7.4c) where there were two possible outcomes 
from a decision, only one of which can be true at any one time.
7.4.1 Rules 
There are three basic types of rule, as shown in Table 7.3, and they have slightly 
different usage depending on whether they follow or precede functions.
Understanding the flow of process models requires an understanding of how 
rules combine with functions and events to represent decisions and parallel paths. 
Decisions (see Section 7.5) use OR and XOR rules, while parallel paths (see Sec-
tion 7.6) use AND rules. Some combinations are not valid in anycircumstances 
while others are valid, but are confusing so we will not show them. If you use the 
rules as defined above and in the examples that follow, you will be able to cor-
rectly model the majority of process flow situations.
21
7.5 Decisions 113
Operator Following a Function 
(single input, multiple outputs)
Preceding a Function 
(multiple inputs, single output)
OR OR – Decision
One or many possible paths 
will be followed as a result of 
the decision.
OR – Trigger 
Any one event, or combination 
of events, will trigger the Func-
tion.
XOR Exclusive OR – Decision
One, but only one, of the possi-
ble paths will be followed. 
Exclusive OR – Trigger
One, but only one, of the possi-
ble events will be the trigger. 
AND AND – Parallel Path 
Process flow splits into two or 
more parallel paths.
AND – Trigger 
All events must occur in order 
to trigger the following Func-
tion. 1
events must occur in order for the AND trigger to be valid. 
Expert Tip – to change a rule to one of a different type (e.g. OR to 
XOR), select the operator, Right-Click > Properties [Format / Object
Appearance] and select the new operator from the Symbol field scroll 
box. Then select the Attributes Tab on the Properties Bar and change the 
Name attribute of the operator. 
7.5 Decisions 
In the ARIS EPC modelling method decisions are made by functions; the name of 
the function describing the decision being taken. 
7.5.1 Modelling Decisions 
The function makes the decision and connects to a rule which determines the logic 
of the possible outcomes (e.g. OR or XOR). The rule has a single input and two or 
more outputs. The outputs lead to events that indicate which particular outcome of 
the decision has triggered that path of the process (see Fig. 7.5b).
You should avoid having OR or XOR rules following an event because there is 
no function to make the decision about which path to follow. You do sometimes 
see this in top-level models. For instance, in Fig. 7.5a an event Order Received
connects to an OR which connects to parallel paths that each process a different 
type of order. The assumption here is that when the order is received it is routed to 
the appropriate path of the order-handling process. 
Note 1: It may be necessary to consider a time period during which all the 
Table 7.3 ARIS Rules 
22
114 The Event-driven Process Chain 
Although this shorthand approach keeps the model simple, it can give a false 
impression of what is actually happening. If the order is actually routed to differ-
ent processes, it is better to model the function that representing the routing deci-
sion, even if it is automatic (Fig. 7.5b). If, on the other hand, the orders aren’t routed 
to the particular process, but the customer sends the order to a different address 
depending on the product, then they are in fact entirely separate processes and it is 
a mistake to model them as if they were one.
Incorrect modelling of decisions is one of the most common mistakes people 
make using ARIS (after not modelling decisions at all!). Typically people don’t 
model what actually happens, but some idealised version of it. This only leads to 
problems later during implementation, analysis or re-design. 
7.5.2 Decision Rules 
There are two rules we can use to represent decisions: 
x OR – Any combination of paths, 
x XOR – One path or the other, but not both. 
It is very tempting to model everything using an OR operator because this is the 
term we use in everyday language. However, in practice most decisions can only 
take one of the possible outcomes and hence should be modelled using the XOR.
The exceptions to this are situations similar to the order-processing example 
above. For example, imagine a business with different processes for delivering each 
different product it sells. When an order arrives it might be for just one product, or 
XOR
XOR
Manufacture
Product B
Manufacture
Product A
Product A
Ready
Manufacture
Product B
Manufacture
Product A
Order
Received
Product B
Ready
Order
Received
Check
Product
Ordered
Product A
Required
Product B
Required
Rule 
determines 
logic
Events 
show 
outcomes
What are 
the 
possible 
outcomes?
Function
makes 
decision
What makes the 
decision which 
path to follow?
(a) Incorrect (b) Correct
Fig. 7.5 Modelling Decisions 
23
7.5 Decisions 115
it may be for a combination of products. To model this situation you should use an 
OR operator after the function to allow for any combination of processes flows to 
be initiated. However, you should remember that later in the process there must 
be a step that makes sure the correct combination of products has been assembled 
before final delivery (see Fig. 7.6). These situations are not that common, so we 
can state the general rule: 
x Always model decisions with an XOR unless you are certain multiple combi-
nations can actually occur. 
7.5.3 Joining Decision Paths 
The result of a decision is to send the process down one or more alternative paths. 
Sometimes one of those paths may be a dead-end where the process stops but, 
normally, the paths join back together at some point to complete the process. The 
join should always be made using the same rule used to make the split after the 
decision, as shown in Fig. 7.6. 
(b) Joining After Functions
Order
Received
Product B
Ready
Manufacture
Product B
Product A
Ready
Manufacture
Product A
Check
Products
Required
Product B
Required
Product A
Required
Pack
Products for
Delivery
Products
Ready for
Delivery
OR
Required
Products
Ready to
Pack
OR
Order
Received
OR
Manufacture
Product B
Manufacture
Product A
Check
Products
Product B
Required
Product A
Required
OR 
Use same 
rule type 
to split and 
join
Last event 
in model
(a) Joining After Events (b) Joining After Functions
Fig. 7.6 Joining Decision Paths 
24
116 The Event-driven Process Chain 
Order
Received
Product A
(Variant A)
Ready
OR
Manufacture
Product A
(Variant B)
Product B
Ready
Manufacture
Product B
Check
Products
Required
Product A
Required
Product B
Required
Assemble
Products for
Delivery
Products
Ready for
Delivery
OR
Check
Variant
Required
XOR 
Variant
B
Variant
A
Manufacture
Product A
(Variant A)
XOR 
Order
Received
Manufacture
Product A
(Variant B)
Product B
Ready
Manufacture
Product B
Check
Products
Required
Product A
Required
Product B
Required
Assemble
Products for
Delivery
Products
Ready for
Delivery
OR 
Check
Variant
Required
XOR 
Variant
B
Variant
A
Manufacture
Product A
(Variant A)
XOR 
Product A
(Variant B)
Ready
OR 
Product A
Ready
(a) Multiple Joins (b) 
Fig. 7.7 Multiple Joins
25
7.5 Decisions 117
The question arises: should the join be made after the events in the alternative 
paths or after the functions? Provided you ensure the functions and events cor-
rectly alternate, it doesn’t really matter. Normally it is better to have the join after 
the events (Fig. 7.6a) so the event at the end of each path marks the completion of 
the path. The ‘joining’ rule is then followed by a function.
If you need to make the join at the very end of a process, often there are no 
other functions after the join and before the final event. In this case you will have 
to put the rule before the final event and the paths must end in functions (Fig. 
7.6b). Often, paths split from several different decisions will join at the samepoint. In that case, although you can bring all the joining paths together at the 
same rule, it is good practice to use individual rules and join the rules as in Fig. 
7.7a. This is essential if the rules are of different types (e.g. OR and XOR).
Fig. 7.7b shows an alternative approach. The OR rule that joins the path from 
the Product B Required flow is separated by an event (Product A Ready) from 
the XOR rule that combines the paths from the Product A Required flow. This is 
possible because the Variant A and Variant B paths in the Product A Required 
flow have been modelled ending in functions. Although we said it was generally 
better to end paths in events, this representation probably leads to a clearer model. 
This just goes to show there is no single correct way to model a process. Provided 
you follow the alternating event–function chain you may choose the representation 
that seems to make the most sense in terms of the process you are modelling.
7.5.4 Do-nothing Decision Paths 
You make think paths resulting from decisions where nothing subsequently hap-
pens would be pointless, but in fact they occur quite often. Look at the example in 
Fig. 7.8a. If the paint is still wet we have to wait for it to dry before applying the 
second coat. If the paint is already dry we can carry straight on to apply the second 
coat so there is no need for a task, and hence a function, in the “paint dry” path. 
Fig. 7.8b shows an alternative way to represent this. This time there is no event 
or function in the “paint dry” path, but just a connecting line. The left-hand 
example has the advantage that the events after the rule make it clear what the 
outcome of the decision is. On the other hand, the right-hand example looks 
cleaner and it is very obvious nothing happens in the “paint dry” path. However, it 
is not so clear which outcome triggered the “do nothing” path and we have had to 
resort to putting a label on the path to make it clear. Once again you have to 
choose the most appropriate method for the process you are modelling. 
Warning – if you should need two events with the same name, it is 
essential you create two separate events. On no account should you 
copy the event object. In any case, it is good practice to make the names 
of similar events slightly different. 
If we didn’t need a second coat and Paint Dry was the end of the process, we 
would have no choice but to use the right-hand representation, because we need to 
end the process in an Event. 
26
118 The Event-driven Process Chain 
7.6 Parallel Paths 
Parallel paths use the AND rule which separates the process into two or more 
paths. The paths normally re-combine in an AND later on in the process. When 
they re-combine, the process cannot continue until all the paths joining at the AND
have been completed. In the example in Fig. 7.9 we now have to complete both 
the Manufacture Product A and Manufacture Product B flows for every order.
The AND split is normally made after an event, and best practice is to re-combine 
after the last event in the parallel paths. Again this is not a hard and fast rule. You 
can re-combine after functions and put a single event after the AND which repre-
sents all the paths being completed.
First Coat
Applied
Paint
Wet
Check
Paint Dry
XOR 
Wait for
Paint Dry
Paint
Dry
Apply
Second
Coat
Paint
Now Dry
XOR 
First Coat
Applied
Paint
Wet
Check
Paint Dry
XOR
Wait for
Paint Dry
Apply
Second
Coat
Second
Coat
Applied
Paint
Dry
XOR
Second
Coat
Applied
Paint Dry
(a) (b) 
Fig. 7.8 Do-nothing Paths 
27
7.7 Triggers 119
The former is better for long complex process 
paths and the latter for simple parallel tasks.
Splitting the process into parallel paths implies 
they can be done at the same time because they 
have no dependence on each other. Of course, just 
because you have modelled it that way, doesn’t 
mean they will actually happen at the same time. 
There may be no process dependence, but if the 
same person has to do both tasks, then only one 
can be done at a time. Even if different people do 
the tasks, there is still no guarantee they will work 
in parallel; there could be a significant gap be-
tween the one branch completing and the other 
even starting. Collecting real process data will en-
able you to check if the process is being executed 
as you intended. Simulating the process with ARIS
Simulation will enable you to check if the allo-
cated resource can achieve what you intended. 
7.7 Triggers 
7.7.1 Basic Triggers 
Most of the examples so far have a single event triggering the start of the process. 
The event represents a change of state in the external environment that requires 
the process to start. 
When defining trigger events it is important to make sure the event, by itself, is 
sufficient to trigger the process. For instance, an order received by telephone is an 
obvious trigger. The telephone rings, someone answers it and takes the order. 
Similarly, an order received by FAX also seems to be a trigger. If you were mod-
elling the sales process at a high-level you would certainly show telephone and 
FAX as alternative triggers. However, at a more detailed level, they may not be 
equivalent. There is no guarantee that when a FAX arrives anyone will notice and 
process the order. It may be necessary to design a process where, periodically, 
someone checks the FAX and deals with the orders.
Processes often fail because tasks that are ‘so obvious’ are not modelled and 
as a result no one does them; everyone assumes someone else does it. A good 
example is an Internet web site that gives an e-mail address for making contact, 
but when you send a message no one ever replies! 
Always scrutinise your events and apply the following tests: 
x Does the event represent an external ‘change of state’? 
x Does the change of state itself directly trigger the process as opposed to just 
influencing it? 
Order
Received
Product B
Ready
Manufacture
Product B
Products
Ready for
Delivery
Product A
Ready
Pack
Products
Manufacture
Product A
AND 
AND 
Fig. 7.9 Parallel Paths 
28
120 The Event-driven Process Chain 
x Is the event sufficient to trigger the process or are there other conditions that 
must be met? 
7.7.2 Multiple Triggers 
Often a process can be triggered by several different events; Fig. 7.10 shows three 
examples modelled with different rules. As we saw with decisions, the use of 
the XOR is more common than the OR. However, it is very important to work out 
the correct logic for triggering the process. 
In the first example, Fig. 7.10a, we can see the start of an order entry process 
triggered by the customer making a telephone call or by sending a FAX. At first 
sight this seems fairly straightforward and it is modelled with an XOR. But, what 
happens if the customer telephones to place an order, but also sends a FAX con-
firmation? In that case either or both events will trigger the process. 
To handle this situation we might be tempted to replace the XOR with the OR,
but is this correct? The telephone call would always trigger the process, but if it 
is common for customers to also send a FAX confirmation, then when a FAX is 
received it would be necessary to associate the FAX with any previous telephone 
order to make sure the order was only placed once. This means the process for 
handling receipt of a FAX is slightly different from receiving a telephone call and 
needs to be modelled differently. 
We can now see that modelling triggers using an OR can be a bit awkward. 
If you do use the OR you shouldthink very carefully about what it means. In the 
example in Fig. 7.10b the triggers are Doorbell Rung OR Knock at the Door.
This means any combination of those events can trigger the process. Either event 
will trigger the process by themselves and it is pretty obvious a visitor may knock 
on the door and ring the bell at the same time and it stills triggers you to open the 
door in the same way. Well maybe you might answer it just that bit more quickly, 
but you still only open it the once.
To make valid use of the OR we have to be certain if both events occur at the 
same time they have exactly the same triggering effect as either one occurring by 
Telephone
Order
Received
XOR
Enter
Order
FAX
Order
Received
Doorbell
Rung
OR
Open the
Door
Knock at
the Door
Telephone
Order
Received
AND
Enter
Order
FAX
Confirmation
Received
(a) (b) (c)
itself. If we decide they never occur simultaneously then, provided they both have 
Fig. 7.10 Multiple Triggers 
29
7.8 Loops 121
the same triggering effect, we should use XOR. If they have different effects then 
we need more complex logic; we also have to think about what time period counts 
as being ‘simultaneous’. These different scenarios are summarised in Table 7.4.
Occurrence Effect Model with
Non-simultaneous events Each have same effect. XOR
Non-simultaneous events Each have different 
effect.
More complex logic 
required.
Simultaneous events Same effect as when 
they occur individually. 
OR
Simultaneous events Different effect from 
when they occur indi-
vidually.
More complex logic 
required.
Simultaneous events Both required to trigger. AND
The third example, Fig. 7.10c, shows triggers combined with an AND. Both 
events have to occur before the function is executed. In this example we have 
insisted the customer confirm telephone orders by FAX before we process them. 
However, we come across the problem of time periods again. If the customer 
places the telephone order, but we never receive the FAX, the process just stalls. 
In practice we might prefer to give the customer a call if we haven’t received the 
FAX by the next day. Therefore, we need to consider during what time period the 
events combined by an AND must arrive for the process to be triggered and, if not 
all the events arrive during that period, what we do instead? 
The above examples are rather contrived, but they help to make the point that 
you need to think carefully about how multiple events combine to trigger a pro-
cess. The use of a single rule may seem an easy way out of describing an awkward 
scenario, but it may cause you to gloss over vital detail that should be modelled in 
a more complete way. 
7.8 Loops 
To cope with more complex process flows and decisions we need to introduce the 
concept of loops. A loop returns a process to an earlier stage to re-run that part of 
the process again. Fig. 7.11 shows a slightly more complex version of our order-
handling process. The process requires a FAX confirmation to be received before 
the original telephone order can be processed. Because there might be a delay 
before the FAX is received, the process checks to see if the order is still valid, i.e. 
the price is still correct. If the order is OK, the Order Current event will link to 
the rest of the order-handling process (not shown). If the order is no longer valid, 
Table 7.4 Event-triggering Logic 
30
122 The Event-driven Process Chain 
the customer is asked if they want to re-order with 
the revised prices. If they do, the process loops 
back to the top of the process to go through the 
order and confirmation activities again. 
To link the loop into the process we have broken 
the connection between the first event and func-
tion and inserted an XOR operator to make the 
connection for the loop. You will notice it is an 
XOR and not an OR because, logically, the initial 
trigger and the loop trigger could never occur to-
gether. A new order and a re-order may arrive at 
the same time, but one would have to wait its turn. 
The process continues exactly as before with 
the customer still needing to confirm by FAX. Of
course, if the customer once again delays sending 
the FAX, the order may go out of date again and 
so we would go around the loop another time. If 
this continues to happen, we could go around the 
loop forever; that’s the problem with loops – they 
loop! So in practice we would need an escape 
route. Perhaps if the order goes out of date twice 
we would just cancel it. 
You do need to be sure when you send the 
process flow back to an earlier point, that the 
same process does repeat in exactly the same way. 
Often when process exceptions or errors occur, 
and the process loops back to an earlier point, it 
will get special attention the next time around and 
it may not be true to model it as if it were exactly 
the same as the first time. In our example, (Fig. 7.11), we have shown the Record
Order Details step being repeated. However, in practice it would not be necessary 
to re-enter the whole order again, but just to update the prices. Typically, there is 
some special processing in the loop back which then joins the main process later 
than might be first thought. It is a matter of judgement whether to draw attention 
to the detailed differences occurring after a loop back. 
7.9 Horizontal or Vertical Layout? 
The Event-driven process chain can be drawn either horizontally or vertically. As 
we have seen in Chapter 5, we can have ARIS automatically layout the model and 
one of the options we can chose is horizontal or vertical orientation. All the exam-
ples in this book are shown in vertical format as they fit the page better. Although 
some people prefer to lay out processes horizontally, so they can see the process 
flowing from left to right, experience has shown that EPCs are easier to follow in 
a vertical format. 
Telephone
Order
Received
AND 
FAX
Confirmation
Received
Record
Order
Details
Order
Recorded
Is Order
Still Valid?
Order
Current
Order
Out of
date
XOR 
Contact
Customer
Again
Customer
Wants to
Re-order
XOR
XOR 
Customer
Cancelled
Order
Fig. 7.11 Loops 
31
7.9 Horizontal or Vertical Layout? 123
Event Event
Function
Event Event
Function
Event Event
Function
Event Event
Function
Event
Function
Event Event
Function
Event
Function
Event Event
Function
Function Function
Event
Function Function
Event
Function Function
Event
Function Function
Event
Function Function
Fig. 7.12 Function, Event and Rule Combinations 
32
124 The Event-driven Process Chain 
7.10 Putting it All Together 
You may be thinking the Event-driven process chain is really rather complicated. 
However, all we have been doing is combining the three basic object types (Func-
tions, Events and Rules) together to represent various process flow scenarios. It is 
possible to combine these objects together in many different ways. Some of these 
are valid and some are invalid, as summarised in Fig. 7.12. 
Fig. 7.13 shows a more complete version of our order-handling process incorpora-
ting many of the scenarios introduced in this chapter. But don’t forget, not every-
thing can be represented as a process. Complex project planning, tasks with multiple 
options and data driven systems don’t model well as processes, either because they 
can be better represented in other ways or because they use a high degree of human 
intelligence, design and planning in their implementation. 
7.10.1 The Rules for Modellingin an EPC 
Based on the principles we have introduced in this chapter we can summarise the 
following basic rules of using the Event-driven process chain to cover modelling 
process flows: 
x Every model must have at least one start event and one end event, 
x Functions and events always alternate, 
x Functions and events only have a single incoming and outgoing connection, 
x Process paths always split and combine using rules, 
x Multiple events triggering a function combine using a rule, 
x Rules cannot follow a single event, 
x Decisions are taken by functions, 
x Functions that take decisions are always followed by rules, 
x Rules show the valid combination of paths that follow a decision, 
x Events following rules indicate the actual outcomes of decisions, 
x Rules cannot have multiple input and multiple outputs. 
These rules follow the ARIS Method, but in some cases are more prescriptive 
than those you may come across in an ARIS training course or in ARIS Help. This 
is in order to remove some of the confusion that occurs when people use rules in 
ambiguous ways. 
33
7.10 Putting it All Together 125
Telephone
Order
Received
AND 
Enter
Order
FAX
Confirmation
Received
Record
Order
Details
Order
Recorded
Start
Timer
AND 
Timer
Running
Timeout ?
No
Timeout
Timeout
XOR 
XOR 
Check
with
Customer
Customer
Cancelled
Order
XOR 
Customer
Intends to
Confirm
XOR 
Is Order
Still Valid?
Order
Current
Order
Out of
Date
Check if
Customer
Will Reorder
XOR 
XOR 
Is this
First
Timeout ?
First
Timeout
Second
Timeout
XOR 
Delete
Order
Record
XOR 
Order
Processing
Complete
XOR 
Customer
Reorders
XOR 
XOR 
Order
Previously
Cancelled
XOR 
Fig. 7.13 Putting it All Together 
34
FORMULÁRIO
Unidade:
 Gerencia Técnica 
TÍTULO:
Formulário de Controle de Processo 
Nº:
MP-040-050-010-010
FOLHA:
1/1
Informações administrativas do processo 
Nome 
Código 
Organização / Divisão / Gerência / 
Departamento (se aplicável) 
Posicionamento dentro da cadeia de 
valor (se possível) 
Objetivo do processo 
Informações de controle do processo 
Uso do processo ( ) Ativo ( ) Inoperante 
Este processo está 
associado à outra(s) 
iniciativa(s) de 
gerenciamento de 
processo?
( ) Não 
( ) ISO 9000 
( ) ISO 14000 
( ) SOX
( ) Six Sigma
( ) Custeio ABC
( ) OSHAS
( ) Implantação ERP
( ) Outro. Indicar: 
Documentação usada ( ) Geral do BPM ( ) Próprio da iniciativa de processo associada 
Critério de auditoria 
usado?
( ) Geral do BPM
( ) Próprio da iniciativa de processo associada 
Peridiocidade ......... meses
Auditorias realizadas 
Identificação:................ Auditor:................... Data:...................... 
Identificação:................ Auditor:................... Data:...................... 
Identificação:................ Auditor:................... Data:...................... 
Auditoria
Auditoria programada Identificação:................ Auditor:................... Data:...................... 
Em execução usando as 
seguintes soluções: 
( ) ERP
( ) Workflow
( ) CRM
( ) email
( ) CRM
( ) SCM
( ) Ambiente legado 
( ) Outros:.............................
Indicadores para os quais 
este processo fornece itens 
de controle
Observações
35
FORMULÁRIO
Unidade:
 Gerencia Técnica 
TÍTULO:
Requisição de Modelagem de Processo 
Nº:
MP-040-050-010-010
FOLHA:
1/1
Informações administrativas 
Projeto associado 
Organização / Divisão / Gerência / 
Departamento
Nome do processo 
Contato direto no site: nome, cargo, 
telefone, email
Líder do processo 
Informações da modelagem de processo 
Posicionamento (se 
possível) dentro da cadeia 
de valor 
Objetivo de existência do 
processo
Escopo
Propósitos primários de 
execução da modelagem 
( ) Documentar o processo atual e torná-lo claro a outros 
( ) Treinar outras pessoas 
( ) Propor melhorias
( ) Corrigir erros e incrementar qualidade
( ) Melhorar desempenho e diminuir custo 
( ) Implementar software e ferramentas de execução dos processos 
( ) Outro. Indicar: 
( ) Gargalos ( ) Redundâncias 
( ) Retrabalhos ( ) Valor não agregado 
( ) Fontes de erro ( ) Falta de integração 
( ) Desperdício ( ) Inatividade 
( ) Excesso de trabalho manual ( ) Atrasos 
( ) Não suporta novos desafios ( ) Risco financeiro 
( ) Compromete a empresa junto a 
clientes
( ) Outro risco. Indicar: 
Há falhas já percebidas na 
execução deste Processo? 
( ) Outros. Indicar: 
Tipos de modelagem a 
serem executados 
( ) Estado atual (As Is)
( ) Estado futuro (To Be)
Método de modelagem ( ) BPMN
( ) EPC
( ) Outro. Especificar e indicar fonte de consulta do método: 
( ) Atividade ( ) Competências necessárias 
( ) Etapas da atividade ( ) Sistemas em uso na atividade 
( ) Recurso ( ) Unidade organizacional relacionada 
( ) Agente – papéis funcionais ( ) Itens de controle necessários para 
compor indicadores 
( ) Informação gerada e recebida ( ) Leis, normas, regulamentos, etc, 
aplicáveis
( ) Eventos ( ) Novos conceitos, siglas, termos, etc, 
adotados no processo 
( ) Custos por atividade ( ) Desvios de processo 
Informações que deverão 
ser coletadas 
( ) Tempos da atividade ( ) Outros. Especificar: 
Observações
36
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
1/17
ESTA FOLHA ÍNDICE INDICA EM QUE REVISÃO ESTÁ CADA FOLHA NA EMISSÃO CITADA 
R.
FL.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 R.
FL.
0 1 2 3 4 5 6 7 8 9 10 11 12 13
01 X 26 
02 X 27 
03 X 28 
04 X 29 
05 X 30 
06 X 31 
07 X 32 
08 X 33 
09 X 34 
10 X 35 
11 X 36 
12 X 37 
13 X 38 
14 X 39 
15 X 40 
16 X X 41 
17 X X 42 
18 43 
19 44 
20 45 
21 46 
22 47 
23 48 
24 49 
25 50 
REV. EMIS. DATA ELAB. VERIF. AUT. DESCRIÇÃO 
00 A 29/06/07 Roquemar Lourenço 
01 F 12/07/07 Lourenço Roquemar 
 
 
 
 
 
 
 
 
 
 
TIPO DE EMISSÃO 
(A) PRELIMINAR (E) PARA COMENTÁRIOS 
(B) PARA APROVAÇÃO (F) APROVADO
(C) PARA CONHECIMENTO (X) CADASTRAMENTO INICIAL 
(D) CANCELADO 
37
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
2/17
Sumário
1 Objetivo......................................................................................................................................... 3
2 Escopo.......................................................................................................................................... 3
3 Participantes da Modelagem deste Processo .............................................................................. 3
4 Definições ..................................................................................................................................... 3
5 Referências................................................................................................................................... 4
6 Diagrama Geral do Processo....................................................................................................... 4
7 Dados finais Registrados.............................................................................................................. 5
8 Equipamentos, software e materiais de consumo ........................................................................ 5
8.1 Equipamentos e software .................................................................................................. 5
8.2 Materiais de consumo........................................................................................................ 5
9 Papéis funcionais envolvidos........................................................................................................ 5
10 Detalhamento das Instruções ....................................................................................................... 5
10.1 010 - Estabelecer detalhes de modelagem ....................................................................... 5
10.2 020 - Preparar reunião....................................................................................................... 6
10.3 030 - Realizar entrevista e criar lista de atividades ........................................................... 6
10.4 040 – Criar rascunho do modelo As Is .............................................................................. 7
10.5 050 – Gerar prévia do modelo As Is .................................................................................. 8
10.6 060 – Analisar consistência do modelo As Is .................................................................... 8
10.7 070 – Liberar modelo As Is discutido................................................................................. 9
10.8 080 – Validar processo.................................................................................................... 10
10.9 090 – Gerar modelo As Is final ........................................................................................ 10
10.10 100 – Aprovar modelo As Is pelos envolvidos................................................................. 11
10.11 110 – Criar documentos As Is complementares.............................................................. 11
10.12 120 – Criar sugestão de modelo To Be ........................................................................... 12
10.13 130 – Gerar modelo To Be .............................................................................................. 12
10.14 140 – Liberar modelo de estado futuro (To Be)............................................................... 13
10.15 150 – Criar documentos To Be complementares ............................................................ 13
10.16 160 – Aprovar modelo To Be pelos envolvidos ............................................................... 13
10.17 170 – Analisar consistência do modelo To Be................................................................. 14
10.18 180 – Publicar processo .................................................................................................. 14
11 Fluxograma................................................................................................................................. 15
38
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
3/17
1 Objetivo 
Fornecer as orientações básicas a serem seguidas quando da modelagem de processos nos serviços 
prestados pela Ícone, bem como para seus próprios procedimentos, de modo a tornar a modelagem 
desenvolvida de acordo com o ambiente de BPM do cliente ou diretrizes da internas. 
2 Escopo 
Trabalhos técnicos de modelagem de processos executados pelo escritório de processos da Ícone. 
Para o uso em clientes, deve ser observado se este processo precisará de condicionantes especiais 
com relação ao projeto e cliente em questão. 
3 Participantes da Modelagem deste Processo 
Os principais participantes da elaboração deste procedimento são os seguintes: 
Setor Participante Representante OBS
Ícone
Diretor Técnico Lourenço Costa Dono do processo 
Gerente responsável 
Diretor Comercial Ricardo Tedesco Especialista em processos 
Assessoria Roquemar Baldam Líder de processo 
Gerente de projeto André Campos Gestor do processo 
Implementação de sistemas Weslly Jorge Infra-estrutura de TI 
4 Definições 
BPM
1
 (Business Process Management): Envolve a descoberta, projeto e entrega de processos de 
negócios. Adicionalmente, o BPM inclui o controle executivo, administrativo e supervisório destes 
processos.
Atividade: É um termo genérico para o trabalho que uma companhia ou organização executa via um 
processo de negócio. Pode ser atômica (pouca abrangência) ou não-atômica. Os tipos de atividades 
que fazem parte de um processo são: processos, subprocessos ou tarefas. 
Processo: É um encadeamento de atividades executadas dentro de uma companhia ou organização, 
que transformam entradas em saídas. 
Subprocesso: É um processo que está incluso em outro processo. 
 
1 Apesar de existir este mesmo acrônimo como: Business Performance Management, Business Process Modeling ou 
mesmo conforme indicaria alguns autores normalmente ingleses, que apontam o BPM como uma ferramenta e não 
uma técnica gerencial, neste Manual de Procedimento é sempre adotado o conceito tal qual a BPMI / BPMN.
39
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
4/17
Tarefa: É uma atividade atômica2 (pouca abrangência) que está incluída num processo. É usada 
quando a atividade no processo não será mais refinada em subprocessos dentro do modelo do 
processo. Geralmente executada por um único usuário final, equipamento ou sistema. 
Modelo: Uma representação (com maior ou menor grau de formalidade) abstrata da realidade (num 
dado contexto). Isto significa que não há um modelo perfeito, objetivo, indiscutível. Nenhum modelo 
corresponde exatamente à realidade; todos apenas a representam, de um modo que parecerá mais 
adequado ou menos adequado, de acordo com o contexto, os atores e as finalidades da modelagem. 
5 Referências 
Leitura Obrigatória: 
BPMN. Business Process Modeling Notation Specification. Needram: Business Process 
Management Initiative, 2006. 308 p. Clique aqui para baixar arquivo.
ROSEMANN, Michael. Potential pitfalls of process modeling: part A. In: Business Process 
Management Journal. Vol. 12 No. 2, p. 249-254. 2006. Clique aqui para baixar arquivo.
ROSEMANN, Michael. Potential pitfalls of process modeling: part B. In: Business Process 
Management Journal. Vol. 12 No. 3, p. 377-384. 2006. Clique aqui para baixar arquivo.
Leitura opcional: 
BALDAM, Roquemar; et al. Gerenciamento de Processos de Negócios. São Paulo; Editora Érica, 
2007.
6 Diagrama Geral do Processo 
Fornecedores Insumos (Entradas) Processo Produtos (Saídas) Cliente 
Escritório BPM - Requisição de 
Modelagem
- Dados existentes do 
processo
Modelar Processo - Modelo de estado 
atual (As Is) 
- Modelo de estado 
futuro (To Be) 
Área requisitante 
 
2 Apesar de “atômica” ser a tradução direta, pode ser entendido como “elementar”, menor porção.
40
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
5/17
7 Dados finais Registrados 
Dado / Documento Forma de armazenamento dos documentos e dados 
Requisição de Modelagem do Processo No ambiente GED de gerenciamento do BPM 
Modelo do estado atual x Versão original e documentos eletrônicos de apoio: 
Ambiente GED 
x Versão HTML e PDF: Intranet controlada pelo escritório de 
BPM
Modelo do estado futuro Idemao Modelo de estado atual 
8 Equipamentos, software e materiais de consumo 
8.1 Equipamentos e software 
Mesa corrida com três metros, parede para fixar os modelos, computador com software de 
modelagem, máquina fotográfica com resolução superior a 3.2 megapixel (para os rascunhos em 
grande formato), escâner formato A4 ( para documentos de apoio). 
8.2 Materiais de consumo 
Blocos de adesivos, fita adesiva, régua de 50 cm, lápis, borracha, folhas de papel sulfite (A0, A1). 
9 Papéis funcionais envolvidos 
Papel funcional Competências requeridas 
Gerente de BPM - Capacitação geral de Gerência de BPM 
Líder de Processo - Capacitação geral de Líder de Processo 
Entrevistados - Micro treinamento de modelagem de processos 
- Conhecimento de execução do processo a ser modelado 
Consultor de processos Sênior - Capacitação geral de Líder de Processo 
- Mínimo de três anos de experiência em modelagem de processos 
Envolvidos - Não são exigidos pré-requisitos específicos 
10 Detalhamento das Instruções 
10.1 010 - Estabelecer detalhes de modelagem 
10.1.1 Etapas 
1. Estabelecer junto à direção do projeto e à parte interessada em que a modelagem está envolvida, 
os seguintes itens: 
x Definição clara do propósito do modelo; 
x Escopo do modelo; 
x Dados desejados de serem obtidos no modelo; 
x Indicadores de desempenho ao qual este modelo deverá fornecer os itens de controle; 
x Técnica de modelagem que deverá ser usada (BPMN, EPC, outra); 
2. Selecionar o Líder de Processo mais adequado para esta modelagem em particular. 
3. Complementar requisição de modelagem de processo, conforme Clique aqui para baixar arquivo.
41
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
6/17
10.1.2 Dados complementares 
Papéis envolvidos Gerente de BPM 
Novas Entradas Requisição de modelagem incompleta. 
Novas Saídas Não há. 
Evento resultante / 
resultado esperado 
Requisição de modelagem atualizada. 
Desvio e Atitudes Não há. 
Tempos Execução: 2 horas. 
Espera: 2 dias 
Custos de execução da 
tarefa
Material: não há 
Serviço: R$ 220,00 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Data e hora de início do processo. 
10.2 020 - Preparar reunião 
10.2.1 Etapas 
1. Estabelecer quem fará parte da equipe envolvida nesta modelagem: dono do processo, gestor do 
processo, gerentes de departamento, especialistas no tema, equipe de Tecnologia da 
Informação.
2. Agendar as reuniões necessárias para executar o processo como um todo em função do 
tamanho do modelo. Inclui: 
x Verificar quais participantes participarão de cada uma delas e seu de acordo com as datas 
propostas;
x Verificar espaço disponível para as datas selecionadas; 
x Fazer reserva de espaço e equipamentos necessários. 
3. Comunicar aos envolvidos. 
4. Coletar e ler modelos anteriores, leis, normas e outros materiais de apoio à entrevista e que 
servirão de base à modelagem. 
5. Conhecer, se for o caso de processo existente, os recursos que hoje executam este processo 
(equipamentos, softwares, instalações, pessoas). 
6. No caso dos envolvidos se disporem a fazer um pré-modelo, poderão fazer da forma que eles 
considerarem mais adequada: desenho a mão livre, usando Word, Power Point, etc. 
10.2.2 Dados complementares 
Papéis envolvidos Líder de processo 
Novas Entradas Modelos anteriores, leis, normas, etc, de apoio à entrevista 
Novas Saídas Não há. 
Evento resultante / 
resultado esperado 
Reuniões agendadas. 
Desvio e Atitudes Não há. 
Tempos Execução: 2 horas. 
Espera: 2 dias 
Custos de execução da 
tarefa
Material: não há 
Serviço: R$ 220,00 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há. 
10.3 030 - Realizar entrevista e criar lista de atividades 
10.3.1 Etapas 
1. No início da reunião: 
x Indicar/ alinhar objetivos da modelagem; 
42
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
7/17
x Indicar/ alinhar tipos de dados que deverão ser coletados para atingir propósitos pré-
estabelecidos.
2. Realizar a entrevista com observações das atividades executadas. 
3. Criar as listas de atividades em blocos adesivos, em conjunto com os entrevistados, para compor 
os modelos na próxima atividade.
10.3.2 Dados complementares 
Papéis envolvidos Líder de processo 
Entrevistados
Novas Entradas Não há. 
Novas Saídas Entrevista do funcionamento do processo. 
Evento resultante / 
resultado esperado 
Entrevista do funcionamento do processo realizada. 
Desvio e Atitudes - Entrevistados não conhecem o método de modelagem usado: usar 
uma palestra de no máximo 45 minutos para explicitar o método. 
Tempos Execução: variável. 
Espera: variável. 
Custos de execução da 
tarefa
Material: R$ 20,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há. 
10.4 040 – Criar rascunho do modelo As Is
10.4.1 Etapas 
1. Criar o rascunho do modelo As Is, observando: 
x Sempre criar o rascunho em modelo de papel de grande formato; 
x Começar o rascunho com o cabeçalho, indicando ao menos: nome do processo, data e 
envolvidos na entrevista; 
x Usar a técnica de modelagem selecionada (BPMN, EPC, outra); 
x Usar blocos adesivos, lápis e borracha para executá-los de modo a ter um modelo fácil de 
corrigir e de alta interatividade com os interessados; 
x Nunca se abster de fazer as alterações indicadas pelos usuários; 
x Deixar clara a participação dos envolvidos na criação e modelos e envolvê-los sempre 
durante a criação; 
x Não criar sob nenhum aspecto na presença dos participantes rascunhos próprios para 
compreensão do processo. Isso tem tendência de induzir o raciocínio dos demais. 
2. Apresentar aos entrevistados rascunho para validá-lo. 
3. Fotografar o modelo em resolução superior a 3.2 megapixels e armazenar no repositório do 
projeto.
Figura 1. Exemplo de rascunho de processo feito com blocos adesivos em grandes formatos. 
43
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
8/17
4. Digitalizar, se for o caso, os materiais complementares para compreensão ou suporte ao modelo: 
leis, formulários, normas, referências, etc. 
10.4.2 Dados complementares 
Papéis envolvidos Líder de processo 
Entrevistados
Novas Entradas Não há 
Novas Saídas Rascunho do modelo As Is, contendo: 
x Modelo em papel de grande formato; 
x Imagem (fotografias) do rascunho em JPG; 
x Arquivos referências de suporte ao modelo. 
Evento resultante / 
resultado esperado 
Rascunho do modelo As Is realizado 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 30,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.5 050 – Gerar prévia do modelo As Is
10.5.1 Etapas 
1. Gerar prévia do modelo usando o software indicado: 
x Modelos em Aris: executar no próprio ARIS; 
x Modelos em Visio: executar no próprio Visio; 
x Modelos em outros softwares: o padrão é executar modelo preliminar em Visio. 
2. Em primeiro plano e para compreensão facilitada, o modelo deve ser feito em folha única, 
evitando modelo distribuído em várias folhas que dificultam muito a visualização por pessoas não 
habituadas com processos. 
3. Para modelos em Visio, usar formas disponíveis em http://146.64.95.4/bpm/bpm_visio.zip
4. Armazenar modelo no GED. No caso do ARIS, guardar um arquivo de impressão no GED, 
deixando o modelo original no banco de dados. 
10.5.2 Dadoscomplementares 
Papéis envolvidos Líder de processo 
Novas Entradas Não há 
Novas Saídas Prévia do modelo As Is
Evento resultante / 
resultado esperado 
Prévia do modelo As Is realizado 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 30,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.6 060 – Analisar consistência do modelo As Is
10.6.1 Etapas 
1. Fazer, sobre o arquivo eletrônico, checagem geral do modelo para verificar possíveis: 
44
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
9/17
x Erros grosseiros; 
x Acertos gráficos; 
x Possibilidades de integração; 
x Qualidade do modelo; 
x Outras sugestões. 
2. Alterar motivo de emissão do documento 
3. Salvar versão alterada do modelo. 
10.6.2 Dados complementares 
Papéis envolvidos Consultor de processo Sênior 
Novas Entradas Não há 
Novas Saídas Não há 
Evento resultante / 
resultado esperado 
Prévia do modelo As Is revisado pelo Consultor de Processos Sênior 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: não há 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.7 070 – Liberar modelo As Is discutido 
10.7.1 Etapas 
1. Normalmente se faz necessário imprimir modelo em grande formato. O formato deve ser tal que 
permita visualização plena a 1,5 metros de distância. Só não será feita em modelos muito 
elementares (5 ou menos tarefas). O Líder de Processos deverá providenciar esta impressão. 
2. Em caso de modelos maiores que formato A3, fixar o modelo na parede para facilitar visualização 
por todos os presentes. 
Figura 2. Modelos fixados em parede para discussão com envolvidos. 
3. Discutir se o modelo apresentado corresponde sem problemas ao rascunho, fazendo marcações 
no próprio modelo das alterações propostas ou novas observações. 
4. As observações devem ser marcadas no modelo e feitas as notações necessárias. 
5. Havendo mudanças pouco significativas, deve ser dado encaminhamento do modelo. Havendo 
muitas mudanças o processo retornará ao líder de processos para devidas correções. 
10.7.2 Dados complementares 
Papéis envolvidos Líder de processos e Entrevistados 
Novas Entradas Não há 
Novas Saídas Não há
45
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
10/17
Evento resultante / 
resultado esperado 
Modelo As Is liberado 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: não há 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.8 080 – Validar processo 
10.8.1 Etapas 
1. De posse do modelo, deve-se testar o mesmo, com dados e registros reais de execução, de 
modo a garantir que o modelo corresponde o melhor possível ao objeto de estudo. 
2. Registrar alterações no próprio modelo. 
3. Fazer as alterações necessárias no modelo As Is.
10.8.2 Dados complementares 
Papéis envolvidos Líder de processos e Entrevistados 
Novas Entradas Não há 
Novas Saídas Não há
Evento resultante / 
resultado esperado 
Modelo As Is final validado 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: não há 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.9 090 – Gerar modelo As Is final 
10.9.1 Etapas 
1. Fazer correções finais. 
2. Alterar motivo de emissão. 
3. Salvar documento no ambiente GED. 
4. Havendo mudanças sensíveis sugeridas, os entrevistados deverão ser mais uma vez 
consultados. Não havendo mudanças significativas, poder-se-á passar para análise dos 
envolvidos.
10.9.2 Dados complementares 
Papéis envolvidos Líder de processos 
Novas Entradas Não há 
Novas Saídas Não há
Evento resultante / 
resultado esperado 
Modelo As Is final concluído 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da Material: não há 
46
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
11/17
tarefa Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.10 100 – Aprovar modelo As Is pelos envolvidos 
10.10.1 Etapas 
1. Imprimir modelo em grande formato e fixar o modelo na parede para facilitar visualização por 
todos os presentes. Deve ser impresso em qualquer formato que permita visualização, mesmo 
que seja formatos maiores que A0. 
2. Não havendo disponibilidade de impressora de grande formato, imprima o modelo em partes no 
Visio (o mesmo possui recurso facilitado para tal) e imprima as diversas páginas necessárias. 
3. Importante garantir que realmente todos envolvidos estarão presentes. O risco é ter um modelo 
que não corresponderá às necessidades do cliente. 
4. Discutir se o modelo apresentado corresponde ao estado atual, fazendo marcações no próprio 
modelo das alterações propostas ou novas observações. 
5. As observações devem ser marcadas no modelo e feitas as anotações necessárias. 
10.10.2 Dados complementares 
Papéis envolvidos Envolvidos
Novas Entradas Não há 
Novas Saídas Não há
Evento resultante / 
resultado esperado 
Modelo As Is liberado pelos envolvidos 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 30,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.11 110 – Criar documentos As Is complementares 
10.11.1 Etapas 
1. Criar os documentos: 
x Manual de procedimento. O modelo de Manual de Procedimento encontra-se em Clique aqui 
para baixar arquivo.
x Formulários; 
x Manuais complementares; 
x Outros documentos necessários a compreensão do processo. 
2. Armazenar os documentos adicionais no GED. 
3. Imprimir cópia do documento e solicitar assinatura dos envolvidos. 
4. Digitalizar e armazenar o documento assinado. 
10.11.2 Dados complementares 
Papéis envolvidos Líder de processos 
Novas Entradas Não há 
Novas Saídas Documentos As Is complementares 
Evento resultante / 
resultado esperado 
Documentos completos do modelo As Is concluídos 
Desvio e Atitudes Não há 
47
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
12/17
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 10,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.12 120 – Criar sugestão de modelo To Be
10.12.1 Etapas 
1. Em caso de modelo existente (em uso ou adquirido por melhores práticas, benchmarking, etc), o 
mesmo deve ser apresentado aos participantes. 
2. Focar sempre: 
x Quem é o Cliente; 
x O que é o Produto Desejado do processo. 
3. Usando a técnica que for adequada ao processo em questão (Redesenho, análise, FAST, teoria 
dos Uns da reengenharia, JAD, etc), criar rascunho de modelo To Be, usando mesmas premissas 
da construção do rascunho em As Is.
10.12.2 Dados complementares 
Papéis envolvidos Líder de processos e entrevistados 
Novas Entradas Não há 
Novas Saídas Rascunho do modelo To Be
Evento resultante / 
resultadoesperado 
Modelo As Is liberado pelos envolvidos 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 10,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.13 130 – Gerar modelo To Be
10.13.1 Etapas 
1. Executar de maneira similar a “050 – Gerar prévia do modelo As Is”
10.13.2 Dados complementares 
Papéis envolvidos Líder de processos 
Novas Entradas Não há 
Novas Saídas Modelo To Be
Evento resultante / 
resultado esperado 
Modelo To Be gerado
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: Não há 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
48
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
13/17
10.14 140 – Liberar modelo de estado futuro (To Be)
10.14.1 Etapas 
1. Executar de maneira similar a “070 – Liberar modelo As Is”
10.14.2 Dados complementares 
Papéis envolvidos Líder de processos e entrevistados 
Novas Entradas Não há 
Novas Saídas Documentos To Be complementares 
Evento resultante / 
resultado esperado 
Modelo To Be liberado
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 30,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.15 150 – Criar documentos To Be complementares 
10.15.1 Etapas 
1. Executar de modo similar a “120 – Criar documentos As Is complementares” 
10.15.2 Dados complementares 
Papéis envolvidos Líder de processos 
Novas Entradas Não há 
Novas Saídas Não há 
Evento resultante / 
resultado esperado 
Documentos completos do modelo To Be concluídos 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: R$ 10,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.16 160 – Aprovar modelo To Be pelos envolvidos 
10.16.1 Etapas 
1. Executar de modo similar a “100 – Aprovar modelo As Is pelo envolvidos”
10.16.2 Dados complementares 
Papéis envolvidos Envolvidos
Novas Entradas Não há 
Novas Saídas Não há
Evento resultante / 
resultado esperado 
Modelo To Be liberado pelos envolvidos 
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
49
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
14/17
Custos de execução da 
tarefa
Material: R$ 30,00 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.17 170 – Analisar consistência do modelo To Be
10.17.1 Etapas 
1. Executar de modo similar a “060 – Analisar consistência do modelo As Is”
10.17.2 Dados complementares 
Papéis envolvidos Consultor de processo Sênior 
Novas Entradas Não há 
Novas Saídas Não há 
Evento resultante / 
resultado esperado 
Modelo To Be revisado
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: não há 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Não há 
10.18 180 – Publicar processo 
10.18.1 Etapas 
1. Checar sobre o modo de publicação do modelo na organização. 
2. Criar arquivos e links necessários. 
3. Disponibilizar os arquivos. 
10.18.2 Dados complementares 
Papéis envolvidos Líder de processo 
Novas Entradas Não há 
Novas Saídas Modelo To Be publicado 
Evento resultante / 
resultado esperado 
Modelo To Be publicado
Desvio e Atitudes Não há 
Tempos Execução: variável 
Espera: variável 
Custos de execução da 
tarefa
Material: não há 
Serviço: variável. 
Centro de Custo: CCT – Desenvolvimento e implantação 
Item de controle coletado na 
tarefa
Dia e hora de publicação do processo 
50
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
15/17
11 Fluxograma 
51
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
16/17
52
MANUAL DE PROCEDIMENTOS
Unidade:
 Gerência Técnica 
TÍTULO:
Modelar Processos 
Nº:
MP-040-050-010 – R1 
FOLHA:
17/17
53
Empresa XPTO LOGO
Unidade:
Gerência de Suprimentos 
TÍTULO:
Manual de Instrução P-23-45-020 
Montagem de Válvula
Nº:
P-23-45-020-0
FOLHA:
1/3
080 - Manual de Instruçao - modelo.DOC 
ESTA FOLHA ÍNDICE INDICA EM QUE REVISÃO ESTÁ CADA FOLHA NA EMISSÃO CITADA 
FL/R.0 1 2 3 4 5 6 7 8 9 10 11 12 13 FL/R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 
01 X 26 
02 X 27 
03 X 28 
04 X 29 
05 X 30 
06 X 31 
07 X 32 
08 X 33 
09 X 34 
10 X 35 
11 X 36 
12 X 37 
13 X 38 
14 X 39 
15 X 40 
16 X 41 
17 X 42 
18 X 43 
19 X 44 
20 X 45 
21 X 46 
22 X 47 
23 X 48 
24 X 49 
25 50 
REV. EMIS. DATA ELAB. VERIF. AUT. DESCRIÇÃO 
00 B 09/10/01 EM 
 
 
 
 
 
 
 
 
 
 
 
TIPO DE EMISSÃO
(A) PRELIMINAR (E) PARA COMENTÁRIOS 
(B) PARA APROVAÇÃO (F) APROVADO
(C) PARA CONHECIMENTO (X) CADASTRAMENTO INICIAL 
(D) CANCELADO 
54
Empresa XPTO LOGO
Unidade:
Gerência de Suprimentos 
TÍTULO:
Manual de Instrução P-23-45-020 
Montagem de Válvula
Nº:
P-23-45-020-0
FOLHA:
2/3
080 - Manual de Instruçao - modelo.DOC 
Sumário
1 Equipamentos necessários........................................................................................................... 2
2 Materiais necessários ................................................................................................................... 2
3 Etapas........................................................................................................................................... 2
4 Resultado Esperado ..................................................................................................................... 2
5 Desvio e Atitudes.......................................................................................................................... 2
6 Vista Explodida ............................................................................................................................. 2
55
Empresa XPTO LOGO
Unidade:
Gerência de Suprimentos 
TÍTULO:
Manual de Instrução P-23-45-020 
Montagem de Válvula
Nº:
P-23-45-020-0
FOLHA:
3/3
080 - Manual de Instruçao - modelo.DOC 
1 Equipamentos necessários 
Chave pneumática. 
2 Materiais necessários 
Graxa especial de vedação; desengraxante; tinta lacre; kit de parafusos; etiqueta de 
identificação.
3 Etapas 
3.1. Verificar a presença de rebarbas no corpo (47001) e tampa (47004) 
3.2. Passar pequena quantidade de graxa de montagem no diafragma da válvula (47002)
3.3. Efetuar sua montagem no corpo, sendo que o resultado da vedação irá de encontro ao 
assento de vedação do corpo 
3.4. Passar pequena quantidade de graxa no anel oring (47003)e efetuar sua colocação na 
tampa (47002)3.5. Proceder o fechamento da válvula, utilizando a tampa (47004) e o conjunto parafusos 
(47005)
3.6. Limpar a superfície da válvula com desengraxante e aplicar etiqueta de identificação 
(ET02)
3.7. Aplicar tinta lacre nos parafusos de fechamento, em toda a extensão da rosca
4 Resultado Esperado 
4.1. Após montagem deverá estar funcionando em conformidade com o procedimento de 
teste
5 Desvio e Atitudes 
5.1. Vazamentos: verificar a posição do anel de vedação 
Importante – Lançar ocorrências de desvios e atitudes em de registro apropriado 
6 Vista Explodida 
56
Processos - Treinamento
090 - Exercícios.doc 
1. Processo: Entregar material requisitado 
A Empresa XPTO deseja modelar um processo para requisição de material usado na 
empresa. 
A idéia é que qualquer funcionário possa preencher um formulário de requisições. Este 
formulário é enviado ao almoxarifado que verifica se o item está na previsão de material 
do setor. Se estiver na previsão e em estoque, envia o material ao despacho. Se estiver na 
previsão e não tiver o material, deve-se proceder a compra do material, emitindo um 
pedido de compra e enviando ao setor de compras. Não estando na previsão o pedido é 
negado. 
2. Processo: Comprar material 
Um pedido de compra é recebido do almoxarifado. 
Se a compra for menor ou igual a R$ 100,00, envia-se direto ao departamento de compras 
para efetivar a compra direta. Acima de R$ 100,00 até R$ 5.000,00, precisa-se de 
aprovação do gerente de compras. Acima de R$ 5.000,00, precisa-se de aprovação do 
superintendente. O superintendente só aprovará a compra se houver ao menos uma 
cotação de preço associada. Se não houver cotação, espera até chegar à mesma. Em 
qualquer caso, um aprovador (superintendente ou gerente de compras) pode rejeitar a 
compra. Compras rejeitadas devem ser enviadas ao escaninho de rejeitadas, com 
justificativa da rejeição. 
Passado um dia que o pedido estiver na responsabilidade do gerente de compras ou 
superintendente, um alerta deve ser enviado ao responsável pela compra (gerente ou 
superintendente respectivo) para alertá-lo que a compra precisa ser aprovada. O alerta 
deve ser repetido a cada dia até que a compra seja decidida. 
Tomada a decisão, a compra é efetuada e a ordem de compra e pedido são enviados ao 
almoxarifado, para aguardar chegada do produto. 
Uma vez o produto disponível, o mesmo é conferido e enviado ao solicitante. A nota 
Fiscal correspondente, juntamente com pedido de compra e documento de recepção do 
material são enviados ao Contas a Pagar. 
57
Processos - Treinamento
090 - Exercícios.doc 
3. Processo: Analisar currículos 
Pessoas enviam currículos o tempo todo aos departamentos de nossa empresa, 
Companhia Genérica, Inc. Esses currículos, dos vários departamentos, são passados para 
o pessoal de RH. 
Os analistas de RH olham os currículos e determinam se deverão ou não 
recomendar a contratação dessas pessoas, enviando para aprovação do gerente de RH, ou 
se rejeitam o referido currículo, armazenando os rejeitados. 
O gerente do RH vai decidir se efetivamente fará a contratação ou rejeitar o 
referido currículo. Uma mensagem a cada dois dias deve ser enviada ao gerente do RH 
caso exista algum currículo parado. 
4. Processo: Contratar novo funcionário 
Os casos contratados no processo do exercício anterior serão transferidos para 
este exercício e terão seus currículos enviados para o departamento de Benefícios e Taxas 
do RH. Aqui, eles irão determinar se toda a documentação pertinente à pessoa está na 
pasta do processo ou não. Cada candidato precisa de um Contrato de Trabalho, de uma 
Listagem de Benefícios associados ao seu cargo e de um Contrato de Confidencialidade. 
Os documentos são relacionados pelo número de CPF. Se estiver tudo ok, uma 
mensagem será enviada para o Vice-Presidente do departamento dizendo que eles 
possuem todos os documentos e encaminha para finalização da contratação. Existe uma 
pessoa especialmente treinada no RH para fechar o contrato. 
Caso a documentação completa não esteja disponível, eles aguardarão até sete 
dias. Terminado este prazo, eles irão verificar se todos os documentos estão corretos. Se 
todos os documentos não estiverem presentes depois de sete dias, o usuário deverá 
decidir se aprova o processo, mesmo faltando itens. 
Se o Analista do departamento de Benefícios e Taxas desaprovar o processo, o 
currículo ficará em uma fila de espera até que decida verificá-lo novamente. 
58
Processos - Treinamento
090 - Exercícios.doc 
5. Processo : Executar cadastro em vídeo locadora 
A empresa Movie Times deseja ajustar seu processo de cadastramento de clientes. 
Usando um sistema via internet de cadastramento de usuários, os formulários eletrônicos 
preenchidos chegam ao nosso processo. Cada solicitação possui ao menos Número de 
Solicitação, Nome, tipo (se é normal ou estudante) e número de identidade. 
Depois de verificar que todas as palavras-chave estão presentes e não existem solicitações 
em duplicidade (Se estiver duplicado, nega o pedido da duplicação), a solicitação é 
enviada para o departamento de crédito. Lá eles irão designar um código de crédito – 1, 2 
ou 3. O código 1 significa aprovação automática. Todas as solicitações com código 2 
serão aprovadas, precisando somente ter uma nota de período de experiência. As 
solicitações com código 3 serão rejeitadas. As solicitações rejeitadas são mantidas por 07 
dias e depois removidas do processo. 
O auxiliar irá telefonar para o solicitante para informá-lo de sua aprovação como membro 
e solicitar cópias dos documentos. Caso não consiga entrar em contato com o solicitante, 
eles aguardarão 3 dias, e então tentará de novo. Caso o solicitante ainda não tenha sido 
contatado, então o contato será feito pelo correio. Envia-se então o processo para 
aguardar a chegada dos documentos junto com os demais. 
As solicitações aprovadas precisam ter cópias do documento de identidade, comprovante 
de residência e em sendo estudante, a carteira de estudante. Caso contrario, eles serão 
mantidos no sistema, e verificados novamente até que tudo esteja no sistema. Se houver 
algum problema com os documentos, nova solicitação é feita ao cliente. 
Após chegar os documentos, o auxiliar fará a solicitação da carteira de sócio. 
Um ajudante do departamento de crédito faz a carteira e o auxiliar avisa o cliente que sua 
carteira está pronta. 
59
Processos - Treinamento
090 - Exercícios.doc 
6. Processo: Conferir Recebimento em Cheque 
Todos os dias, nosso sistema de COLD importa as notas fiscais emitidas para 
nosso ambiente GED. Estas notas ficam no sistema por até 30 dias e após isso, não 
chegando o cheque do pagamento, o cobrador fará o contato para checar falta de 
pagamento ou se houve algum tipo de engano. 
Assim que chegar o cheque referente a este pagamento, se o pagamento estiver ok 
com a nota, arquiva-se cheque e nota. Para saber que nota e cheque estão ok, o cheque 
deve possuir como dado o mesmo número da nota e o valor deve estar ok. Se entrar o 
cheque com diferença grande de valor em relação à nota, o processo é enviado para 
checar diferenças de valor, com sendo exceção. 
Se o cheque possuir diferença muito pequena (menos de R$ 4,00) ou tiver erros 
de preenchimento, o cheque é enviado a um verificador de exceções para checar se é 
mesmo uma exceção ou não. Este verifica se aceita ou não como exceção. Se o ocorrido 
for irrelevante, mandar arquivar e encerra-se o processo. 
Existindo cheque duplicado ou sem número de nota equivalente, o mesmo deve 
encaminhado para corrigir estes erros. 
Sendo exceção realmente, envia-se para uma pessoa que irá verificar esta exceção 
e conseguindo trata-la, encerra-se o processo. Não conseguindo, manda para o supervisor. 
Se o supervisor entender que o fato é superável, encerra-seo processo e também arquiva-
se. Não conseguindo resolver, separa este processo e trata depois como uma exceção de 
2º nível. Passado um dia sem o supervisor resolver, o verificador de exceções tem de 
avisá-lo constantemente deste atraso, ou seja, todo dia o avisa. 
Quando a exceção possui valor de compra superior a R$ 10.000,00, o cheque é 
enviado para tratamento como grandes valores e o pessoal lá vai dar tratamento adequado 
ao mesmo. 
60
Processos - Treinamento
090 - Exercícios.doc 
7. Processo: Tratar exceções em conferência de pagamento 
 Ao final do Exercício Anterior, as verificações não resolvidas foram colocadas em 
uma fila de exceções. A partir daquela fila, um documento de exceção (e-Form – 
Formulário eletrônico) deverá ser criado. Este documento deveria herdar e obter as 
palavras-chave apropriadas. A exceção deverá ser enviada para o grupo de Cobrança. A 
menos, é claro, que a exceção tenha sido gerada pelos supervisores. Todas as exceções 
geradas pelos supervisores deverão ser enviadas para a gerente do departamento de 
cobranças. 
 No grupo de cobrança, as exceções são visualizadas e o cliente é contatado por 
telefone. O grupo de cobrança, então designa um certo número de dias para aguardar 
antes de verificar a exceção novamente. Esse número pode ser mais de cinco. Depois que 
o tempo tiver terminado, ela é então enviada de novo para o grupo de cobranças. O grupo 
de cobranças irá determinar se a exceção foi esclarecida ou enviá-la para o gerente do 
departamento de cobranças. Caso tenha sido esclarecida, então deverá ser removida do 
fluxo de trabalho junto com a verificação. 
 O gerente do departamento de cobranças precisa estar habilitado para determinar 
se envia a exceção ou a dispensa. Caso a envie adiante, o documento será enviado para o 
departamento de crédito. Caso seja dispensada, a exceção e correspondente verificação 
serão removidas do fluxo de trabalho . 
 Como é óbvio, a auditoria desejará manter os olhos sobre as exceções que sejam 
dispensadas ou esclarecidas. 45 por cento de todas as exceções dispensadas ou 
esclarecidas devem ser enviadas para a fila de auditoria. 
 Finalmente, este processo inteiro não deverá levar mais do que 5 dias . Se uma 
exceção estiver no fluxo de trabalho por mais de 5 dias, uma nota deverá ser enviada ao 
gerente.
61
Processos - Treinamento
090 - Exercícios.doc 
8. Processo: Fornecer Cartão de Crédito 
1 - Proponente preenche a solicitação do cartão de crédito via Internet 
2 - Unidade de negócios confirma dados cadastrais como endereço residencial, tempo de 
residência, telefone para contato, e-mail, renda, tempo de emprego e outras informações. 
3 - Informações não conferem - nega a proposta e envia correspondência para o 
proponente 
4 - Informações conferem - segue com a análise 
5 - Unidade de negócios efetua consulta pelo CPF em órgãos externos como Serasa e 
Associação Comercial de São Paulo (ACSP) 
6 - Se constar restrições - nega a proposta e envia correspondência para o proponente 
7 - Se não constar restrições - segue com a análise 
8 - Unidade de negócios efetua consulta interna para avaliar histórico do proponente 
9 - Se constar restrições - nega a proposta e envia correspondência para o proponente 
10 - Se não constar restrições segue com a análise 
11 - O Sistema de propostas efetua o cálculo do Credit Score através de variáveis como: 
Residência ( )Própria ou ( )Alugada 
Possui veículo ( )SIM ou ( )NÃO 
Possui seguro de automóvel ( )SIM ou ( )NÃO 
Possui seguro residencial ( )SIM ou ( )NÃO 
Possui seguro de vida ( )SIM ou ( )NÃO 
Possui conta corrente ( )SIM ou ( )NÃO 
Possui investimentos ( )SIM ou ( )NÃO 
Possui empréstimos ( )SIM ou ( )NÃO 
Possui outros cartões de crédito ( )Cartão X ( )Cartão Y ( )Cartão Z 
12 - Com base nestas variáveis é determinada uma pontuação X para o proponente onde 
se for menor a proposta é negada e se for maior a proposta é aprovada. 
13- Se for negada envia correspondência para o proponente 
14- Se for aprovada o sistema de proposta faz interface com o sistema de cartões e gera o 
número da conta 
15- Proponente recebe o kit de boas vindas e recebe o cartão de crédito em seu endereço 
de correspondência. 
16- Fim do processo de iniciação ao crédito 
62
Processos - Treinamento
090 - Exercícios.doc 
9. Processo: Autorizar compras com Cartão de Crédito 
0 - Início do processo de autorizações de compras 
1 - Cliente entra no estabelecimento para efetuar a compra 
2 - Lojista passa o cartão no Ponto de venda ( POS – Point of Sale) 
3 - Sistema da loja faz interface com o sistema da empresa emissora do cartão de crédito 
4 - Sistema de autorizações da empresa emissora verifica se há limite disponível para 
autorizar a compra e também se há atraso no pagamento da fatura atual. 
5 - Se não possuir limite disponível ou se estiver em atraso atual - sistema de autorizações 
faz interface com o sistema de exceção de autorizações. 
6 - Sistema de exceção de autorizações verifica algumas variáveis de negócios para a 
tomada de decisão se aprova ou não a compra, tais como: 
Dias de atraso atual 
Valor do limite de crédito 
Pontuação do Behavior Score (BS) 
Meses desde o último aumento de limite de crédito 
Meses desde a última redução de limite de crédito 
Possui cheque sem fundo ( )SIM ( )NÃO 
Meses desde o último atraso 
7 - Com base nestas variáveis o sistema de exceção de autorizações atribui o número da 
estratégia e o número do cenário desta autorização. 
8 - Dependendo do cenário que o sistema de exceção de autorizações atribuir, nega a 
compra e o POS mostra a mensagem para o lojista que a autorização foi negada. 
9 - Se o cenário atribuído pelo sistema de exceção de autorização aprova, neste caso a 
compra é autorizada. 
10- Se possuir limite disponível ou se não estiver em atraso atual - sistema de 
autorizações autoriza a compra direto sem a necessidade de chamar o sistema de exceção 
de autorizações. 
11- Se autorização aprovada - atualiza o saldo do cartão 
12- Fim do processo de autorizações de compras 
63