IDEF0

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
Ricardo J. Rabelo UFSC
Sumrio
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
Modelagem de Processos e a Automatizao

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.
DAS5313 Avaliao de Desempenho de Sistemas Ricardo J. Rabelo UFSC
Mas o que mesmo Processo ?!
PROCESSOS
Processo uma coleo de atividades interrelacionadas 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.
Relembrando ... 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
P1
P2
P3
P4
P5
P6
Processo A1
Processo A2
P7
P8
P9
Processo A
Processo A3
Empresa B
Relembrando ... PROCESSOS 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.
O QUE SIGNIFICA MODELAR PROCESSOS ? 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/)
O QUE SIGNIFICA MODELAR PROCESSOS ?
Esta modelagem pode objetivar situaes, ou mesmo ambas:
duas
- 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.
PARA QUE SERVE A DOCUMENTAO E MODELAGEM DOS PROCESSOS ?

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.

COMO DOCUMENTAR PROCESSOS ?
Uma
adequada deve
documentao permitir que
/ a
modelagem
atividade em questo seja descrita com completude, corretude, clareza e sem ambiguidades.
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

Abordagem Bottom-Up e Top-Down 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

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 ?!
PROCESSOS
um longo e difcil caminho ...

Entender
Racionalizar
Mudar Implantar
Avaliar
DIFICULDADES Dificuldade de compreender o escopo do
projeto,
empresas
ou
seja,
so
quais
processos
devero
da
ser
afetados
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 !
PROCESSOS
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.
MTODO DO QUESTIONAMENTO
(White, 1987)
Um processo de melhoria ou pravaliao 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).
(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
ALGUMAS 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. ...

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
metodologia
IDEF
desses a sua
(ICAM
DEFinition
mais de
methodology) utilizada como suporte formalizao especificamente, passos; componente
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
dos
de
diagramas,
modelo
funcional (portanto, fluxo de informaes 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 (interrelacionadas) 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
Regras
Entradas
Processo
Sadas
Ax Recursos
Regras
Entradas
Processo
Sadas
REGRAS DO IDEF0
Ax Recursos
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; ...
Regras
Entradas
Processo
Sadas
REGRAS DO IDEF0
Ax Recursos
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;
Regras
Entradas
Processo
Sadas
CONVENES IDEF0
Ax Recursos
Regras
Entradas
Processo
Sadas
CONVENES IDEF0
Ax Recursos
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.
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
A2
A3
A11
A12
A13
A111
A112
A113
A1111
A1112
A1113
A1114
ou 4
Questes de Pesquisa:
CONVENES IDEF0
A1
X
A2
A3
Questes de Pesquisa:
CONVENES IDEF0
A1
A2 A3
EXEMPLO DE DIAGRAMA IDEF0
ordem de manufatura pea X torneada
pea em bruto
Tornear Famlia Peas X A 21
relatrio de inspeo programa CNC
torno Y
ferramentas
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.
OUTRAS REGRAS DA NORMA 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 ?!

IDEF0

Enviado por

Dados do documento

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

IDEF0

Enviado por

Direitos autorais:

Formatos disponíveis

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

Objetivos e Dificuldades de Modelagem de

Tcnicas de Captura de Informaes

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

Modelagem de Processos e a Automatizao

automatizar algum processo empresarial deve,

antes de mais nada, se certificar de que o

workflow), perfeitamente conhecido, entendido

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

Modelagem de Processos e a Automatizao

Mas como se conhece e se mapeiam processos ?

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

Modelagem de Processos e a Automatizao

Modelagem de Processos e a Automatizao

Mas o que mesmo Processo ?!

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

Relembrando ... PROCESSOS

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

CBOK Common Body of Knowledge (http://www.abpmp.org/)

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

O QUE SIGNIFICA MODELAR PROCESSOS ?

Esta modelagem pode objetivar situaes, ou mesmo ambas:

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

PARA QUE SERVE A DOCUMENTAO E MODELAGEM DOS PROCESSOS ?

Documentar para expressar padronizaes;

Documentar / Representar uma viso consolidada /

Muito importante em uma posterior automatizao /

Claro fluxo de controle, de material e de dados; Clara viso de escopo da atividade.

COMO DOCUMENTAR PROCESSOS ?

documentao permitir que

Conjunto de Processos Valor

Valor Conjunto de Processos

NO FCIL DOCUMENTAR PROCESSOS ...

ambiguidades tem sido visto como um dos

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

um longo e difcil caminho ...

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

DIFICULDADES Dificuldade de compreender o escopo do

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC

DIFICULDADES S o entender e mapear todos os processos existentes

envolvidos (o que envolve

DAS5313 Avaliao de Desempenho de Sistemas

Ricardo J. Rabelo UFSC