Artigo IDEF0 Processos

DAS5313 Avaliao de Desempenho de Sistemas Ricardo J.
Rabelo UFSC
Modelagem de Processos
e
a Metodologia IDEF0
Prof. Ricardo J. Rabelo
UFSC Universidade Federal de Santa Catarina
DAS Departamento de Automao e Sistemas
DAS5313 Avaliao de Desempenho de Sistemas
DAS5313 Avaliao de Desempenho de Sistemas Ricardo J. Rabelo UFSC
Introduo a Processos
Modelagem de Processos
Modelos AS-IS e TO-BE
Objetivos e Dificuldades de Modelagem de
Processos
Mtodo do Questionamento
Tcnicas de Captura de Informaes
Linguagens de Modelagem
O IDEF0
Comentrios Finais
Sumrio
Qualquer medida que vise entender e
automatizar algum processo empresarial deve,
antes de mais nada, se certificar de que o
processo sobre o qual solues automatizadas
sero implantadas (por exemplo, software ou
workflow), perfeitamente conhecido, entendido
e est devidamente racionalizado.

Seno ... automatizao da baguna !
Modelagem de Processos e a Automatizao
Este o passo nmero um que empresas de
consultoria e engenheiros fazem: entender e
mapear os processos.
Mas para faz-lo essencial se
conhecer a empresa, ou seja, o jeito
que ela executa suas vrias atividades.
Mas como se conhece e se
mapeiam processos ?
1) Identificando-os,
2) Compreendendo-os,
3) Modelando-os e,
4) Documentando-os.

Depois sim torna-se
vivel e mais slida a
base para analis-los
e por fim propor
melhorias, ou seja, re-engenheir-los.

Fazer uma re-engenharia mudar os processos.
Mas o que mesmo Processo ?!
Processo uma coleo de atividades inter-
relacionadas de uma organizao qualquer que
transforma e/ou agrega valor fsico e
informacional em relao a um estado anterior,
visando gerar um determinado resultado e valor
(final ou intermedirio para o estado / processo
posterior) a partir de eventos (inputs),
considerando objetivos & metas, regras &
restries, e executada por e com recursos
(equipamentos, sistemas, know-how, pessoas,
etc.) existentes.
PROCESSOS
Um processo usualmente constitudo por
inmeros processos menores (sub-processos e
atividades) sequenciais, paralelos ou
hierarquizados, inter-relacionados, desenhados
para atingir um certo objetivo da forma mais
eficaz.

Pode ser visualizado ou tratado sob vrios nveis
de abstrao.

Pode envolver tambm outras empresas.
Relembrando ... PROCESSOS
Processo A
Processo A1 Processo A2
Processo A3
P1 P2 P3 P4 P5 P6
P7 P8 P9
Empresa B
Do ponto de vista de tipos de um processo
como um todo, Michael Porter classifica-o em
5 tipos principais:

1- Logstica Interna;
2- Operaes (ou produo);
3- Logstica Externa;
4- Vendas e Marketing;
5- Servios.
Modelar significa expressar de alguma forma
uma atividade (j existente ou em vias de ser
introduzida) para entend-la e documentar
este entendimento.

Esta documentao pode
ser textual ou representada
(modelada) atravs de
diagramas.
O QUE SIGNIFICA MODELAR PROCESSOS ?
Segundo o CBOK 2.0, modelagem de
processos significa retratar a situao atual
e descrever a viso futura dos processos
de negcio (business processes).

A ao de modelagem passa pela
representao grfica de um processo para
que possa ser melhor compreensvel para os
vrios tipos de atores necessrios.

CBOK Common Body of Knowledge (http://www.abpmp.org/)
Esta modelagem pode objetivar duas
situaes, ou mesmo ambas:

- Modelagem da Situao Atual: chamada de
modelo AS-IS. a fotografia exata (dos
processos em anlise) da empresa.
- Modelagem da Situao Proposta (ou
Futura): chamada de modelo TO-BE (ou
SHOULD-BE). Representa a viso da
melhoria pretendida.
Facilitar comunicao;
Documentar para expressar padronizaes;
Documentar para certificaes;
Facilitar o entendimento do processo, sua anlise,
medio de desempenho, proposio de melhorias, e
anlise de impactos.
Facilitar (ou viabilizar) manuteno;
Dar suporte para treinamento de pessoas sobre ele
(atual ou novo);
Documentar / Representar uma viso consolidada /
oficial da empresa;
Muito importante em uma posterior automatizao /
integrao de sistemas;
Claro fluxo de controle, de material e de dados;
Clara viso de escopo da atividade.
PARA QUE SERVE A DOCUMENTAO
E MODELAGEM DOS PROCESSOS ?
Uma adequada documentao /
modelagem deve permitir que a
atividade em questo seja descrita com
completude, corretude, clareza e sem
ambiguidades.
COMO DOCUMENTAR PROCESSOS ?
Nenhuma atividade do processo fique de fora.
Expresse exatamente como atividade feita.
Seja facilmente legvel e entendvel.
No haja diferentes interpretaes sobre como
ela funciona.
Abordagem Bottom-Up e Top-Down
As abordagens tradicionais basicamente
tomam como premissa que de alguma forma
os processos j existem, so razoavelmente
conhecidos e ento o trabalho de apenas
model-los. Ou seja, o Valor da sua cadeia
a mera expresso e consequncia lgica da
estruturao de seus processos.

Abordagem Bottom-Up

Conjunto de Processos Valor
Uma abordagem complementar e inversa a
isso toma como premissa que os processos e
suas estruturaes so dinmicos, e que sua
modelagem ser consequncia de um novo
entendimento dado pela nova viso da
empresa. Ou seja, o Valor desejado para a
empresa quem determina a lgica e
estruturao de seus processos.

Abordagem Top-Down

Valor Conjunto de Processos
Abordagem Bottom-Up e Top-Down
NO FCIL DOCUMENTAR PROCESSOS ...
Como j comentado, o atingir essa viso
integrada, coerente, completa, correta e sem
ambiguidades tem sido visto como um dos
maiores desafios das empresas atualmente:

Porque ?!
um longo e difcil caminho ...

Entender
Racionalizar
Mudar
Implantar
Avaliar
PROCESSOS

Dificuldade de compreender o escopo do
projeto, ou seja, quais processos da
empresas so afetados devero ser
envolvidos.
DIFICULDADES
S o entender e mapear todos
os processos existentes
envolvidos (o que envolve
leituras, observaes, reunies,
discusses, etc.) costuma levar
vrios meses.
DIFICULDADES
Para CADA processo (e sua decomposio), h que se
definir, tanto para o AS-IS como para o TO-BE:
O Que (What) ele exatamente e quais so seus
subprocessos, atividades, inputs & outputs fsicos e
informacionais, recursos materiais e humanos
envolvidos, e condies de execuo & habilitadores ?
Porque (Why) ele existe / feito ?
Quais so os atores (Who) que o executam ?
Em quais situaes / processos da empresa (When)
ele executado ?
Local fsico (Where) o processo executado ?
Como (How) o processo Executado e Avaliado ?
DIFICULDADES
E se se tratar de processos novos, de
mudanas, onde as (diferentes)
pessoas naturalmente - expressam
como acham que deveria funcionar, o
problema torna-se ainda maior !
DIFICULDADES
Na verdade, esta anlise uma tarefa
permanente / diria do engenheiro, pois:

- Processos esto constantemente sendo
modificados / refinados;
- Processos devem ser mudados medida
que inovaes so introduzidas.
PROCESSOS
Um processo de melhoria ou pr-
avaliao pode ser aplicado a um processo
para questionar o seu desenho.

O Mtodo do Questionamento consiste
em usar as questes O Que, Quem, Como,
Quando, Porque e Onde, sobre vrias
situaes relacionadas com o processo
(em seus vrios nveis).
MTODO DO QUESTIONAMENTO
(White, 1987)
(White, 1987)
O propsito do processo/atividade;
O lugar onde o processo/atividade ser
realizada;
A sequncia na qual o processo/atividade
feito em relao outro;
O modo como o processo/atividade feita;
A pessoa que executa o processo/atividade;
O meio usado para executar o
processo/atividade.
(White, 1987)
OBJETIVO da atividade
O Que feito ?
Porque feito ?
Que Outra coisa poderia ser feita ?
O Que tem que ser feito ?
(White, 1987)
LUGAR onde a atividade feita
Onde ela feita ?
Porque ela feita l ?
Qual Outro lugar onde ela poderia ser
feita ?
Onde ela teria que ser feita ?
(White, 1987)
SEQUNCIA na qual as atividades so
empreendidas
Quando ela feita ?
Porque ela feita ?
Quando ela poderia ser feita ?
Quando ela teria que ser feita ?
(White, 1987)
PESSOAS atravs das quais as atividades
so empreendidas
Quem ela ?
Porque ela a pessoa a fazer isto ?
Quem mais poderia fazer isto ?
Quem teria que fazer ?
(White, 1987)
MEIOS pelos quais as atividades so
executadas
Como ela feita ?
Porque ela feita desta maneira ?
Como ela poderia tambm ser feita ?
Como ela teria que ser feita ?
PROCESSOS IMPACTAM SOFTWARE
Um software, na sua lgica de programao e
funcionamento aos eventos / interaes, deve
refletir exatamente como o dado processo
funciona.

Mudou o processo Mudar o software !!!

Portanto, quanto mais completo, correto, fcil e
sem ambiguidades o processo for modelado,
mais consistente, rpido e fcil tende a ser
especificao e o desenvolvimento de software,
ou seja, a soluo de automao pretendida.
DIFICULDADES AO MODELAR OS PROCESSOS
complexidade de entendimento e modelagem;
desconhecimento dos processos e objetivos da
empresa;
seleo das devidas tcnicas de captura de
informaes sobre os processos;
tempo para anlise, modelagem, etc.;
custos associados;
alocao intensiva de recursos humanos;
seleo de um mtodo & formalismo para
modelagem.
TPICAS TCNICAS DE CAPTURA DE INFORMAO
Observao direta
Entrevista
Workshop
Videoconferncia

Essas tcnicas podem ser todas utilizadas uma ou
vrias vezes num dado e ao longo de um projeto de
modelagem de processos.
Fonte: CBOK Common Body of Knowledge (http://www.abpmp.org/)
Observao direta

Acompanhamento presencial do processo a
ser modelado. Depende da amostragem dos
eventos do dia e consome muitas horas das
pessoas.
Entrevista

Conversa presencial com certas pessoas sobre
processo a ser modelado. Depende da
experincia do entrevistador na conduo da
entrevista e posterior qualidade do relato dos
resultados.
Workshops

Reunio presencial de vrias pessoas
envolvidas com o processo. Depende da
experincia do moderador na conduo das
conversas (e conflitos) e posterior capacidade
de consolidar os resultados. Alm disso,
depende da disponibilidade de vrias pessoas
simultaneamente.
Videoconferncia

Reunio virtual de vrias pessoas envolvidas
com o processo. Depende da experincia do
moderador na conduo das conversas, de
lidar com o equipamento e posterior
capacidade de consolidar os resultados. Alm
de tambm depender da disponibilidade de
vrias pessoas simultaneamente, uma
tcnica que pode ser muito cara de ser
operacionalizada.
LINGUAGENS
DE
MODELAGEM
IDEF0 (Integration Definition for Function Modeling) -
representao grfica de processos na forma de digramas
hierarquizados, formalizando os inputs, outputs, controles e
recursos necessrios para a execuo do processo e suas
atividades.
SADT (Structured Analysis and Design Technique) linguagem
equivalente ao IDEF0, porm inicialmente criada com o objetivo
de expresso de ideias.
UML (Unified Modeling Language) modela processos atravs
de certos diagramas, mas mais voltado para processos de
software, e no empresariais. Neste contexto, pode-se
mencionar tambm o BPEL (Business Process Execution
Language), voltado para mapeamento das interaos entre
diversos servios web (web services).
BPMN (Business Process Modeling Notation) derivado do
conceito / tecnologia BPM, equivalente ao IDEF0, mas permite
expressar processos com uma riqueza de detalhes bem mais
ampla. Porm, mais complexa. Permite integrao com BPEL.
...
ALGUMAS LINGUAGENS DE MODELAGEM
SIPOC (Supplier-Input-Process-Output-Consumer) muito
usado no Six Sigma, definindo claramente o escopo de cada
Ator no processo.
EKD (Enterprise Knowledge Development) metodologia de
modelagem de uma organizao como um todo, incluindo seus
processos, objetivos, requisitos e recursos. Do ponto de vista
de expresso, semelhante ao IDEF0.
Fluxograma tcnica de modelagem atravs do uso de
smbolos de diferentes tipos de aes na definio do fluxo de
um dado processo. O EPC uma variao deste, contendo
tambm os conceitos de operadores lgicos OR, AND e XOR nas
aes relativas a decises.
Value Stream Mapping muito usado em Manufatura Enxuta,
visa expressar o ambiente fsico e o fluxo de materiais para
retratar desperdcios, produtividade e pontos de controle.
Systems Dynamics diagramas que representam as
atividades realizadas nas flechas e no nos ns a fim de
descrever a dinmica do comportamento do processo.
...
ARIS Produto comercial: conjunto de ferramentas de
modelagem, de nveis mais abstratos de negcio at a parte de
desenvolvimento de software. Do ponto de vista de expresso,
os diagramas tem um visual entre a simplicidade do IDEF0 e a
complexidade do BPMN.
VISIO - Produto comercial: ferramenta de modelagem de
processos e base de dados.
SADT
UML (Diagrama de Classes)
BPMN
SIPOC
EKD
Fluxograma
EPC
Value Stream Mapping
Systems Dynamics
ARIS
VISIO
A METODOLOGIA IDEF0
A METODOLOGIA IDEF0
A metodologia IDEF (ICAM DEFinition
methodology) utilizada como suporte
formalizao desses passos; mais
especificamente, a sua componente de
descrio funcional, a IDEF0 (Integration
Definition for Function Modeling).
A METODOLOGIA IDEF0
Esta metodologia correspondeu a uma
iniciativa da US Air Force para a criao de
ferramentas e metodologias de suporte ao
desenvolvimento de sistemas avanados de
manufatura.

O IDEF0 uma derivao de um outro
mtodo bastante reconhecido, o SADT
(Structured Analysis and Design Technique).
A METODOLOGIA IDEF0
A IDEF0 permite descrever, atravs de uma
hierarquia de diagramas, o modelo
funcional (portanto, fluxo de informaes
dos PROCESSOS !) do sistema que se
pretende analisar ou implementar.

O IDEF0 no foi concebido para modelar
aspectos temporais.
A FAMLIA IDEF
O IDEF uma famlia de mtodos para se
estruturar e analisar uma empresa.
IDEF0 (Functional Modeling Method):
mtodo para se modelar os processos
associados a decises, aes e atividades
de uma empresa ou sistema.
IDEF1 (Information Modeling Method):
mtodo para expresso de requisitos de
um sistema (modelos AS-IS e TO-BE).

A FAMLIA IDEF
IDEF1X (Data Modeling Method): mtodo
para se expressar o desenho de bases de
dados relacionais e associar semntica aos
campos.
IDEF3 (Process Description Capture
Method): mtodo para se expressar
relaes de causa-efeito entre processos.
IDEF4 (Object-Oriented Design Method):
mtodo para auxiliar no projeto de
sistemas orientados a objetos.

A FAMLIA IDEF
IDEF5 (Ontology Description Capture
Method): mtodo para auxiliar na
identificao de ontologias associadas aos
processos e informaes.
IDEF9 (Business Constraint Discovery
Method): mtodo para auxiliar na
identificao das restries associadas a
um sistema ou processo.
A METODOLOGIA IDEF0
O IDEF uma norma ISO, logo,
standard !

H ferramentas e mtodos que
se baseiam nela, e outras que mais tarde
surgiram com base no IDEF (por exemplo, Aris e
Visio).

Outros mtodos, em alguns casos, surgiram
muito a posteriori e se tornaram os padres de
facto, substituindo alguns mtodos (como o
IDEF4). Exemplo: a metodologia UML (Unified
Modeling Language).
A METODOLOGIA IDEF0
Apenas para facilitar a compreenso, muito
basicamente, cada uma das tarefas (inter-
relacionadas) de um dado diagrama
representada por uma caixa.

Nas quatro laterais de uma caixa so
identificadas todas as informaes de
entrada, as informaes / produto de sada,
os recursos disponveis para a sua realizao
e as condies para a sua ativao,
respectivamente.
A METODOLOGIA IDEF0
Entradas Sadas
Recursos
Regras
Processo
i
Ax
REGRAS DO IDEF0
Todas as informaes de Entrada para um processo
(Atividade A) devem ser colocadas esquerda do
diagrama;
Todas as informaes de Sada devem ser colocadas
direita do diagrama;
Todas as informaes sobre Recursos de um
processo devem estar no lado inferior do diagrama;
Todas as informaes sobre Condies de Controle
sobre um processo devem ser colocadas no lado
superior do diagrama;
...
Entradas Entradas Sadas Sadas
Recursos Recursos
Regras Regras
Processo
i
Ax
Processo
i
Ax
Os nomes das informaes devem ser unvocos e,
idealmente, os mesmo que os usados nos sistemas;
Toda e cada informao tem 1 (uma) seta associada;
Todo digrama deve ter o nome da ao-base do
processo e uma numerao unvoca no formato Ax
(o A faz parte da Norma, significando Activity);
As numeraes (identificaes) devem iniciar por A0,
que representa o nvel mais abstrato de descrio de
um processo;
Recursos Recursos
Regras Regras
Processo
i
Ax
Processo
i
Ax
REGRAS DO IDEF0
CONVENES IDEF0
Recursos Recursos
Regras Regras
Processo
i
Ax
Processo
i
Ax
CONVENES IDEF0
A identificao do nome do processo usualmente
expressa na forma de uma ao, de um verbo. Por
exemplo, ao invs de se chamar um processo de
usinagem de peas, usar-se-ia usinar peas.
No caso de ser uma empresa internacionalizada ou
multinacional, os nomes costumam ser expressos
em ingls ou na lngua na matriz.
Recursos Recursos
Regras Regras
Processo
i
Ax
Processo
i
Ax
CONVENES IDEF0
No se recomenda mais do que 5 nveis de
exploso.
No se recomenda mais do que 3 ou 4
diagramas por nvel de exploso, com uma
numerao seqencial.

Mais do que isso acha-se que a pessoa no tem
uma viso devidamente clara dos processos e
ao mesmo tempo poder de abstrao. Cada
nvel deve ser auto-contido, ou seja, uma
pessoa deve ser capaz de entender o processo
bastando olhar um dos nveis. No caso de
desejar obter mais detalhes, ento deve
consultar o nvel abaixo.
CONVENES IDEF0
A0
A1
A11
A111
A1111
A2 A3
A12 A13
A112 A113
A1112 A1113 A1114
5
3 ou 4
CONVENES IDEF0
A1 A2
Questes de Pesquisa:
A3
X
CONVENES IDEF0
A1
A2
Questes de Pesquisa:
A3
EXEMPLO DE DIAGRAMA IDEF0
Tornear
Famlia Peas X
pea em
bruto
pea X torneada
torno Y
A
21
ordem de
manufatura
relatrio de
inspeo
ferramentas programa
CNC
EXEMPLO DE MODELAGEM COM IDEF0
EXEMPLO COMPLETO DE IDEF0
GANHOS COM IDEF0
Uma modelagem atravs do IDEF0 (ou de algum outro
padro) propicia:
Rigor (formal) e Preciso;
Facilidade do mtodo;
Abstrao;
Flexibilidade de introduzir mudanas;
Clareza e Conciso na descrio;
Rpida e Correta compreenso (por quem o conhece );
Economia de tempo e recursos quando de manutenes /
(cada vez mais freqentes) novas mudanas;
Clara identificao das responsabilidades e fronteiras de
cada processo.
OUTRAS REGRAS DA NORMA
No existe NENHUM outro smbolo que
possa ser usado a no ser o diagrama e
as setas.

possvel casos de retro-alimentao e
paralelismo de processos.
Nem todo output tem que ser necessariamente
o input do processo/diagrama imediatamente
a seguir ou mesmo de algum dos processos
daquele nvel. No nada anormal que inputs
de um dado processo possam vir de outros
nveis/processos fora do escopo do A0 em
questo, e que outputs de um dado processo
possam ser inputs de outros fora do escopo do
A0.

No entanto, quando isso ocorrer, a informao
em questo vir com um parnteses associado.
H casos muito especficos onde mesmo com
toda a clareza e preciso do diagrama o
engenheiro pode achar que h algum risco
de dvida de interpretao ou mesmo que
deseja enfatizar algo. Para isso, no diagrama
da Norma existe um campo Observao,
onde ento se pode escrever algo.
Como regra geral, para fins de manuteno
da consistncia entre os vrios nveis de uma
modelagem, todas Entradas, Controles,
Recursos e Sadas que aparecem nos
diagramas de nvel inferior devem aparecer
tambm no nvel superior.

Porm, se as sadas de alguns processos
foram produzidas apenas internamente, elas
no devero aparecer no nvel acima.
DVIDAS FREQUENTES ...
O que difere uma Entrada de um Controle ?

Pode uma Entrada ser Controle ?

Pode um Controle ser Entrada ?

Um Recurso no uma Entrada ?
Entradas refletem materiais e/ou informaes que
sero transformadas no processo resultando
nalguma sada em funo disso. H casos onde um
processo no tem Entrada alguma, o que significa
que no haver transformao no processo, mas
sim apenas uso de Recursos como preparao para
alguma posterior atividade de transformao.

Um Recurso um bem fsico, frequentemente
esttico, que usado para realizar a transformao
das Entradas em Sadas. Portanto, um Recurso no
uma Entrada.
Um Controle no material, mas simplesmente
um sinal, um evento, que sem ele ocorrer o
processo no pode iniciar, mesmo que se tenha
todas as entradas disponveis e recursos prontos.

Uma Entrada um Controle implcito, e por isso no
precisa/deve estar explicitado como tal como
Controle. Uma Entrada est tipicamente associada a
uma entidade fsica, que sem ela chegar o processo
/ atividade no tem como iniciar.
J um Controle um habilitador explcito, lgico.

H casos que um evento (Controle) pode ter uma
informao de Entrada associada. Por exemplo,
pode-se ter um processo que precisa da chegada de
uma autorizao para ser iniciado. Se esta
autorizao for tambm uma informao que
internamente ser processada / transformada,
ento ela pode ser tambm considerada como
entrada.
CONSIDERAES FINAIS
Uma modelagem de processos vista hoje
como base para o entendimento da empresa e
posterior introduo de melhorias.

, no entanto, uma tarefa usualmente longa e
custosa.

Para que a modelagem atinja a essncia dos
seus objetivos, fundamental que ela reflita o
que real ou o que ser efetivamente feito,
mesmo que a soluo final acerca de como se
acha que o processo deveria funcionar no seja
a tecnicamente (e reconhecidamente a) mais
eficiente.
CONSIDERAES FINAIS
Com os processos devidamente modelados e,
assim, com os pontos de conexo entre eles
correta e completamente identificados,
economiza-se imensamente tempo e recursos
financeiros no desenvolvimento de software.
Isso porque, em mdia, 30% do tempo gasto
com entendimento dos processos e definio
das interfaces e variveis que sero usadas na
integrao entre eles.

Uma modelagem ou metodologia de
modelagem no visa resolver problemas
culturais e prticas ultrapassadas da empresa,
mas pode ajudar a faz-las aparecer.
CONSIDERAES FINAIS
Mesmo aplicando-se uma metodologia como
esta as vezes o poder de expressividade de
quem modelou (ou mesmo devido a
intrnseca complexidade de um dado
processo) no suficiente para garantir que
uma terceira pessoa entenda com 100% de
certeza.

Por outro lado, como seria sem a aplicao de
nenhuma metodologia de modelagem &
documentao ?!

Artigo IDEF0 Processos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Artigo IDEF0 Processos

Enviado por

Direitos autorais:

Formatos disponíveis

DAS5313 Avaliao de Desempenho de Sistemas Ricardo J.

Você também pode gostar