EA&BPM

“AQUELE QUE BUSCA O
CAMINHO DA
TRANSFORMAÇÃO PRECISA
ENXERGAR ALÉM DA
VISÃO, PRECISA ENXERGAR
A CONEXÃO ENTRE TODAS
AS COISAS”
Marcio da Costa Coelho

Arquitetura Empresarial & BPM Multidimensional
ENTERPRISE
ARCHITECTURE
&
BPM-
MULTIDIMENSIONAL
1
Capítulo 01
INTRODUÇÃO
“No contexto dos negócios, a razão existencial de todas as coisas somente pode ser
compreendida quando conhecemos sua real utilidade”
2
1. A VISÃO ORGÂNICA E ESTRUTURADA DA EMPRESA

Me agrada comparar a natureza das empresas com a
natureza humana, usando a visão do sr. Ichak Adizes, um dos ícones da
escola humanista de administração de empresas, conforme o conceito
global usado em sua obra “O ciclo de vidas das organizações - Editora
Pioneira, 1998”.
Em nossas vidas precisamos cuidar da saúde de quatro
aspectos para que possamos encontrar harmonia em nosso crescimento
e sustentabilidade existencial.
De uma forma simplificada, precisamos ter alguma visão
de futuro de vida para orientarmos nossas ações aos nossos objetivos,
sejam eles de médio ou longo prazo. Precisamos desenvolver e manter
nossos relacionamentos com os elementos de nossa “rede” social
(família, amigos, provedores, clientes, instituições, etc.), precisamos
administrar bem nossos recursos financeiros, sem os quais não podemos
subsistir em um meio capitalista, e precisamos cuidar da manutenção de
nosso corpo físico. Acima de tudo, precisamos cuidar da harmonia e do
alinhamento entre todos esses aspectos, de maneira a permitir que
nossos relacionamentos, recursos financeiros e corpo físico, estejam
alinhados entre si, e se tornem capazes de suportar a materialização de
nossas metas de vida segundo nossa visão de futuro. Um quinto aspecto
que é nosso corpo etéreo, também deve ser cuidado, porém esse é um
assunto para uma outra obra.
Da mesma forma, compreendo a natureza de uma
empresa. Existem quatro aspectos fundamentais que traduzem a saúde
de uma empresa ao longo de sua vida. Denominaremos esses aspectos
como “Domínio de Gestão”, e essa percepção é válida para negócios
com fins lucrativos ou não. Os domínios de gestão são:
 Gestão estratégica;
 Gestão de mercado & produtos;
 Gestão financeira;
 Gestão operacional.
Os quatro domínios são determinantes para saúde,
subsistência e crescimento de qualquer negócio.
3
Cada um dos domínios de gestão é passível de ser

compreendido através de meta modelos que representam os conceitos e
especificações a serem materializados na operação da empresa. Esses
meta-modelos serão mais tarde chamados de artefatos.
Nesta obra, embora reconhecida a importância dos quatro
domínios de gestão, daremos foco específico ao domínio da gestão
operacional, através da aplicação dos conceitos da Arquitetura
Empresarial e do BPM – Multidimensional.
Gestão Estratégica
A visão de futuro e a estratégia de crescimento e
sustentabilidade de uma empresa são semelhantes à nossa visão e metas
pessoais.
Mesmo não havendo um plano estratégico formal ou
estruturado, a empresa precisa definir uma linha guia de futuro para
orientar as ações que a empresa deve tomar ao longo de sua existência.
Essa linha guia deve determinar a condição que a empresa deseja
atingir (ser líder, crescer, manter-se ou até encerrar sua operação),
determinar como ela quer chegar nessa condição (mercado, produtos,
investimentos. etc.), e quando ela quer chegar nessa condição.
Assim como conheci empresas planejadas e estruturadas,
conheci também muitas empresas que não possuem uma visão formal e
estruturada sobre seu futuro, um plano estratégico ou um plano
orçamentário, e mesmo assim subsistem e até crescem. Porém observei
que em todas elas, os empreendedor ou líder tinham claro em suas
mentes onde queriam chegar com seus negócios, mesmo não tendo isso
formalizado . Porém, notei a infestação de um problema nessas
empresas: a dificuldade ou incapacidade de promover o alinhamento
4
dos demais níveis de comando com sua visão a fim de definir, planejar
e executar as ações adequadas para a evolução ou manutenção do
negócio.
Também conheci empreendedores com uma visão
indefinida e múltiplos focos quanto ao futuro, que sucumbiram seus
negócios meio a situações quase caóticas.
Usando ainda a visão orgânica, podemos notar que uma
empresa tem o mesmo ciclo de vida que tem um ser humano:
nascimento, crescimento, envelhecimento, doença e morte. A diferença
está por conta da possibilidade da realização de interversões, com as
quais podemos transformar os quatro domínios e principalmente sua
arquitetura, que é o foco desta obra. Podemos, com isso, romper com o
ciclo na fase de envelhecimento e doença, antes de sua morte e
promover o seu “rejuvenescimento”.
É possível elencar muitas causas para a morte de uma
empresa, sempre referentes aos domínios de Gestão estratégica, Gestão
de mercado & produtos, Gestão financeira e Gestão da operação. As
causas mais comuns são: sucessão conflitante de herdeiros, deterioração
do portfólio de produtos, concorrência, perda de capacidade de
sustentabilidade financeira, deficiência operacional, alteração do
cenário tributário, entre outros, o mais comum é a combinação de vários
destes fatores, já que e se afetam mutuamente.
Precisamos ter consciência que, assim como tudo no
universo, a empresa é uma entidade instável que está em constante
transformação afetada pela variação de múltiplos fatores como: cultura
e moda, concorrência, evolução tecnológica, legislação, meio ambiente,
economia, política, etc.
A visão de futuro e estratégia de sustentabilidade &
crescimento contribuem com esforço da construção de planos e ações
para o contínuo realinhamento do negócio em decorrência da variação
desses fatores.
Há uma discussão entre escolas de planejamento
estratégico que coloca em xeque o modelo de planejamento saudável
para condução de um negócio. De um lado as escolas mais tradicionais
pregam a elaboração de planos estratégicos a longo e médio prazo e seu
desdobramento em planos de ação que se tornam “bíblicos” e
5
inalteráveis, e do outro lado, escolas ortodoxas que defendem que o

planejamento absoluto a capacidade de inovação, a adaptabilidade e a
capacidade de perceber a absorver oportunidades que surgem ao longo
da linha do tempo.
Particularmente, acredito no conceito oriental do
“caminho do meio”, planejamento estratégico com “válvulas” para
ajustes ponderados a fim de não suprimir a capacidade e a cultura de
inovação e adaptação.
Existem técnicas específicas para a construção e gestão
do plano estratégico, técnicas como:
 Planejamento baseado em Visão ou Baseado em objetivos;
 Planejamento baseado em itens de interesse;
 Modelo de alinhamento;
 Planejamento de cenários;
 Planejamento Orgânico (Auto-organização);
 Planejamento em tempo real.
A adoção e aplicação destas técnicas depende de
variáveis como cultura da empresa, experiência regressa com
Planejamento estratégico, cultura organizacional e objetivos do
Planejamento estratégico. Certamente é um domínio de gestão para o
qual cabe uma obra específica.
A gestão de mercado & produto

A contínua mudança do mercado através de inovação de
produtos e serviços dos concorrentes, a alteração de perfil de demanda
dos consumidores devido a mudanças culturais ou regionais e os ciclos
da moda necessitam uma constante atenção da empresa.
É fato que essa realidade pode ser mais ou menos
agressiva dependendo do segmento de mercado que estivermos
considerando, porém ela sempre estará presente.
A perfeita definição de mercado, clientes alvo, segmento,
canais, e produtos ou serviços, é um direcionador fundamental para o
alinhamento da arquitetura empresarial no domínio de gestão
operacional.
A própria natureza do negócio depende profundamente
das definições deste domínio de gestão. De acordo com os modelos de
6
mercado e produtos/serviços serão dadas todas as variações da operação

do core business da empresa.
A compreensão da natureza do portfólio de ofertas, afeta
de forma drástica a arquitetura operacional e a configuração de todos os
seus componentes.
Por exemplo, uma empresa de uma vertical específica,
que possui produtos e serviços em seu portfólio tem uma anatomia que
difere da anatomia de uma empresa da mesma vertical que não possui
serviços.
A configuração dos produtos e serviços refletem
diretamente nos macro processos e seus componentes. Portanto,
conhecer o modelo de gestão de mercado & produtos em sua situação
corrente e sua visão de futuro é parte fundamental de qualquer plano de
transformação do domínio de gestão operacional e de sua arquitetura.
Gestão financeira
Por muito tempo no Brasil, as empresas foram geridas,
quase que exclusivamente, com foco nos recursos financeiros. Isso
ocorreu durante as décadas em que tínhamos altos índices de inflação e
altas margens de resultado, quando a preocupação principal dos
gestores financeiros era a de proteger o capital e obter maiores ganhos
no mercado financeiro ou no mercado de capitais.
Na realidade atual, em uma economia globalizada com
margens de resultado muito menores, a gestão financeira assumiu seu
justo papel de relevância como uma das componentes fundamentais da
manutenção da saúde das empresas tendo como preocupação
fundamental, no lugar da especulação financeira, os modelos de gestão
de planejamento de investimentos, planejamento de fluxos de caixa,
captação e aplicação de recursos, planejamento e controle de custos e
outras práticas que visam otimizar investimentos e despesas para
maximizar os resultados.
Esse domínio de gestão, da mesma forma que os demais
não abordados nesta obra, merecem ser alvo de uma obra específica.
Gestão da Operação
7
Este domínio de gestão será abordado ao longo desta

obra através do conceito de Enterprise Architecture (EA, Arquitetura
Empresarial, também denominada como Arquitetura Corporativa.
Essa disciplina aborda a arquitetura dos ativos físicos e intelectuais
(componentes) de uma empresa, através de meta modelos primitivos e
combinatórios que representam a operação do negócio. Ela deve estar
alinhada às definições do domínio da Gestão estratégica e da Gestão de
mercado & produtos para viabilizar a materialização dos objetivos da
empresa.
A saúde operacional de uma empresa pode ser
comparada à saúde do corpo físico do ser humano. Enquanto nós, seres
humanos, somos compostos por órgãos físicos que desempenham
funções específicas, as empresas são compostas por macro funções.
Cada vertical ou segmento de mercado possui uma “anatomia
operacional” com particularidades, pois existem macro funções
específicas necessárias para sua operação decorrentes de seu modelo de
gestão de mercado & produto.
Essas macros funções estão organizadas de forma
estruturada pelo que chamamos de Cadeia de Valor. O conceito de
Cadeia de valor (Value Chain) foi criado por Michael Porter, em 1985,
em sua obra “Vantagem competitiva: Criando e sustentando uma
performance superior”. Utilizaremos uma abordagem baseada nos
conceitos de Porter, porém aqui especializada para representar uma
“anatomia” específica de cada vertical e segmento de mercado. De
forma a criar uma visão classista que represente meta modelos de
arquitetura ou “Frameworks” reaproveitáveis para cada segmento de
mercado.
Essas cadeias de valor contêm macroprocessos, que são
seus componentes funcionais, executando subfunções de cada cadeia de
valor. Os ativos físico e intelectuais utilizados para a operação destes
macro processos, são agrupados para efeito de estudo e definição
arquitetônica, através da disciplina: Enterprise Architecture (EA) .
Nossa abordagem de Enterprise Architecture (EA) será
focada exclusivamente nos ativos operacionais (componentes) da
empresa. O framework de EA que utilizaremos como base conceitual
inclui, no domínio de arquitetura de negócio, artefatos que
8
consideraremos parte dos domínios de gestão de mercado & produto e

gestão financeira, portanto não abordados ao longo desta obra.
Uma grande parcela dos problemas que comprometem a

sustentabilidade, crescimento e maturidade de uma empresa está
associada à sua deficiência operacional.
O cenário não se torna menos complexo quando
avaliamos os fenômenos a partir do ponto de vista dos investidores. Os
fatores de transformação externa requerem constante e ininterrupto
alinhamento da arquitetura das macro funções.
Uma empresa pode revisar seus planos estratégicos e de
gestão de mercado & produto, realizar ações de saneamento da gestão
financeira e buscar referenciais de excelência através de benchmarking,
porém se não obtiver sucesso na melhoria de sua operação continuará
com sua saúde comprometida.
Tenho notado que devido à velocidade, profundidade e
complexidade da necessidade da transformação de suas arquiteturas, as
empresas tem buscado executar projetos de melhoria utilizando técnicas
como Lean–Sixsigma, programas de modernização de tecnologia de
informação, desenvolvimento de novos sistemas aplicativos
especialistas, implementação de sistemas ERP’s, automação e
orquestração de processos, projetos de gestão de performance, projetos
de GED (gestão eletrônica de documentos), programas de certificação
de qualidade, projetos de desenvolvimento organizacional e outras
iniciativas, na maioria das vezes, de forma isolada e não sincronizada,
9
sem no entanto, em muitos casos, conseguir o alinhamento de seus

domínios arquitetônicos, e sem atingir o estado de eficiência e
assertividade desejado por seus investidores ou por seus clientes.
É muito comum ainda a frustração no momento da
implementação de transformações, isso devido à desconexão entre os
domínios arquitetônicos. É neste cenário que observamos sintomas na
saúde das empresas:
 Frustração com grandes projetos de tecnologia de informação sem a
esperada melhoria sobre a operação;
 Desgaste da imagem da empresa decorrente do mal relacionamento
com o mercado (atendimento a clientes, relacionamento com
fornecedores, etc.);
 Instabilidade ou ausência do padrão de qualidade dos serviços e/ou
produtos;
 Conflito crônico entre unidades organizacionais;
 Incapacidade ou dificuldade de adaptação às mudanças;
 Existência de "feudos" de informação e dificuldade de recuperação e
consolidação da informação;
 Altos custos e tempos de processamento;
 Desconhecimento, por parte das pessoas, de seu papel na
organização;
 Quadro de pessoal aparentemente incompatível com o volume de
processamento/produção.
Esses sintomas são efeitos, que requerem uma
abordagem integral dos componentes da arquitetura operacional para
serem tradados.
Podemos comparar essa situação a de um paciente que
procura diversos especialistas, cada qual focado em um “órgão” do seu
corpo sem o conhecimento da integração inseparável de seus
componentes e do seu funcionamento.
O domínio de gestão operacional será o foco desta obra e
procuraremos demonstrar como compreendê-lo, partindo do mais alto
nível de abstração e decompondo-o até seu menor nível de
especificação. Podemos dizer que partiremos da percepção conceitual e
10
arquitetônica e chegaremos à especificação de engenharia para a

construção e implementação das transformações.
2. O CONCEITO FUNDAMENTAL – EA & BPM
Nesta obra abordaremos o domínio de gestão operacional
visando habilitar os arquitetos de negócio a gerarem modelos e
especificações suficientes para a promoção da construção,
desenvolvimento e implementação de transformações da arquitetura
empresarial. Embora não venhamos a abordar todos os quatro domínios
da arquitetura com a mesma profundidade, dedicaremos atenção
especial aos domínios de Arquitetura de negócio, arquitetura de
informação e arquitetura de aplicações.
A conexão conceitual entre EA e BPM é fundamental,
visto que o alinhamento do domínio de gestão operacional com os
domínios de gestão estratégica e de mercado & produto inicia-se com o
alinhamento do domínio de negócio para, a partir daí termos condição
de estudar e redefinir a arquitetura dos domínios de informação e de
aplicação.
Nossa abordagem será top-down e botton-up, e abordará
através da modelagem simultânea e multidimensional todos os
componentes necessários para a definição dos modelos arquitetônicos
envolvidos em uma transformação.
O BPM-Multidimensional será o “veículo” que permitirá
a concepção e manutenção da arquitetura de negócio multinível
combinada com as arquiteturas de informação e arquitetura de
aplicações.
EA – Enterprise Architecture
EA é a abreviatura, em inglês, para o termo “Enterprise
Architecture”, literalmente Arquitetura Empresarial ou Arquitetura
Corporativa.
O Conceito de Enterprise Architecture (EA) propõe uma
forma estruturada de compreender a arquitetura de um conjunto de
domínios de ativos da empresa, normalmente: pessoas, organização do
negócio, informação, sistemas aplicativos e infraestrutura de tecnologia,
e um método de administração contínua do ciclo de vida dessa
11
arquitetura, que pode ser aplicável a qualquer categoria de empresa ou

negócio.
Em contraposição às escolas organizacionais, que
procuram abordar a empresa como partes totalmente independentes, a
Arquitetura Empresarial propõe compreender a empresa como um todo,
um conjunto de componentes, ativos, totalmente interdependentes e
inter-relacionados que não podem, de forma eficaz e eficiente, ser
compreendidos, criados, transformados ou mantidos independentes uns
dos outros.
A implementação de um modelo de gestão operacional
baseado em EA pressupõe que seja adotado também um modelo de
transformação continua gerenciada, onde, partindo-se da visão da
arquitetura corrente, estabeleça-se uma arquitetura alvo e se gerencie o
processo de transformação e manutenção contínua. Efetivamente
falando, a gestão do ciclo de vida da arquitetura empresarial.
Uma breve visão da História da EA

O termo The Enterprise Architecture foi sugerido pela
primeira vez pelo Dr. Steven H. Spewak em seu livro “The Enterprise
Architecture Planning” [Spewak, 1992]. Steven H. Spewak, Ph.D., era
arquiteto-chefe da DHL Systems Inc. Em 1987 John Zachman criou o
seu framework original que fazia referência a um “framework de
arquitetura de sistema de informação”, Zachman adota o termo de
Enterprise Architecture a partir de 1996, usando a mesma estrutura de
arquitetura de sistema.
Em 1995, o “Technical Architecture Framework for
Information Management” ou TAFIM foi desenvolvido pelo
Departamento de Defesa dos EUA e foi o produto dos anos de pesquisa
do DoD (Department of Defense) dos EUA. No mesmo ano, o TAFIM
foi cedido ao The Open Group, um consórcio neutro de fornecedores de
tecnologia, para ser utilizado como base para o desenvolvimento do
TOGAF – The Open Group Architecture Framework. O TOGAF tem
lançamento sucessivas versões atualizadas.
Em 1996, o Governo Federal dos EUA iniciou um
Esforço de Enterprise Architecture, o ato legislativo “Clinger-Cohen”
12
estabeleceu que cada Agência e Departamento Federal teria a

responsabilidade de estabelecer e manter seus programas de Enterprise
Architecture (EA).
Em abril de 1998, o Conselho Federal de CIO’s - Chief
Information Officers do Governo dos EUA foi incumbido de
desenvolver o Framework Federal de Enterprise Architecture, a fim de
promover um único desenvolvimento para processos federais comuns e
interoperabilidade e compartilhamento de informações entre as agências
do Governo Federal e outras entidades governamentais. Foi gerado o
Guia Prático para Arquitetura Empresarial Federal (um guia “end to
end” para iniciar, implementar e manter um programa de EA).
Hoje existem alguns Frameworks utilizados para EA
além do TOGAF, tais como: FEAF (Federal Enterprise Architecture
Framework), GERAM (Generalized Enterprise Reference Architecture
Method), ZACHMAN Framework, DoDAF (Department of Defense
Architecture Framework), entre outros.
O TOGAF
TOGAFtm - The Open Group Architecture Framework

é um padrão criado e mantido pelo The Open Group tm, que pode ser
acessado através do enderenço web: www.opengroup.org/.
O TOGAF pode ser definido como um modelo de
abordagem completo baseado em um método de alto nível, aberto e
13
crescente, para a compreensão, definição e melhoria contínua da

Arquitetura Empresarial.
O modelo de domínios da arquitetura empresarial,
segundo a visão TOGAF, contempla quatro arquiteturas
interdependentes: Arquitetura de Negócio, Arquitetura de Informação,
Arquitetura de Aplicações e Arquitetura de Infraestrutura tecnológica,
além de um método de administração do ciclo de vida da arquitetura
(ADM – Architecture Development Method) que contempla nove fases
interdependentes de desenvolvimento e administração da transformação
da arquitetura.
BPM - Business Process Modeling

Antes de definirmos o que é o BPM, precisamos definir o
que é o conceito de Processo no contexto operacional. Processo pode
ser definido como um conjunto de atividades ou unidades de ação
interdependentes, ordenadas no tempo e no espaço, que envolvem
recursos físicos e conhecimento para processar matéria e/ou
informação, com o objetivo de produzir algo de valor agregado para um
“cliente”.
BPM, que é a abreviatura em inglês para o termo
“Business Process Management”, literalmente Gestão de Processo de
Negócios, refere-se a uma disciplina, um conjunto de conceitos e
técnicas para a construção, especificação, análise e monitoramento de
performance e melhoria contínua da arquitetura de processos de negócio
dentro do contexto de uma organização. O objetivo fundamental do
BPM é conhecer a arquitetura (modelo) dos processos de negócio a fim
de melhorar seus níveis de eficiência, eficácia, segurança, controle e
observância de regulamentação (compliance).
A mesma sigla BPM é, também, utilizada para fazer
referência ao tema Business Process Modeling - Modelagem de
Processos de Negócio, técnicas de modelagem e especificação de
processos de negócio.
A gestão de processos de negócios também é conhecida
como: BPR - Business process reengineering, BPA – Business process
analysys, Business process change management, BPI – Business
14
process improvement, BPO – Business process optimization, BPE -

Business process engineering.
Técnicas diferentes como Lean e SixSigma, entre outras,
embora não sejam abordagens de BPM, também sugerem formas de
melhoria de processos e recomendam a aplicação do BPM para
produzirem resultados estruturados sobre a arquitetura dos processos.
Cenário atual do BPM
 Gartner Group
 EM 2015 Gartner anuncia : Os gastos mundiais em software de
gerenciamento de processos de negócios (BPM) devem crescer e chegar a
US $ 2,7 bilhões nos proximos anos. À medida que as organizações estão
iniciando sua transformação digital - repensando seus modelos e processos
de negócios.
 Gartner Business Process Management Summit em Sydney- 2018, o diretor
de pesquisa da Gartner, Rob Dunie, anuncia que gerenciar os processos de
negócios com eficiência é um desafio difícil para os líderes empresariais de
hoje, porque muitos dos sistemas usados são rígidos e difíceis de mudar
rapidamente .
 Intelligent Business Process Management: Ferramentas inteligentes de
gerenciamento de processos de negóciosusam insights acionáveis em tempo
real a partir da observação e avaliação de operações para melhorar a
orquestração e a automação de processos de negócios adaptáveis.
 BPMI (Business process management group) divisão da OMG criou
O BPMN – Business Process Modeling Notation
 OMG, WFC padronizaram técnicas de engenharia de software e
automação de processos baseadas em padrões de BPM;
 SAP, Oracle, Microsoft, entre outros, são configurados com base em
modelos de Processo de Negócio;
 Soluções de BPMS (workflow automation) e de EAI (Enterprise
Application Integration) são configuradas e implementadas com base
no modelo de processo de negócio;
 Sistemas de qualidade ISSO, entre outros, se baseiam na gestão da
qualidade e melhoria de processo de negócio;
15
 Ferramenta com BSC (balanced score card) e outros métodos de

gestão de desempenho baseiam-se na gestão de processo de negócio;
 EA Frameworks como TOGAF, ZACHMAN, CASEWASE, entre
outros, utilizam do BPM para abordar a arquitetura de negócio;
Uma breve visão da História do BPM

Técnicas referentes a modelagem e análise de processos
de negócios surgiram desde o início do século 20, como gráfico de
Gantt de Hanry Gantt (por volta de 1899), Diagrama de fluxo de
processo criado por Frank Gilbreth (1921), Diagrama de blocos
funcionais e Diagrama de Rede PERT criado pelo Navy’s Special
Projects Office - EUA (década de 1950), diagrama de fluxo de controle.
Entre os métodos modernos estão o DFD e IDEF0/3 de Douglas T .
Ross (década de 1960); EPC – Event Drived Process Chain criado Prof.
Wilhelm-August Scheer (início anos 1990); BPMN - Business Process
Modeling Notation criado pelo BPMI (2004) que hoje é administrado
em conjunto com a técnica UML – Unified Modeling Language da
OMG – Object Management Group, entre outros.
Ainda assim, estes representam apenas uma fração das
técnicas utilizadas ao longo dos anos para documentar processos de
negócios. O termo “modelagem de processos de negócios” em si foi
cunhado na década de 1960 na área de engenharia de sistemas por S.
Williams em seu artigo de 1967 - “Modelagem de Processos de
negócios Melhora o controle administrativo”.
Uma das pessoas mais eminentes na história da melhoria
de processos foi Adam Smith que viveu no século 18. Em 1776
inspirado por um artigo da Enciclopédia de Diderot, Smith reconheceu
pela primeira vez como a produção e um “pino” poderia ser aumentada
através da aplicação da divisão do trabalho. Naquela época, em uma
sociedade onde a produção era dominada por produtos artesanais, um
homem realizava todas as atividades exigidas durante o “processo” de
produção. Smith descreveu como o trabalho foi dividido em um
conjunto de tarefas simples, que poderia ser realizada por trabalhadores
especializados. O resultado desta divisão de trabalho resultou no
16
aumento da produtividade por 24.000%, ou seja, o mesmo número de

trabalhadores produziu 240 vezes mais pinos que tinham produzido
antes da introdução da divisão do trabalho.
É interessante notar que Smith não defendia a divisão do
trabalho a qualquer preço por si só. Mas sim, que o nível adequado de
divisão de tarefas deveria ser definido através de um “design”
experimental do processo de produção.
Em contraste com a visão de Smith, que era limitado ao
mesmo domínio funcional e atividades integrantes sequenciadas no
processo de fabricação, o conceito de hoje inclui multidisciplinaridade
como uma característica importante. Seguir as suas ideias da divisão do
trabalho foi amplamente adotado, enquanto a integração de tarefas em
um processo funcional, ou Cross funcional, não foi considerado como
uma opção alternativa até muito mais tarde.
O primeiro método estruturado para documentar fluxo de
processo, o “diagrama de fluxo de processo”, foi introduzido por Frank
Gilbreth aos membros da Sociedade Americana de Engenheiros
Mecânicos (ASME), em 1921, na apresentação “Process Charts—First
Steps in Finding the One Best Way”. As ferramentas de Gilbreth
rapidamente encontraram seu caminho no círculo de engenharia
industrial. No início dos anos 1930, um engenheiro industrial, Allan H.
Mogensen ensinou as pessoas da área de negócios, o uso de algumas das
ferramentas de engenharia industrial em suas Conferências trabalho de
simplificação em Lake Placid, Nova York. Em 1947, A ASME aprovou
um conjunto de símbolos derivados do trabalho original Gilbreth como
o Padrão ASME para gráficos de processo.
Outro profissional importante na história do BPM foi
Doulgas T. Ross (1927 – 2007) que foi o responsável pela criação do
primeiro método estruturado de modelagem e análise de processos. Em
1969 ele criou o IDEF0 (Integration Definition for Function Modeling)
que foi parte da família de linguagens de modelagem IDEF no campo
da engenharia de software. A técnica IDEF foi construída sobre a
linguagem de modelagem funcional SADT - Structured Analysis and
Design Technique que foi utilizada amplamente pelo governo
americano nas décadas de 80 e 90 e ainda é amplamente aplicada em
empresas pelo mundo.
17
O mundo está estudando o assunto melhoria de processos

a 236 anos e há o que ser descoberto, experimentado e estudado. A
compreensão da interdependência dos ativos físicos e intelectuais em
um processo é ainda um assunto a ser explorado sob a ótica de
arquitetura e engenharia.
3 - O BPM – MULTIMENSIONAL
O BPM-M é uma criação do autor desta obra e é uma
abordagem do BPM orientada aos conceitos arquitetônicos da EA –
ENTERPRISE ARCHITETCTURE. É uma abordagem arquitetônica que
permite compreender e transformar, de forma segura, a combinação
multidimensional entre os domínios das arquiteturas: de negócio,
informação e infraestrutura na operação de uma empresa.
Como um caminho para a melhoria operacional de
empresas, o BPM - Multidimensional surge da evolução e combinação
das tradicionais disciplinas BPM, Engenharia de Produção e
Engenharia de Sistemas de Informação. Foram incorporados a essas
disciplinas, os conceitos metodológicos e técnicas: EA – GERAM,
Value Chain Theory (M. Porter), SADT-IDEF0/3 (Douglas T. Ross),
6M Theory (dr. Koaru Ishikawa), OOSE (Ivar Jacobson), Análise
Essencial (Palmer e McMenamim), UML (OMG), IE-Engenharia da
Informação (J. Martin).
O autor tem aplicado, desde de 1997, com sucesso, a
abordagem em empresas nacionais e multinacionais de médio e grande
porte, focando projetos de transformação operacional, implementação
de pacotes de sistemas aplicativos, projeto de sistemas especialistas,
certificação de qualidade, gestão de performance, entre outros focos.
Com isso a BPM-Multidimensional visa estabelecer uma
abordagem cartesiana para o estudo e configuração adequada do
ambiente operacional de qualquer negócio que vise produzir valor a
partir do esforço conjunto de pessoas, equipamentos e instalações.
Por sua natureza “holística” a BPM-M tem a capacidade
de unificar e sincronizar os esforços de transformação Tecnológica,
Humana, Ambiental, de Relações com Mercado e de Qualidade,
normalmente dispersos, através de um esforço único e integrado,
18
reduzindo atritos, desgastes, investimentos e prazos elevados quando

comparados com as abordagens tradicionais isoladas.
Através da EA & BPM-M compreenderemos a empresa
como um sistema que age e reage a estímulos de entidades do ambiente
externo, produzindo bens, serviços ou informações que agregam valor.
Desta forma, compreendemos a razão existencial de
todos os ativos (componentes) operacionais da empresa como
elementos necessários para habilitá-la a produzir essas respostas. Estes
ativos são combinados e ordenados de forma estruturada na arquitetura
dos processos de negócio para atingir o objetivo do negócio.
“Uma empresa é um conjunto de ações e respostas

estruturadas, estimuladas por relacionamentos de mercado, que visam
transformar informação e matéria, com base em regras de negócio,
utilizando, de forma combinada, recursos humanos, tecnológicos e de
meio-ambiente.”
Os ativos ou componentes são as dimensões, como as

chamaremos, que se combinam através de atividades em um modelo
ordenado no tempo e no espaço para produzir valor de acordo com a
natureza do negócio.
Tecendo uma comparação com a engenharia operacional
de produção ou manufatura, podemos observar a correlação entre suas
19
sete dimensões. Essa comparação torna clara a inseparabilidade das

dimensões, pois qualquer alteração de configuração de uma delas, pode
refletir na necessidade de reconfiguração e ajustes das demais.
A Missão do BPM – Multidimensional é suportar

compreensão e transformação dessa arquitetura operacional
multidimensional e garantir seu contínuo realinhamento em decorrência
das forças de mudança, provendo: Eficiência, Escalabilidade e
portabilidade, Assertividade, Flexibilidade, Segurança & redução de
riscos, Controlabilidade, Repetitividade.
BPM-M & EA
Utilizando a teoria dos conjuntos, podemos considerar
que o BPM-M está contido na metodologia EA. O BPM-M, conforme
referenciado pelo TOGAF 9.1tm, suporta a geração de modelos do
domínio da arquitetura de negócio.
Os benefícios da aplicação do BPM-M acoplado à EA,
além da própria transformação dos processos de negócio, podem ser
resumidos como:
● Suporte à definição da arquitetura de negócio de alto nível;

● Suporte à análise multidimensional de problemas operacionais;
● Suporte à definição de BBs (bulding blocks) orientados ao negócio;
● Suporte ao alinhamento da gestão operacional à gestão de mercado
& produtos/serviços;
● Suporte à definição de modelos de gestão de performance;
● Suporte à transformação de estruturas organizacionais;
● Suporte à gestão de job description e capacitação operacional
contínua;
● Suporte ao projeto detalhado de sistemas aplicativos;
● Suporte à análise de aderência de pacotes de sistemas aplicativos;
● Suporte detalhado à configuração e implementação de pacotes de
sistemas aplicativos;
● Suporte à análise de distribuição física de processamento;
● Suporte à definição de requerimentos de infraestrutura de
processamento e comunicação.
20
Através do alinhamento do BPM Multidimensional com

a Arquitetura Empresarial, podemos decompor a arquitetura de negócio
até os níveis de engenharia implementacional, considerando de forma
clara e precisa, todas as interação e combinações com os demais
domínios no mesmo nível de observação.
Portanto o BPM-M é um poderoso instrumento de apoio
à Arquitetura Empresarial distinguindo-se de outras visões do BPM
focadas exclusivamente na automação & orquestração de processos, ou
ainda no aspecto de qualidade intrínseco dos processos.
As Duas Faces de Observação

Compreender o a operação de uma empresa exige a
compreensão primária das duas faces de observação e da sua
inseparabilidade funcional.
A exovisão está voltada para fora da empresa e reflete as
características e necessidade da organização no tocante a seus
relacionamentos com o mercado e mundo exterior. Compreendendo que
processo é a forma através da qual a empresa responde a estímulos
originados dos relacionamentos. Por exemplo: Seus relacionamentos
com clientes, fornecedores, investidores, competidores, órgãos
reguladores do meio ambiente, o Estado, etc.
Para a melhoria desta face da organização aplicam-se
disciplina e técnica como CRM, CI, Análise Competitiva, Pesquisas de
mercado e outros, voltados para estudar, planejar e executar ações
referentes ao mercado. Nesta face deve-se observar a empresa
interagindo com o mercado.
A segunda delas deve estar totalmente focada nos
componentes internos da empresa e pressupõe uma INTRAVISÃO da
organização, de fato sua operação. A abordagem dos ativos (dimensões)
que compõem seu ambiente operacional são o foco da preocupação e da
busca de evolução. Nesta face deve-se observar a empresa como um
organismo, um conjunto de partes inseparáveis e interdependentes.
21
A Sinergia de Esforços Apoiada pelo BPM – Multidimensional
As empresas investem em esforços para a busca de

programas de modernização de plataforma de tecnologia de informação,
certificação ISO 9000, benchmarking, CRM, CI, programas de
qualidade, desenvolvimento de sistemas aplicativos, implementação de
sistemas ERP/CRM/BI, reengenharia de processos, desenvolvimento
organizacional, outsourcing, ajuste de quadro e estrutura de pessoas e
outros esforços que envolvam a organização.
A BPM - Multidimensional tem, por natureza, a
capacidade de unificar e sincronizar esses esforços de transformação
Tecnológica, Humana, Ambiental, de Relações com Mercado e de
Qualidade, normalmente dispersos, através de um esforço único
integrado reduzindo atritos, desgastes, investimentos e prazos elevados
quando comparados com as abordagens tradicionais isoladas.
As características fundamentais da compreensão dos modelos de
negócio de repetição planejada
Para podermos compreender adequadamente a questão
de planejamento das respostas temos que considerar dois fatores
fundamentais na observação das empresas que serão alvo dos esforços
do BPM - MULTIDIMENSIONAL:
 A relação volume vs. variedade
 A relação serviço vs. matéria
A relação volume vs. variedade

Esta relação aponta para uma combinação que produz
duas situações extremas, produção de material ou serviço:
22
Quanto maior a variedade e menor o volume, mais a

operação do negócio ou produção está para um modelo artesanal, onde
o planejamento da ação tende ser cada vez mais abstrato e macro
regulador (princípios).
Quanto menor a variedade e maior o volume, mais a
operação do negócio ou produção está para um modelo repetitivo e
planejado onde a ação tende a ser especificada com uma profundidade
de detalhe crescente e estável.
A relação serviço vs. matéria

Esta relação aponta para uma combinação no tocante a
proporção da transformação de serviço e matéria ao longo da cadeia de
um negócio ou produção.
Mesmo as empresas de serviço manipulam
obrigatoriamente matéria em determinados pontos de seu negócio,
consumindo-as ou transformando-as para execução de seus serviços.
4 - OS DOMINIOS ARQUITETONICOS NO BPM-M
4.1. ARQUITETURA DE NEGÓCIO
A Dimensão Atividade
A dimensão Atividade é o componente central “espinha
dorsal" do modelo multidimensional de processo, é a dimensão sobre a
qual as demais dimensões são conectadas e derivadas, é modelada
visando a cadeia de transformação de "input" (insumo) em "output"
(produtos) em conformidade com o objetivo do processo de negócio, e
representa a resposta às Relações com o Mercado.
É através dela que as demais dimensões se justificam:
 As Classes de Pessoa.
 As Informações
 A Tecnologia de Informação
 As Regras de Negócio.
 O Meio Ambiente de Processamento.
23
Processo de Negócio (Modelo de Operação do Negócio)

“Um processo ou uma operação é um conjunto de
atividades, interdependentes e ordenadas no tempo e espaço, executadas
por um conjunto de pessoas auxiliadas por tecnologia, com base em
regras, e com o objetivo de responder a estímulos, transformando ou
manipulando informações provenientes de inputs, para a produção de
informações de valor, destinadas à satisfação das necessidades de uma
classe de clientes”.
Cuidado a tomar, não confundir modelo de processo
com:
 Arquitetura de sistema de aplicativos (software aplicativo);
 Arquitetura de Informação ou de dados;
 Modelo de estrutura organizacional;
 Modelo de organização física de ambientes;
A Dimensão “Relações com Mercado”

Como vimos anteriormente, compreendemos a empresa
como um sistema de respostas a estímulos de relações com o mercado.
Com base nos objetivos do negócio, as relações são compreendidas e
estudadas de forma nos permitir definir quais relações terão respostas
repetitivas planejadas e quais não, além de facilitar a identificação de
possíveis problemas no relacionamento com as entidades externas à
empresa e determinar a adequada ação de transformação para corrigi-la.
Para cada relação com o mercado reconhecida a empresa
deve constituir um processo específico que será arquitetado para operar
produzindo o output esperado pelo agente da relação.
Cada "output" a ser gerado pela relação é avaliado a partir dos diversos
pontos de vista envolvidos (clientes, fornecedores, governo, acionistas,
investidores, credores etc.) para determinar sua adequada configuração
a fim de satisfazer às expectativas das entidades externas. Os inputs são
configurados para que possam permitir o adequado processamento e
geração do output.
Toda a operação da empresa deve justificar-se, de forma
direta ou indireta, a partir das relações com mercado, sejam estas
reativas ou proativas, e para cada relação deve existir uma ação interna
24
planejada e ordenada a fim de produzir os outputs demandados pelo

mercado.
A Dimensão Regras de Negócio

A dimensão Regra de Negócio é a peça fundamental e
essencial para a Flexibilização das arquiteturas. Ela determina as
restrições e condições para a execução de atividades e transformação de
inputs em outputs. As regras de negócio determinam ou orientam sobre
o “COMO” executar uma atividade, seu script é separado do script da
atividade a fim de estabelecer uma componente com variáveis definidas
e passíveis de terem seus valores alterados para mudar a qualidade do
output sem com isso alterar a arquitetura das demais dimensões.
A Dimensão Recurso Humano

Como Modelo de Recursos Humanos, compreendemos
o conjunto de definições referentes às CLASSES DE PESSOAS, que
constituem o corpo físico da empresa. Tais definições são referentes a:
Definição das classes de pessoas, Qualificação das classes de pessoas,
Quantificação das posições de trabalho das classes de pessoas,
Organização do agrupamento e comando das classes de pessoas,
Determinação do modelo de distribuição física das posições de classe
de pessoas.
Na realidade, falamos sobre a derivação dos
requerimentos de recursos humanos a partir dos processos de negócio
da empresa, uma vez que estas classes de pessoas têm sua razão
existencial justificada pelos próprios processos de negócio, assim como
aquelas classes de comando e Gerenciamento que existem em função
das classes de pessoas dedicadas à operação dos negócios.
De fato, uma empresa pode ser compreendida como um
sistema produtivo organizado com base na utilidade de seus ativos
constituintes.
O BPM - Multidimensional foca estabelecer, entre as
demais dimensões, uma base para a razão existencial de cada indivíduo
da organização diferenciando aqueles que devem ter uma atuação livre
ou menos planejada baseada em sua capacidade de análise e execução,
daqueles que devem obrigatoriamente ter uma atuação planejada,
25
repetitiva e regrada, para com isso ter a primeira componente de um

sistema social produtivo ordenado.
A Dimensão Meio Ambiente

A infraestrutura de meio ambiente é projetada para
suportar a instalação dos postos de trabalho e operação, garantindo a
adequação do layout, ergonomia, iluminação etc., necessários à
operação do negócio, de acordo com o modelo de destruição de
processamento preestabelecido para cada "site" físico do negócio.
4.1. ARQUITETURA DE INFORMAÇÃO

A arquitetura de informação é modelada de forma que
sejam conhecidos e definidos os requerimentos em três dimensões.
A dimensão objetos de negócio

São as "coisas" que possuem características próprias e
sentido existencial independente e são "manipuladas" pelo negócio. Sua
criação, alteração, eliminação, associação e transformação de estado ou
condição representam o objetivo essencial da operação do negócio,
através de suas atividades.
A dimensão grupos de dados

Que são os fluxos de dados, documentos, formulários,
arquivos gerados, etc., que trafegam entre as atividades e contém uma
combinação específica de dados sobre os objetos de negócio,
necessários a cada atividade ao longo da cadeia do processo.
A dimensão Classes
Que são os “repositórios” de dados sobre os objetos de
negócio em formato adequado para representar a armazenagem pelas
ferramentas de gerenciamento de banco de dados (DBMS) ou
gerenciamento de arquivos na dimensão Tecnologia de Informação.
A dimensão Elemento de dado
26
Que são os atributos ou características de cada Objeto de

negócio. Os elementos de dados são características úteis sobre os
objetos de negócio manipuladas nas atividades através e transportadas
através do processo nos grupos de dados.
4.3-ARQUITETURA DE APLICAÇÕES
A Dimensão Sistema Aplicativos

Na arquitetura de aplicações, quando nos referimos a
desenvolvimento de aplicações para suportar a operação do negócio,
podemos decompô-la em duas classes de requerimento:
 Requerimentos Funcionais para Sistemas Aplicativos (Pacotes ou
Desenvolvimento);
 Requerimentos de Armazenagem, manipulação e recuperação de
dados/Informação;
Tais requerimentos são derivados do modelo processo de
negócio e decomponíveis, sendo cada um deles alvo de especificação
detalhada até que se obtenha um modelo completo e implementável de
Sistemas Aplicativos.
Algumas abordagem convencionais para o Projeto de
Sistemas Aplicativos é baseada nas ações do arquiteto ou analista
focadas em: relacionar fatos que parecem pertencer ao sistema,
relacionar eventos utilizando brainstorm, aplicar algoritmos para
descobrir eventos, resumir os eventos, avaliar as exceções e falhas
incomuns, abstrair os atores e seus use cases, resumir os objetos ou
ainda listas requerimento funcionais desconectados da arquitetura de
negócio.
Já a abordagem baseada na BPM – Multidimensional
utiliza a derivação dos requerimentos funcionais a partir do modelo de
processo de negócio. Cada atividade de negócio suportada por sistemas
aplicativos gera um projeto de Use Case. Os dados manipulados no Use
Case são as informações transformadas na atividade de negócio.
A lógica do código do aplicativo, distribuída entre os
objetos de controle (CO) e os objetos de interface (IO) responde, é
especificada para que o aplicativo reaja a cada interação entre o Ator e
27
o sistema produzindo a informação necessária àquele "step" da

operação do negócio.
Pacotes de Sistemas Aplicativos

O processo de implementação de pacotes de sistemas
aplicativos, sejam eles sistemas ERP ou sistemas especialistas, é
frequentemente um problema.
Sabemos que todo Pacote de Sistema aplicativo infere ou
traz consigo, em muitos casos explicitamente e em outros casos
"implicitamente" e não declarado, parte do(s) "modelo(s)" de operação
dos negócios que propõem suportar.
Muitos pacotes não conseguem ser adaptáveis o
suficiente para serem aplicados na totalidade do mercado sem com isso,
frequentemente, resultarem em problemas. Muitos projetos são levados
a cabo sem conhecimento do modelo operacional próprio da empresa.
Esta situação agrava-se quando se trata de operações
contidas no “core business”, as quais por si só podem representar um
diferencial de mercado. Isto nos leva a questionar a tradicional
declaração dos fornecedores de pacotes: “operações são iguais em todas
as empresas”.
Do ponto de vista do BPM - MULTIDIMENSIONAL os
sistemas aplicativos de apoio ao negócio são instrumentos
(mecanismos) utilizados pelos atores em cada atividade da cadeia das
operações. Sendo assim seu uso predeterminado pelo modelo de
operação do negócio é o fator determinante na definição de suas
características.
A Dimensão Tecnologia de Informação - Orquestração de

Processos (BPMS/BAM), Integração de Aplicações (EAI-AIA),
Gestão de conteúdo (ECM/GED)
4.4. ARQUITETURA DE INFRAESTRUTURA

Os requerimentos de infraestrutura tecnológica estão
completamente vinculados a forma com que a operação do negócio é
arquitetada.
28
Mudanças na arquitetura da operação do negócio podem

requerer revisão das características da arquitetura de infraestrutura
tecnológica. É por este motivo que a concepção e transformação
contínua dos requerimentos tecnológicos são derivadas da Operação do
Negócio, garantindo o seu alinhamento ao negócio. Este domínio
arquitetônico não será alvo de estudo nesta obra visto que sua
complexidade e extensão merecem uma obra específica. Componentes
Básicos:
 Requerimentos de arquitetura de processadores;

 Requerimentos de arquitetura de rede;
 Requerimentos de arquitetura de comunicação;
 Requerimentos de softwares básicos (DBMS, network, application
server, segurança, desenvolvimento, monitoramento, etc.)
5. A Certificação com base na Excelência Operacional

Por vezes encontramos empresas levando a cabo
processo de certificação ISO 9000 e outros baseados em modelos de
processos como COBIT, ITIL sem a preocupação de melhorar de fato
suas operações, visando apenas a certificação de um modelo de
repetição de processamento mesmo que este não seja o ideal e por vezes
nem o minimamente adequado.
Com a nova versão da ISO 9000, a versão 9001–2000,
ficou enfatizada a necessidade da busca da melhoria contínua no cerne
dos objetivos da ISO. Recomenda-se a análise de problemas
operacionais, a abordagem por processos e a adoção de indicadores
de desempenho como conceitos basilares para a certificação da
excelência operacional.
A Engenharia Operacional é a base inicial sobre a qual
pode-se buscar a excelência operacional e consequentemente sua
certificação segundo os critérios da nova ISO série 9000.
A seguir destacamos alguns dos itens gerados pelo BPM-
Multidimensional considerados básicos para ISO série 9000:
 Modelo de processos;
 Identificação de responsabilidades e papéis;
29
 Definição de documentação operacional;

 Definição de indicadores de performance;
 Instrumentos de monitoramento
 Instrumentos de melhoria contínua;
6. Gestão de Desempenho
A gestão de desempenho é um elemento chave ao longo
do processo de transformação. É com base em modelos de medição de
desempenho que podemos medir e controlar o estado da operação dos
processos identificando desvios, degradação e oportunidades de
transformação.
A gestão de desempenho pode partir do nível mais alto
da arquitetura de negócio e chegar até os componentes tecnológicos
operacionais embutidos nas soluções tecnológicas.
Um modelo integral deve ser perseguido pelos gestores
conectando, através de um modelo de decomposição combinatório, a
arquitetura de indicadores de alto nível à arquitetura dos indicadores
dos níveis operacionais e transacionais.
As características métricas das sete dimensões
operacionais podem ser mensuradas permitindo ao gestor do negócio o
conhecimento dos aspectos métricos relevantes do negócio.
São definidas as bases para comparação entre as
situações ou cenários obtidos no processo de otimização, bem como
bases métricas para a simulação da operação.
A aplicação dos conceitos de métricas pode ser utilizada
tanto para “medir” a situação corrente de uma operação quanto para
medir a diferença em relação a sua situação transformada.
 Indicadores volumétricos;
 Indicadores financeiros;
 Indicadores qualitativos;
 Indicadores temporais;
 Iniciadores métricos compostos.
Diversas técnicas de estatística, de custeio, de otimização
de produção e de qualidade podem ser utilizadas.
 BSC (Balanced Score Card)
30
 Six Sigma;
 ABC/ABM (Activity based cost/Activity based management)
 AVA/EVA - Análise de valor agregado ou de contribuição;
 Análise de balanceamento de carga;
 Capacity Plan;
 PERT/CPM;
 Outras.
7. A Análise de Problema como Instrumento de Melhoria

Multidimensional
O primeiro passo consiste em identificar e classificar os
problemas e correlacioná-los aos elementos operacionais e suas
instâncias.
Cada problema encontrado é analisado a fim de que se
compreenda sua real causa e efeito.
Esta análise é realizada dentro de contextos específicos
da operação do negócio, adotando-se pontos de vista diferentes para a
completa percepção dos problemas, suas causas e efeitos (executor, alta
administração, fornecedor, cliente, etc.). As ações corretivas são os
primeiros aspectos a serem considerados na otimização do modelo
operacional, e especificação das necessidades de ajustes para cada um
dos elementos operacionais
Intenso e fundamental na fase de conhecimento da
situação corrente, a qual envolve análise de problemas e captura de
conhecimento sobre a operação engenhada. Menor na fase de
engenharia da situação “ideal” (otimizada), pois é nesta fase que o
engenheiro tem maior responsabilidade sobre a concepção das soluções
cabendo ao cliente o papel de questionador e aprovador das ideias
conceitos e princípios apresentados pelo modelador.
“Nem toda mudança conduz a melhorias, porém toda
melhoria exige mudanças”
31
Capítulo 02
O PROCESSO DE TRANSFORMAÇÃO
A aplicação prática da BPM-M se dá através da execução

de um conjunto de atividades ordenadas no tempo, onde são aplicadas
técnicas para a produção de modelos, atividades estas realizadas pelo
Engenheiro Operacional com o envolvimento de classes de pessoas
específicas.
Neste capítulo apresentaremos os conceitos básicos desta
estrutura de execução de serviço a fim de orientar os “treinados” sobre
como planejar e organizar um projeto de BPM-M.
Índice do capítulo
 O ciclo de vida das organizações e momento da transformação;
 Os estágios da maturidade para a gestão por processo;
 O ciclo de transformação;
 As situações de aplicação da BPM-M;
 A transição para o estado de excelência operacional;
 A configuração de projetos;
 Envolvimento do cliente;
 O conceito CAP;
32
 As etapas de um projeto de Transformação.
1. O Ciclo de vida das organizações e momento da

transformação
É importante salientar que a transformação operacional é
o último passo a se executar em um processo maior de transformação
empresarial. Precisamos ter em mente a natureza e a grandeza dos
riscos envolvidos em projetos desta natureza. Segundo Ichak Adizes em
sua obra “O Ciclo de Vida das Organizações” as organizações têm
seu ciclo de vida evoluindo através de dez estágios: Namoro, Infância,
Toca-Toca, Adolescência, Plenitude, Estabilidade, Aristocracia,
Burocracia incipiente, Burocracia e Morte.
A abordagem pode ser utilizada em empresas em
qualquer estágio de evolução, porém, é nas empresas que se encontram
dentro do intervalo de receptibilidade, entre o estágio de adolescência e
o de burocracia incipiente, é que as chances de sucesso são maiores. As
empresas fora do intervalo exigem um esforço muito grande para a
mudança de valores e visão antes de qualquer iniciativa cartesiana
para sua transformação operacional. Isto representa maior risco de
fracasso pois a organização não está consciente da necessidade da
transformação, o que resulta em resistência maior à transformação.
O reconhecimento do estágio evolutivo no qual encontra-

se a empresa objeto da transformação é fundamental, pois de acordo
com cada estágio encontraremos diferentes riscos para o processo de
transformação. Para cada situação teremos uma abordagem preparatória
diferente a ser recomendada para a empresa.
33
A proposta da abordagem EA&BPM-M não é

transformar a estratégia da empresa, mas sim abordar de forma
estruturada e cartesiana a engenharia e implementação de qualquer
transformação empresarial operacional.
Além da identificação do estágio evolutivo da empresa,
nota-se que os projetos de transformação operacional realizados em
operações de linha (core business) em empresas cuja a estratégia do
negócio não está bem definida são deficientes, pois mudanças na
estratégia da empresa ao longo ou após a concepção da nova arquitetura
podem provocar desvalimento e resultar em ajustes de conceitos
arquitetônicos que podem retardar ou inviabilizar sua implementação.
1. Os Estágios da maturidade para a Gestão por Processos

Empresas iniciam seus esforços para a transformação do
modelo de gestão de diversas formas. O caminho adequado para a
transformação do modelo de gestão deve considerar um conjunto de
estágios através dos quais a empresa evolui em sua maturidade
organizacional até efetivamente estar gerindo sua operação com base
em seus processos e os respectivos indicadores. O Modelo BPMM –
Business Process Maturity Model propõe os seguintes estágios:
 Nível de Maturidade 1: Inicial

 Serviços e processamento são irregulares e não sistemáticos. A
arquitetura de negócio é desconhecida e suas integrações com as
arquiteturas de Informação, aplicações e infra também. A
34
operação depende exclusivamente do conhecimento e talento

das pessoas.
 Nível de Maturidade 2: Repetitivo
 Os processos mais importantes (críticos) são conhecidos; a
arquitetura de negócio é previsível e repetitiva. A operação
produz resultados definidos.
 Nível de Maturidade 3: Definido
 A arquitetura de negócio é documentada, padronizada e
integrada. Os processos estão alinhados à estratégia do negócio.
 Nível de Maturidade 4: Administrado
 Objetivos de performance são definidos, e continuamente
medidos e controlados. Os ativos físicos (TI, meio ambiente e
recursos humanos) tem suas arquiteturas configuradas e
integradas à arquitetura de negócio.
 Nível de Maturidade 5: Otimizado
 A melhoria da operação é proativa, contínua e baseada na
arquitetura empresarial. A transformação do negócio e do
mercado é monitorada e reflete em possíveis inovações e
adequações da arquitetura empresarial.
2. O Ciclo de Transformação
A transformação da arquitetura empresarial é um
processo contínuo decorrente das forças de transformação.
O Objetivo fundamental do modelo de ciclo de
transformação é estabelecer um processo através do qual a empresa
transita do estado atual de arquitetura para o estado de otimização de
arquitetura.
35
O TOGAF – ADM propõem um modelo de fases e

gestão contínua da transformação, composto pelas fases:
A. Preliminar;
B. Visão de arquitetura;
C. Arquitetura de negócio;
D. Arquitetura de sistemas de informação;
E. Arquitetura de tecnologia ( infraestrutura);
F. Oportunidades e soluções;
G. Planejamento da migração (transformação);
H. Governança da implementação;
I. Gestão da transformação da arquitetura;
O Ciclo de Transformação – Comparação com outras Abordagens

A combinação de EA – BPM-M não está restrita à
aplicação de programas de “melhorias”, é uma proposta de abordagem
para criação, estruturação, especificação e otimização operacional
empresarial. Porém, é muito comum encontrarmos comparações entre
métodos e abordagens diferentes desconsiderando suas diferentes
naturezas, amplitudes e profundidade de produtos e resultados.
36
Para suportar uma abordagem multidimensional,

integrada e estruturada de transformação que produza modelos e
especificações suficientemente adequados, completos e precisos para a
condução de transformações de arquitetura de negócio, aplicações,
informação e infraestrutura, somente os frameworks de engenharia
baseados em Enterprise Architecture funcionam com segurança. O
quadro a seguir compara as três abordagens mais utilizadas de mercado.
TOGAF + BPM M = melhoria contínua & engenharia operacional

Lean + Sixsigma = melhoria contínua
3. As Situações de Aplicação da BPM-M
A Engenharia Operacional de Negócio pode ser utilizada
basicamente em quatro situações onde se faz necessária a abordagem
dos elementos/dimensões operacionais:
37
Abrangência
Impacto (ciclo de
Situação Contexto Foco Profundidade transformação)
& Risco
Otimização Contínua Baixo Restrito Foco Total Completo

Monitoração das restrito (da estratégia até a
mudanças e/ou ou não implementação)
necessidades do
ambiente operacional,
adequação infinita por
demanda ou iniciativa
própria.
Intervenção Temporal Alto Restrito Foco Total Completo
Intervenção periódica ou não restrito (da estratégia até a
em decorrência da não ou não implementação)
monitoração do
ambiente operacional.
Realização por demanda.
Criação de Novo Baixo Irrestrito Foco Total Do modelo
Negócio Irrestrit proposto até a
Novos negócios e/ou o implementação
operações específicas
que demandam modelos
de operação ainda não
existentes.
Diagnóstico - Irrestrito Foco Parcial ou Total
Conhecimento da restrito Apenas o modelo
Situação Instalada de ou não atual &
operações existentes a Diagnóstico
fim de identificar
oportunidades de
otimização (melhoria).
As Classes de Serviço Configuráveis com base na abordagem

● Transformação Operacional de Negócio;
● Identificação de Oportunidades de Melhoria;
● Manutenção Operacional Pontual;
● Qualidade de Negócio Assegurada na Implementação de Pacotes de
Sistemas aplicativos (ERP, CRM, etc.);
● Ajuste em Operações com Pacotes de Sistemas Aplicativos já
implementados;
● Avaliação de Aderência de Sistemas Aplicativos ao Negócio;
● Projeto de Sistemas Aplicativos Orientados a Operação de Negócio;
● Otimização Operacional em Projetos de Certificação Qualidade;
● Fusão Operacional;
38
● Avaliação de métricas operacionais (volumétricas, financeiras,

qualitativas e temporais);
● Adequação de Quadro de Recursos Humanos;
● Treinamento e capacitação contínua operacional.
4. A transição para o estado de excelência operacional

Devido ao complexo relacionamento e interdependência
entre as operações de uma empresa a fatores restritivos internos e
externos, nem sempre é possível implementar um novo modelo
operacional em uma única etapa.
Para administrarmos essa transição faz necessária a
concepção de modelos operacionais em cenários intermediários,
modelos estes que considerem na sua arquitetura os conceitos da
situação circunstancialmente exequíveis e as restrições internas e
externas circunstanciais.
Pode ser necessária a definição de vários modelos
intermediários para a administração da transição.
Tipicamente as variáveis restritivas encontradas num
processo de transformação operacional que nos obriga a criar um
modelo de transição são:
 Impossibilidade de mudança imediata da plataforma
tecnológica;
 Restrições orçamentárias temporais;
 Mudança de cenário mercadológico;
 Sincronismo com a transformação de outras operações
envolvidas na transformação;
 Impasses políticos.
5. Configuração de Projetos
Suportados por nosso método de trabalho, estabelecemos
quesitos que constituem o critério de dimensionamento dos projetos.
Este critério permite aos clientes a definição de projetos modularizados
e escalonáveis, dotando nosso relacionamento de transparência,
39
flexibilidade e segurança total. Esta configuração é estabelecida para

“operação” identificada como Contexto do trabalho.
Contexto
Refere-se ao conjunto de macroprocessos da empresa a
serem abordados pelo processo de transformação. Cada processo do
contexto pode consistir em um “projeto” com relativa autonomia.
Definir o contexto de um projeto exige o conhecimento
da arquitetura operacional da empresa em questão, “arquitetura” essa
que pode ser diferente em cada segmento de mercado (banking, retail,
industry, telecom, services, utilities, logistics, healthy, etc.).
O domínio sobre os conceitos de administração
empresarial é de extrema importância para a segurança da definição do
contexto. De fato, a determinação do contexto de um dado projeto pode
requerer que o engenheiro operacional de negócio transcenda ao
conhecimento do gestor ou patrocinador do projeto, a fim de entender
qual deve ser a “verdadeiros” processos a serem abordados para buscar
a transformação declarada ou desejada pelo “cliente”.
A má definição do contexto do projeto pode acarretar na
impossibilidade ou na altíssima complexidade da implementação do
processo abordada.
Foco
Determina o conjunto de dimensões ou elementos
(atividades, tecnologia de informação, informação, recursos humanos,
regras de negócio, relações com o mercado e meio ambiente) a serem
abordados no projeto.
É configurado de acordo com a expectativa de produtos a
serem gerados e com o objetivo da transformação (desenvolver sistemas
aplicativos, redução de custos e ciclos de tempo, adequação de quadro
de recursos humanos, etc.). Para cada dimensão especifica a ser
abordada faz necessário abordar outras estritamente relacionadas, como
segue:
Dimensão Focada - Principal Dimensão Focada – Adicional Necessária
40
Relações com o Mercado

Tecnologia de Informação Atividade, Informação, Regra de Negócio
Recurso Humano Atividade
Meio ambiente Atividade
Regra de Negócio Atividade
Informação Atividade
Relações com o Mercado -
De acordo com o foco determinado para o projeto serão

estabelecidos os produtos (modelos) a serem gerados pelo trabalho a
engenharia, e consequentemente selecionadas as técnicas a serem
utilizadas para geração de tais produtos (modelos). A má determinação
do foco do projeto pode acarretar na insuficiência de informações
(modelos) para suportar o processo de transformação operacional.
Profundidade
Refere-se ao nível de detalhamento (decomposição) a ser
atingido na abordagem na especificação das dimensões e/ou elementos
definidos como foco.
Pode variar entre especificação detalhada, base para a
implementação ou de alto nível, níveis intermediários de decomposição.
Abrangência
Refere-se à extensão das fases do projeto a serem
executadas. Inicia-se com o conhecimento da situação corrente e pode
se estender até a implementação e monitoramento de resultados.
6. O Envolvimento do Cliente
Os trabalhos são realizados com a total participação e
envolvimento dos clientes, tanto na fase de absorção do conhecimento
da situação corrente, quanto na fase de criação da arquitetura otimizada.
Esta participação visa:
 O cliente envolvido e comprometido em todos os papéis
relevantes;
 A harmonia de objetivos;
41
 A instalação do espírito de equipe;

 A execução de atividades em grupo, racionais e otimizadas;
 A utilização de recursos visuais (WYSIWYG);
 A criação de uma base de conhecimento única e sólida para
compreensão da operação do negócio, garantindo a efetiva
transferência de know-how.
Para garantir o quadro de envolvidos essencialmente

necessários e termos todas as pessoas que possam influenciar sobre a
transformação, definimos um conjunto de metaclasses de pessoa a
serem consideradas na constituição da equipe de cada processo
abordado.
Adotamos cinco metaclasses de pessoas como pontos de
vista para fonte de informação na construção do modelo corrente (as is)
e críticos/decisores na construção do modelo otimizado (to be) na
realização de projetos de BPM-M.
Cada metaclasse (classe de pessoa) deve ser representada
por pessoas escolhidas entre aquelas que participam na operação e
comando do processo de negócio abordado.
As metaclasses são:
Operador:
Operador refere-se efetivamente à Classe de Pessoas que
está envolvida com a execução das atividades “procedurais” contidas na
operação observada. Portanto são pessoas conhecedoras dos “detalhes”
operacionais do negócio. Por outro lado, as pessoas desta classe não
possuem uma visão da operação ampla o suficiente a ponto de suportar
a compreensão de toda a cadeia de atividades e interações com outras
operações.
Esta metaclasse de pessoa proverá informações
operacionais num “grânulo” de detalhe bastante alto, porém muito
pontual, restritas ao âmbito de suas responsabilidades.
Como classe de pessoas contidas nesta metaclasse,
podemos ter classes referentes a cargos operacionais (cargos que não
sejam de comando), tais como: Auxiliar de Compras, Comprador,
Analista Financeiro, Vendedor, Auxiliar Administrativo, Porteiro,
42
Operador de Caixa, Recrutador, Analista Orçamentário, Inspetor,

Almoxarife e outros, cada qual afeto a uma área de interesse específica.
Envolvimento:
Ele deve ser envolvido em todas as atividades de
levantamento e validação que envolvam um alto grau de detalhamento
das dimensões focadas.
Especialista na Operação:
O especialista na Operação refere-se efetivamente à
Metaclasse de Pessoas que pode tanto estar envolvida com a execução
das atividades “procedurais” como com atividades de “comando”,
contidas na operação observada.
Portanto são pessoas conhecedoras do “todo” da
operação do negócio em um nível de detalhe suficiente a ponto de
suportar a compreensão de toda a cadeia de atividades e interações com
outras operações.
Esta metaclasse de pessoa proverá informações
operacionais num “granulo” de detalhe médio às vezes muito alto.
Como classe de pessoas contidas nesta metaclasse, podemos ter classes
referentes a cargos operacionais ou de comando.
Envolvimento:
Ele deve ser envolvido em todas as atividades de
levantamento, criação e validação do projeto, certamente é a metaclasse
de pessoa mais requerida ao longo do projeto.
Gestor da Operação:
Como gestor entendemos a Metaclasse de Pessoas
responsável pela gestão e comando da operação observada.
Esta metaclasse de pessoas nos proverá conhecimento
operacionais associados aos recursos de Controle, Coordenação,
Planejamento da operação observada.
Normalmente o gestor da operação possui autoridade
investida para tomar decisões sobre o modelo operacional e é o canal de
comunicação direto com níveis superiores de comando.
43
Envolvimento:
Ele deve ser envolvido nas fases de criação e validação
do projeto. É o responsável pela identificação das pessoas que
assumiram os papéis de Operador e Especialista da Operação.
Patrocinador:
O patrocinador é a metaclasse responsável pela
encomenda e custos e resultados do projeto em questão. Deve pertencer
preferencialmente à alta direção da empresa.
Envolvimento:
Ele deve ser envolvido em todas as fases de validação do
projeto. É o responsável pela definição da pessoa que assumirá o papel
de Gestor da Operação, pela definição de metas, pela definição de
diretrizes estratégicas, por garantir recursos para o projeto, por controlar
a evolução do projeto e por resolver impasses.
“Stakeholder” da Operação:
O “stakeholder” representa a metaclasse de pessoas que
possui a condição de perceber e medir o grau de satisfação gerado pela
operação, ou seja, são aqueles normalmente denominados “clientes” da
operação, embora não sejam eles necessariamente Clientes do negócio.
Podem ser qualquer Classe de Ator que tem o poder de
avaliar a qualidade da operação quando vista por quem solicita (dispara)
ou recebe seu produto (output) principal ou não.
Como classe de pessoas contidas nesta metaclasse,
podemos ter classes referentes aos cargos operacionais, cargos de
comando e entidades externas, tais como: clientes, fornecedores,
instituições financeiras, instituições legais, instituições governamentais,
investidores, sociedade, parceiros, etc.
Envolvimento:
O “stakeholder” deve ser envolvido nas fases que
necessitem compreensão ou confirmação de algo do ponto de vista
externo à operação abordada.
44
A seleção das pessoas que comporão a matriz de envolvimento

Uma atenção especial deve ser dada à seleção das
pessoas que assumiram os papéis da matriz de envolvimento, pois elas
podem interferir diretamente na qualidade do produto de trabalho e no
sucesso do processo de transformação. A qualidade do produto, para
operações existentes, está diretamente proposicional à qualidade do
levantamento que pode ser considerado engenharia de conhecimento.
A princípio os aspectos abaixo relacionados devem ser
observados quando da seleção das pessoas.
 Atendam aos requisitos de conhecimento de cada metaclasse;

 Sejam influenciadores naturais das demais pessoas envolvidas
na operação abordada;
 Tendam reconhecidamente a permanecer na empresa após o
processo de transformação;
 Não sejam resistores contumazes ao processo de transformação;
 Possuam autoridade reconhecida para tomar decisões quando
necessário;
 Sejam criativas e empreendedoras;
7. O Conceito de CAP
Este conceito preconizado pelo Ichak Adizes, em sua

obra literária Gerenciando Mudanças, é extremamente amplo, e a partir
dele, resumimos uma interpretação aplicável à BPM-M. Este diagrama
45
é utilizado em lógica simbólica para demonstrar a relação entre os

conjuntos. Quando autoridade e poder se sobrepõem, temos o Poder
Autorizado, esse é o direito de punir e recompensar.
Quando autoridade, poder e influência se sobrepõem,
temos uma nova combinação denominada CAPI (C de conjugação).
A empresa possui uma organização com autoridade para
dizer o que fazer, tem o poder para punir ou recompensar, e pode
influenciar a respeito da validade daquilo que quer que seja feito.
Quando uma empresa dispõe do CAPI, não há razões
para deixar de seguir seu curso de crescimento. Esta organização possui
o controle sobre seu processo de evolução.
 Autoridade,
 Este conceito é definido como sendo o “direito de dizer sim ou
não”.
Quando as organizações são jovens, seus fundadores
podem dizer sim e não. Eles têm plena autoridade, não se perguntam a
respeito de onde conseguir a provação para uma decisão.
Quando as organizações crescem e tornam-se
complicadas demais para serem gerenciadas somente pelos fundadores,
eles precisam delegar autoridade.
Como resultado, normalmente, eles delegam somente o
direito de dizer não. Isso é muito perigoso, porque a autoridade somente
para dizer não impede as mudanças e burocratiza a organização.
8. As etapas de um projeto de Transformação
Etapa 0 – Construir Arquitetura de alto nível da Empresa

46
Objetivo:
Compreender a arquitetura empresarial de alto nível focado nos
domínios de negocio, informação e aplicação. Identificar a “anatomia”
da empresa a fim de balizar o planejamento de transformação e seus
building blocks
Técnicas Utilizadas:
ENTERPRISE ARCHITECTURE;
Atividades Produtos
↘ Entrevistar os gestores de 2º. Nível ↘ Mapa de cadeia de valores
hierárquico
↘ Levantar o portfolio de aplicativos em ↘ Portfolio de aplicativos
uso
↘ Elaborar analise de problemas ↘ Mapa de analise de problemas;
matriz de vulnerabilidade
↘ Elaborar plano de transformação ↘ Plano de transformação, building
blocks
↘ Elaborar modelo de objetos de ↘ Modelo de objetos de negócio
negócio preliminar preliminar
Etapa 01 – Configurar e Planejar Projeto

Objetivo:
Adquirir conhecimento inicial sobre a natureza e abrangência do
projeto, juntamente com as expectativas do cliente. Criar o plano de
trabalho e ajustar a estrutura do método (atividades e participantes) em
conformidade com a natureza do projeto.
ENTERPRISE ARCHITECTURE
BPM-M
Planejamento de Projetos
Atividades Produtos
↘ Identificar variáveis de configuração ↘ Contexto, foco, profundidade,
abrangência, prioridade
↘ Identificar os objetivos e expectativas ↘ Relação de objetivos e expectativas;
de alto nível
47
↘ Identificar premissas e restrições de ↘ Descrição de premissas e restrições

alto nível
↘ Definir participantes do projeto ↘ Estrutura organizacional do projeto
↘ Elaborar Cronograma preliminar ↘ Cronograma preliminar
↘ Realizar kick off ↘ Comunicação (agenda e
responsabilidades)
Fase 02 – Conhecer Modelo Operacional Corrente

Objetivo:
Capacitar os participantes quanto ao conhecimento da realidade
corrente das operações abordadas, dar segurança as próximas etapas da
metodologia e criar a base de comparação para o modelo ideal
BPM-M
Engenharia de Informação
Análise de Problemas
Análise de Métricas
Atividades Produtos
↘ Construir o modelo de processo de ↘ DPN - macro processos (nível 0 e/ou
negócio procedural)
↘ Descrição do objetivo do processo;
↘ Especificar as dimensões definidas ↘ Modelo de Informação (Objetos de
como foco da situação corrente Negócio) - Alto nível
↘ Modelo de relacionamento dos
sistemas
↘ Descrição da plataforma tecnológica
↘ Modelo de regra de negócio
↘ Modelo de recursos humanos
↘ Modelo de meio ambiente
↘ Modelo de relações com o mercado
↘ Modelo de atividades
↘ Realizar a análise de problemas ↘ Mapa de problemas e plano de ações
corretivas;
↘ Definir os alvos de melhoria ↘ Relação de alvos de melhoria
↘ Levantar métricas ↘ Levantamento de métricas
48
operacionais
Fase 03 – Construir e/ou Manter Modelo Operacional Ideal

Objetivo:
Modelar a operação do contexto do projeto visando determinar uma
arquitetura que atinja aos alvos de melhoria pré-definidos, o plano de
ações corretivas e referencial de excelência estabelecidos.
ENTERPRISE ARCHITECTURE
BPM-M
Engenharia de Informação
UML.2X
Análise de Métricas
Atividades Produtos
↘ Definir expectativas de ↘ Descrição das expectativas de
ganho ganho
↘Construir o modelo de ↘DPN- macro processos ( nível 0
processo de negócio e/ou procedural)
↘Descrição do objetivo do processo;
↘ Especificar as ↘ Modelo de Informação (Objetos de
dimensões definidas Negócio) - Alto nível
como foco da Situação ↘ Projeto lógico do(s) sistema(s)
ideal ↘ Descrição de requerimento de
infraestrutura tecnológica
↘ Modelo de regra de negócio
↘ Modelo de recursos humanos
↘ Modelo de meio ambiente
↘ Modelo de relações com o mercado
↘ Modelo de atividades
↘ Modelo de métricas operacionais
↘ Identificar riscos e ↘ Descrição dos fatores críticos de
fatores críticos de sucesso e riscos
sucesso
Fase 04 – Transformar Recursos Operacionais
Objetivos:
49
Desenvolver e/ou construir os três elementos físicos envolvidos na

transformação, a Tecnologia de Informação, os Recursos Humanos e o
Meio Ambiente Físico
Atividades Produtos
↘ Avaliar, adquirir, ajustar e ↘ Pacotes de sistemas aplicativos
configurar os pacotes de disponíveis
sistemas aplicativos
↘ Desenvolver e/ou ajustar ↘ Sistemas aplicativos disponíveis
novos sistemas aplicativos ou
sistemas existentes
↘ Construir e/ou executar ↘ Meio ambiente físico disponível
reforma no meio ambiente
físico
↘ Recrutar, selecionar e/ou ↘ Equipe operacional disponível
avaliar e transferir pessoal
operacional e de comando
↘ Formalizar alterações de ↘ Estrutura divulgada
estrutura organizacional
↘ Realizar a instalação e/ou ↘ Infraestrutura tecnologia disponível
manutenção na infraestrutura
de tecnologia necessária
Fase 05 – Implementar Solução Operacional

Objetivos:
Implantar a solução completa (sistema; processo de negócio, políticas,
estrutura organizacional) desenvolvida em ambiente de operação final.
Atividades Produtos
↘ Capacitar equipe de ↘ Equipe capacitada
operadores e gestores
envolvidos na operação
↘ Estabelecer ambiente de ↘ Instalação definitiva do sistema;
produção
↘ Executar a conversão final ↘ Base de dados pronta para operar
da base de dados, depurar
base de dados convertida
e Efetuar Carga de dados
iniciais
50
↘ Realizar roll out da ↘ Operação iniciada

operação
Fase 06 – Avaliar Resultado Operacional

Objetivo
Avaliar, após um determinado período de operação, os resultados
obtidos com a implementação da solução completa. Corrigir eventuais
desvios e/ou falhas detectadas.
Atividades Produtos
↘ Avaliar a performance da ↘ Relatório de avaliação
operação
↘ Avaliar o efeito comportamental ↘ Relatório de avaliação
nos ambientes envolvidos
↘ Definir possíveis correções ↘ Especificação das correções
(execução das fases 4 e/ou 5)
Capítulo 03
ATIVIDADE & PROCESSO DE NEGÓCIO
51
“Atividades podem ser definidas como a especificação

de uma “unidade de ação” que descreve o comportamento humano para
transformar (criar, atualizar, eliminar, associar) classes de objeto no
contexto do negócio abordado.
A especificação de uma atividade envolve a explanação
de que classes de pessoa devem fazer, como resposta a estímulos, em
locais físicos específicos, utilizam recursos de tecnologia, para
transformar informações de objetos provenientes de inputs em
informações de valor, com base em regras de negócio, destinadas à
satisfação das necessidades de stakeholders”
É o componente central do modelo de processo
multidimensional. O modelo de atividades (processo de negócio) é a
"espinha dorsal" sobre o qual as demais dimensões são conectadas e/ou
derivadas:
As Classes de Pessoa são atribuídas às atividades como
responsáveis por sua execução. Os objetos são decompostos em
Informações que são combinadas em agrupamentos para serem
manipuladas em cada atividade do processo. A Tecnologia de
Informação é especificada como requerimento para suportar a execução
de cada atividade do processo.
As Regras de Negócio podem ser necessárias para
estabelecer controles e definir “como” cada atividade é executada. E
52
finalmente as atividades do processo têm seu processamento distribuído

fisicamente, definindo assim a requerimento para configuração do Meio
Ambiente de Processamento.
A Identificação das Atividades

Para a segura identificação das atividades de um
processo de negócio recomenda-se a observação dos seguintes critérios:
1. Compreensão do objetivo do processo em termos de

processamento dos objetos de negócio envolvidos. Processos de
negócio, normalmente, têm seu objetivo compreendido através da
definição das ações realizadas sobre um ou um conjunto de classes de
objeto. Essa definição determina a restrição de contexto do processo.
Por exemplo: Processo Vender Produtos a Cliente –
objetivo: Prospectar novos Clientes & atender a clientes ativos de
carteira, qualificá-los e classificá-los para orçamento e venda de
produtos de estoque.
Neste objetivo identificamos duas classes de objeto e as
ações realizadas entre eles:
a) Clientes;
b) Produto;
c) Criação, classificação & qualificação de instâncias de cliente;
d) Orçamentação & Venda de produto (duas classes de associação
entre instâncias de Cliente e Produto).
2. Identificação primária do nome da Atividade: A identificação do

nome de uma unidade de ação candidata a atividade é o primeiro passo,
após o conhecimento do objetivo e contexto do processo, para em
seguida se aplicar os demais critérios.
Uma ação é candidata a ser atividade quando
conseguimos definir com clareza o “Verbo” referente à ação e o “objeto
gramatical” sobre o qual a ação efetua um tipo de processamento.
Uma unidade de ação deve se referir ao processamento
de um objeto ou partes de um objeto que pertença ao contexto do
processo modelado. Frequentemente as unidades de ação se referem ao
processamento de grupos de dados que são agrupamento de
53
informações sobre um ou mais que um objeto de negócio processado

pelo processo de negócio (documentos, telas, mensagens, etc.). Estas
ações são basicamente de quatro naturezas: ações de transformação
(criação, eliminação, alteração), controle, movimentação,
recuperação/leitura.
Definir o nome adequado da ação candidata à atividade
exige a adequada análise morfológica das palavras (verbos e objetos) a
serem adotados. A inadequada definição do título da ação pode induzir
a outras falhas de modelagem.
3. Abordagem da sequência de processamento. Partindo-se de um

determinado “ponto de observação” no processo, podemos identificar as
“unidades de ação” utilizando uma abordagem que compreenda a
interdependência temporal dessas “unidades de ação” através de sua
estrutura de predecessão e sucessão.
Podemos identificar toda a sequência de ações de
transformação dos objetos de negócio descritos no objetivo de processo.
A forma mais simples e segura é iniciar a identificação das atividades a
partir do evento de negócio gatilho do processo, e seguir a cadeia de
sucessão identificando os possíveis desvios condicionais dessa cadeia.
Os desvios condicionais percebidos da classe de conexões lógicas do
tipo “E” e “OU”, a segunda representa perguntas de resposta binária.
4. Agregação e desagregação de Atividade. Este conceito

orienta o modelador sobre como “identificar” e definir atividades
subsequentes decidindo entre “juntá-las”, “separá-las” ou mantê-las no
mesmo nível de observação como identificadas primariamente. Essa
decisão é uma das dificuldades básicas na especificação de atividades e
pode ser orientada segundo o uso dos princípios:
a. Quando agregar atividades:

● Quando forem executadas pela mesma classe de ator e não
possuírem desvios condicionais ou interrupção temporal entre
elas ou quando não produzirem outputs de valor (inputs
transformados) entre elas.
b. Quando separar atividades:
54
● Quando forem executadas por diferentes classes de ator;

● Quando a descrição da ação possuir interrupção temporal;
● Quando ações custódias forem descritas junto com
transacionais;
● Quando a transformação exigir passos subsequentes com a
mesma classe de ator, porém com scripts independentes;
● Identificação de dois ou mais verbos “fortes” na titulação da
atividade;
A falha na aplicação deste conceito pode levar a

consequências inadequadas, tais como:
a. Falhas ou degradação da identificação & projeto de Casos

de Uso de sistemas aplicativos,
b. Falhas na identificação de objetos e grupo de dados;
c. Impossibilidade de valorar as métricas da atividade;
d. Dificuldade na configuração do perfil da classe de ator;
e. Aumento de complexidade do modelo;
f. Distorção do conceito de essencialidade.
A Titulação das Atividade

As atividades devem ser tituladas de forma que o título
transmita seu objetivo básico quanto à “o que fazer” com “o que”
através do uso de “verbo” e “objeto gramatical”.
A escolha do verbo deve ser criteriosa pois deve dar a
ideia exata da ação que será executada com respectivo objeto a ser
manipulado. Deve-se evitar a adoção de mais que um verbo na titulação
da atividade, sempre há um verbo “forte” que representa a ação
“essencial” a ser executada. Exemplo: “Consultar e aprovar requisição
de compra”, onde o verbo forte é “aprovar”.
A atividade deve ser titulada de forma sucinta, através do
emprego de um Verbo associado a um Objeto gramatical (objeto de
negócio ou elemento de dado). Exemplo:
55
Dicionário de Verbos - Classificação Quanto a Agregação de Valor

A escolha dos verbos adequados conduz à perfeita
compreensão do processo. A lista abaixo é uma referência dos verbos
conforme sua categoria essencial. Classificamos os verbos em seis
categorias básicas:
Verbos de transformação:
São os verbos que se referem às ações que transformam
os objetos e suas características. A transformação é intrínseca e pode ser
de estado/condição, formato, valor de característica. Como exemplo,
observamos que essa categoria de verbo é mandatória nos processos
produtivos industriais.
Verbos de controle:
São os verbos que não se referem a qualquer tipo de
transformação dos objetos e suas características. Ações que manipulam
os objetos e visam planejar ou controlar seu estado/condição, seu
formato, o valor de seus atributos, sua localização. Como exemplo,
observamos as atividades de aprovação, conciliação, inspeção, teste,
seleção, entre outras.
Verbos de movimentação:
São referentes a ações que se referem à movimentação
dos objetos na “dimensão espaço físico”. Como exemplo, observamos
os verbos transferir, guardar, separar, distribuir, etc.
Verbos de acesso à informação:
56
São verbos referentes a ações que não transformam e

nem controlam os objetos, porém, expressam ações que visam acessar,
disponibilizar, consultar informações sobre os objetos. Como exemplo,
observamos os verbos consultar, apresentar, etc.
Verbos de demanda:
São verbos que visam expressar ações que disparam ou
encerram cadeias ou trechos de cadeia de processos sem efetuar
nenhuma transformação, controle ou movimentação de objetos. Como
exemplo, observamos os verbos solicitar, requisitar, entregar, etc.
Verbos auxiliares:
São os verbos que precisam referir-se a outros verbos
para dar o significado à ação. O exemplo é o verbo “executar”.
Lista de Verbos Essenciais
Verbo Categoria
Acomodar Transformação
Adaptar Transformação
Administrar Controle
Admitir Movimentação
Agrupar Movimentação
Aguardar Movimentação
Ajustar Transformação
Alocar Transformação
Alterar Transformação
Analisar Controle
Apontar Controle
Apresentar Acesso a informação
Apropriar Controle
Aprovar Controle
Arquivar Movimentação
Atrasar Movimentação
Atualizar Transformação
57
Auditar Controle
Calcular Transformação
Calibrar Transformação
Carregar Movimentação
Catalogar Controle
Certificar Controle
Checar Controle
Classificar Controle
Coletar Movimentação
Coletar Movimentação
Completar Transformação
Conduzir Movimentação
Configurar Transformação
Confirmar Controle
Consultar Acesso a informação
Contar Controle
Copiar Transformação
Corrigir Transformação
Criar Transformação
Definir Transformação
Desempregar Transformação
Desenvolver Transformação
Designar Transformação
Determinar Transformação
Distribuir Movimentação
Eliminar Transformação
Emitir (gerar) Transformação
Empurrar Movimentação
Endossar Controle
Entregar Demanda
Escolher Controle
Estabelecer Transformação
Estocar Movimentação
58
Etiquetar Transformação
Examinar Controle
Executar Auxiliar
Exibir Acesso a informação
Expedir Movimentação
Fabricar Transformação
Fixar Transformação
Formular Transformação
Gerar Transformação
Gravar Transformação
Identificar Transformação
Implementar Transformação
Informar Acesso a informação
Inspecionar Controle
Instalar Transformação
Instruir Acesso a informação
integrar Transformação
Limpar Transformação
Manter Transformação
Marcar Transformação
Medir Controle
Modificar Transformação
Monitorar Controle
Montar Transformação
Mover Movimentação
Mudar Transformação
Negociar Transformação
Observar Controle
Orientar Controle
Pedir Demanda
Pesar Controle
Pesquisar Acesso a informação
Planejar Controle
59
Preencher Transformação
Preparar Transformação
Priorizar Controle
Processar Transformação
Produzir Transformação
Prover Transformação
Puxar Movimentação
Ratificar Transformação
Receber Movimentação
Reconciliar Controle
Reembolsar Transformação
Registrar Controle
Regular Transformação
Remover Transformação
Reparar Transformação
Reportar Controle
Reproduzir Transformação
Requerer Demanda
Requisitar Demanda
Restaurar Transformação
Retornar Movimentação
Retrabalhar Transformação
Rever Controle
Revisar Controle
Rotular Transformação
Selecionar Controle
Separar Movimentação
Solicitar Demanda
Testar Controle
Transferir Movimentação
Obter Transformação
Validar Controle
Verificar Controle
60
A Composição e Decomposição de atividade (Nível de observação)

Toda atividade, a princípio, pode ser decomposta
recursivamente, de maneira que suas decomposições se tornam
processos subordinados ou subprocessos.
A decomposição sucessiva pode ocorrer até que se
identifique uma atividade subordinada que represente ações não
decomponíveis, desta forma, podem existir vários Níveis de Observação
para um mesmo processo de negócio. Algumas técnicas recomendam
limites de decomposição com a quantidade de níveis variando entre 3+-
1.
Ponto de Partida
O ponto de partida é o conceito mais importante quando
da definição de abrangência, contexto e “fronteiras” a serem observadas
para o processo.
A adoção de um nível de observação adequado como

ponto de partida, é essencial a compreensão de todos as dimensões e
61
aspectos das atividades do processo de negócio, tanto para o

conhecimento da situação corrente, quanto para a modelagem de
soluções. De sua má definição, podem decorrer efeitos negativos como:
 Deficiência da compreensão da estrutura de interdependência
dos processos de negócio abordados;
 Falha na análise e solução de problemas e aspectos críticos;
 Má configuração de soluções de requerimentos de tecnologia;
recursos humanos;
 Falhas na análise de métricas e projeto de indicadores entre
outros problemas.
Ponto de Partida Ideal vs. Prático

O ponto de partida ideal de decomposição é aquele que
corresponde ao próprio macro processo de negócio, onde podemos
compreender seu objetivo e definir com clareza as restrições de
contexto para identificação das atividades atômicas.
Desta forma, o ponto de partida prático e seguro é adotar
o nível de observação inicial que corresponda ao nível imediatamente
acima do nível de real interesse do trabalho.
Assim, é possível estudar as interdependências do
processo abordado e assegurar:
 a perfeita compreensão do segmento de negócio,
 suas verdadeiras relações de causa-efeito;
 a perfeita identificação de suas macro conexões;
 sua função e objetivos no contexto em que está envolvido.
Um aspecto importante a ser observado é que, quanto
mais amplos forem os processos, ou quanto mais alto for o nível de
observação, maior é a possibilidade de otimização através da
integração, a complexidade envolvida e a dificuldade de mensurá-los e
modificá-los.
Limite Prático de Decomposição

Ou seja, é neste nível de observação que encontramos as
atividades atômicas, executadas por pessoas através da organização da
empresa.
62
É, também, neste nível de observação que encontramos a

interseção do projeto de processos de negócio com o projeto de sistemas
de informação, através da identificação e seleção das atividades a serem
executadas e ou suportadas por processadores artificiais.
Cuidados a Tomar com a Decomposição e o Nivelamento

Todos os subprocessos contidos em um processo
(decompostos) devem preferencialmente ser decompostos com a mesma
quantidade de níveis de observação, isto facilita compreensão do
modelo visto que navegar (subir e descer) em uma árvore de
subordinações desbalanceada pode provocar um sentimento de
desorientação do observador. Isto porque de fato o único nível de
observação que realmente existe em um processo é o nível procedural
(atômico), os demais níveis de observação não virtuais e servem
exclusivamente para particionar a visão do modelo para o modelado.
A Descrição da Atividade
Uma atenção especial deve ser dada à descrição das
atividades. Descrições de atividades são scripts para a execução de
tarefas humanas, portanto devem ser adequadas para interpretação
humana. Descrições de atividades são mensagens, que segundo
Napoleão Bonaparte, devem ter como qualidade:
“Uma mensagem deve ser clara, objetiva e completa”
A descrição de atividades deve essencialmente ater-se a

descrever o que deve ser feito por uma determinada classe de ator.
A especificação de uma atividade envolve a explanação
de o que a classe de pessoa deve fazer, respondendo a quais eventos de
negócio, em quais locais físicos específicos, utilizando quais recursos
de tecnologia da informação, para com base em quais regras de
negócio, transformar quais grupos de dados em output de valor
destinados a uma atividade sucessora ou a uma entidade externa.
Sua estrutura da especificação deve considerar a escolha
mais adequada de verbos, adjetivos e objetos gramaticais, este último
(objetos) devem necessariamente referir-se aos objetos de negócio
63
manipulados pelo processo e/ou aos grupos de dados manipulados pela

atividade.
Deve-se evitar descrever ou especificar na especificação
da atividade:
 Especificar o como realizá-la, pois esta é a especificação da
dimensão regra de negócio;
 Referir-se à classe de atores, tanto o responsável pela atividade
quanto outros;
 Referir-se às atividades predecessoras e/ou sucessoras;
Exemplos:
01.04 - Elaborar plano campanha anual

Elaborar o plano de campanha para o exercício corrente,
considerando o histórico dos planos dos exercícios anteriores e os novos
eventos e oportunidades identificados pela pesquisa. Considerar as
relações dos eventos com as "regiões de anúncio" e "segmento de
mercado" específicos, sobre os quais cada evento irá impactar como
gerador de oportunidades de venda.
Registrar o novo, ou atualizações do plano de campanha
junto ao sistema, avaliar o impacto, estimado pelo sistema, sobre os
"produtos" e "base de clientes" afetados pelos eventos. Efetuar ajustes
na configuração dos eventos avaliando os impactos diferenciados sobre
a base.
02.04 - Informar qtde. de páginas dos cadernos da edição,

Registrar, junto ao sistema, a quantidade de páginas de
cada caderno de edição dimensionado, com base na simulação e no
histórico de vendas dos cadernos da respectiva publicação.
A quantidade de páginas definida para cada caderno será a regra de
limite de páginas a ser controlada pelo sistema no subprocesso de
vendas.
Caso a quantidade de páginas a ser definida ultrapasse ao
"limite" máximo definido pelo editor responsável pela revista, deverá
64
ser realizada "negociação" junto a este editor a fim de obter, ou não, a

aprovação da ampliação da quantidade de páginas dos respectivos
cadernos.
03.12 - Recepcionar chamado direto

Atender ao chamado telefônico de clientes, identificar a
natureza do chamado,
 Se chamado referente à venda,

Ofertar os produtos de classificados, considerando o "plano de
campanha de eventos" a matriz "produto" por segmento de mercado
informados pelo sistema. Negociar a venda conforme determinação do
conjunto de políticas de comercialização.
 Se chamado referente a solicitação de informação,
Registrar novo relacionamento. Quando necessário programar novo
contato ou registrar o contato efetuado sem sucesso de venda, registrar
um novo relacionamento associado ao cliente, como realizado ou
programado. Aproveitar a oportunidade para cadastrar ou atualizar os
dados cadastrais do respectivo cliente
Os Atributos da Atividade
Na especificação da Atividade estabelecemos um
conjunto de informações essenciais sobre a própria Dimensão Atividade
e identificamos as demais Dimensões correlacionadas a ela, definindo
desta forma, o modelo multidimensional. Estas informações são:
 WBSC da atividade (código estruturado);

 Título da atividade;
 Nível de observação da atividade (na estrutura de decomposição
hierárquica);
 Tipo de atividade (manual ou caso de uso);
 Descrição da atividade;
 Descrição do requerimento funcional para suporte de sistemas
aplicativos;
65
 Informação sobre métricas da atividade (ex: tempo de

processamento unitário, tempo de espera, volume de
processamento, valor agregado, entre outras).
Processo de Negócio
Série de atividades que se sucedem e são ligadas por
relações de estímulo. Conjunto de atividades interdependentes e
ordenadas no tempo e espaço, que ocorrem como resposta a estímulos, e
que possuem início, fim, inputs e outputs, bem definidos.
Sob uma segunda ótica, podemos definir processo de
negócio como uma visão integrada da organização da arquitetura
empresarial, através da qual se compreende a interdependência
funcional e existencial dos elementos:
 Relações com mercado;
 Atividades;
 Informação;
 Tecnologia de informação;
 Regras de Negócio;
 Recursos humanos;
 Meio Ambiente Físico.
Então podemos definir um processo de negócio como:

“Modelo arquitetônico que combina e ordena elementos no tempo e
espaço definindo como, quando e onde informações são transformadas
por pessoas e máquinas, através de atividades executadas com base em
regras preestabelecidas”.
66
Portanto, os processos de negócio permeiam a estrutura

organizacional da empresa, envolvendo coordenadamente áreas de
diversas disciplinas, com o objetivo de produzir outputs, sejam eles
bens, serviços ou informações, para atender às necessidades dos
Clientes.
Concluindo, podemos compreender a empresa como um
conjunto de processos de negócio inter-relacionados, que têm na
essência, como objetivo primário, responder direta ou indiretamente aos
estímulos da entidade externa Cliente.
A Definição de Processo de Negócio
“...ordenação específica das atividades de trabalho no tempo e espaço,

com inputs e outputs claramente identificados, uma estrutura para
ação...”
Thomas H. Davenport
“...uma ou um conjunto de atividades inter-relacionadas, destinadas a

transformar um ou mais inputs em um ou mais outputs que representem
soluções do ponto de vista de clientes internos ou externos...”
Lon Roberts
“...conjunto de atividades com uma ou mais espécies de entrada, e que

cria uma saída de valor para o cliente...“
Michael Hammer
“...é uma coleção de atividades interagidas que trabalham para

produzir e definir produtos e serviços. Todos os processos empresariais
existem para cumprir a missão da empresa. Os processos de negócios
devem estar relacionados de alguma maneira à missão da empresa...”
Daniel S. Appleton
Para aplicação no BPM-M adotamos:
“Um processo de negócio é um conjunto de atividades,

interdependentes e ordenadas no tempo e espaço, que visa uma
67
transformação específica (criação, atualização, eliminação,

associação) de classes de objeto no contexto do negócio da empresa.
Estas atividades são executadas, em locais específicos, por classes de
pessoa auxiliadas por recursos de tecnologia, com base em regras, com
o objetivo de responder a estímulos, transformando informações
provenientes de inputs em informações de valor, destinadas à
satisfação das necessidades de uma classe de cliente”.
Portanto, sob o enfoque do BPM-M, são passíveis de
serem engenhados, todos os processos que têm, predominantemente,
como finalidade o processamento de informações e serviços
informações.
Processos industriais são aqueles que transformam
predominantemente bens materiais. A engenharia destes processos não
é o objetivo do BPM-M, visto que para a engenharia da dimensão de
tecnologia é exigido o domínio sobre as tecnologias fabris. Porém,
como todo processo processa uma parcela de matéria e de informação,
eles podem ser abordados utilizando-se o BPM-M para a engenharia do
processamento da informação que nele está contida.
Cuidados a tomar:
Não confundir modelo de processo de negócio com:
 Modelo de sistema de informação (softwares aplicativos);
 Modelo de Informação ou de dados;
 Modelo de estrutura organizacional;
 Modelo de organização física de ambientes de trabalho.
Todos estes modelos são essenciais à compreensão da

organização do negócio, porém, cada qual representa uma visão
específica.
68
Estrutura Organizacional vs. Modelo de Processo de Negócio
As estruturas organizacionais, definem uma visão das

relações de subordinação e comando, bem como das responsabilidades
dos papéis que compõem essa estrutura.
Por outro lado, a visão de processo é dinâmica e
representa a forma através da qual a empresa combina e aplica seus
ativos para produzir um determinado conjunto de valores.
É muito comum a tentativa de identificar processos
através da abordagem da estrutura organizacional, o que, na maioria dos
casos, conduz a um resultado distante do conceito de processo de
negócio.
Arquitetura Básica de um Processo de Negócio

Sabemos da diversidade de particularidades que as
operações possuem nas diversas áreas de interesse (suprimentos, RH,
logística, vendas, finanças, produção, manutenção, etc.) nas empresas
dos diversos segmentos de mercado (varejo, indústria, bancos,
financeiras, saúde, serviços, utilidades, logística, transportes etc.).
Sabemos também que apesar das infinitas
particularidades que podem ser encontradas nas diversas operações nos
diversos cenários, podemos identificar uma certa “arquitetura” básica
em todas as operações, anatomia que faz referência aos agrupamentos
69
de atividades (subprocessos) que normalmente podem compor estes

processos.
Estes componentes da “arquitetura” podem ser utilizados
pelo engenheiro de processos como um guia inicial para a compreensão
e estruturação de operações, mesmo quando referentes a uma classe não
estudada anteriormente.
Arquitetura Empresarial - Cadeia de Valor Agregado
Utilizamos aqui a teoria de Cadeia de Valor criada por

Michael Porter em 1985, que representa o conjunto de atividades
desempenhadas por uma organização desde as relações com os
fornecedores, ciclos de produção, e de venda até à fase da distribuição
final.
Com base neste conceito, podemos compreender uma
empresa através de uma anatomia básica de funcionamento que,
independentemente da natureza de sua atividade, pode ser estabelecida
como padrão e ser conhecido e estudado.
As partes desta anatomia são os processos de negócio
que cumprem determinadas funções necessárias para a operação do
negócio. Estes processos de negócio são agrupados em CADEIAS DE
VALOR AGREGADO (CVA) de acordo a semelhança da missão dos
processos em termos de manipulação de Objetos de Negócio e grau de
70
associação à atividade fim da empresa (primários ou de apoio segundo

M. Porter).
Para efeito da representação integral da anatomia, estas

cadeias foram classificadas pelo BPM-M em três grupos:
 cadeias do CORE BUSINESS (primária)

 cadeias de SUPORTE
 cadeias de CONTROLE.
Este é do ponto de vista do BPM – Multidimensional,

este é o ponto de partida para a decomposição da Arquitetura de
Processos de Negócio e uma boa forma de garantir a compreensão do
contexto de um projeto.
 As cadeias do core business (primária): contém os processos
de negócio diretamente relacionados com a missão e/ou
atividade fim da empresa, e estão obrigatoriamente associadas à
produção dos outputs de valor agregado do ponto de vista do
cliente. O conjunto de processos de negócio que está contido
nesta cadeia pode variar de acordo com atividade fim da
empresa (segmento de mercado), e é efetivamente o que
diferencia uma Empresa de sérvios, de uma indústria, ou
empresa de saúde, ou financeira, ou banco, ou seguros, ou
educação, ou utilidades etc. Processos que em uma determinada
vertical são processos de suporte ou controle podem constituir
processos do core business para empresas de outro segmento de
mercado. Por exemplo: Em uma empresa do segmento
financeiro a cadeia “Gerir Recursos Financeiros” certamente faz
parte do CORE enquanto em uma empresa do segmento de
saúde está associada ao CONTROLE da operação.
● As cadeias de suporte contêm os processos de negócio

relacionados produção ou a provisão de insumos para os
processos do CORE BUSINESS. Tal qual recursos humanos,
materiais, tecnologia de informação e outros insumos e
71
habilitadores necessários que aqueles processos operem. Como

cadeias de Controle podemos relacionar:
▪ Gerir suprimentos de bens e serviços
▪ Gerir recursos humanos
▪ Gerir recursos de tecnologia de informação
▪ Gerir manutenção de ativos
▪ Gerir serviços de suporte
● As cadeias de controle contêm os processos de negócio

relacionados ao controle da operação do negócio, ou melhor, ao
controle da operação dos demais processos do negócio. Como
cadeia de controle podemos relacionar:
▪ Planejar a operação
▪ Gerir recursos financeiros
▪ Controlar a operação
▪ Gerir compliance
Esta forma de compreensão da arquitetura empresarial é

o caminho para uma visão mais clara e ordenada da centena de
processos e instâncias de dimensões que podem existir na compreensão
desse organismo empresa.
Isto não significa necessariamente que os processos em si
tenham exatamente a mesma arquitetura, porém em termos de objetivo
são certamente idênticos. E com base em uma visão semelhante que as
soluções de sistemas ERP (Enterprise Resource Planning) foram
concebidas, partindo do fato que os diversos segmentos de mercado
contêm, basicamente, os mesmos conjuntos de processos para Controlar
e Suportar a operação.
A Relação Volume – Variedade

A primeira decisão a ser tomada na concepção de um
processo é a classificação do tipo de processo. Em termos amplos, é a
característica de volume-variedade que dita o tipo de processo.
Cada tipo de processo de manufatura ou serviço implica
em uma forma diferente de organizar as atividades das operações com
72
diferentes características de volume e variedade. Os tipos de processos

são:
M Processo de Cada processamento possui um lead time diferente e longo e o modelo de processo é
A projeto organizado, predominantemente, de forma ad hoc em cada processamento.
N
U
F Processo de A maior parte dos processamentos é única ou de baixo grau de repetição. Os
A Jobbing recursos de transformação não são próprios, são compartilhados com os de outras
T operações e envolvem especialistas processadores, produzindo alta variedade e baixo
U volume. (ex. restaurar móveis, confeccionar roupa sobre medida)
R Processo de São relativamente repetitivos, produzem volumes elevados, porém podem variar de
A lotes modelo de processo para cada produto produzido.
Processo de Produzem produtos em alto volume e possuem um modelo de processo
produção em relativamente estável para cada classe de produto, sendo que as variáveis de cada
massa classe de produto não afetam o modelo de processo de negócio.
Produzem produtos em altíssimo volume e possuem baixíssima variedade sobre o
Processo
modelo de processo. Normalmente operam por períodos muito longos, chegando
contínuo
literalmente a serem contínuos e ininterruptos.
S Processo de São operações onde os clientes demandam tempo considerável do processo, o

E serviço modelo de processo considera para cada processamento um alto nível de
R profissional customização. São baseados em pessoas e não possuem modelos estáveis, são ad
V hoc.
I Processo de Compreendem muitas interações com clientes, demandando tempo limitado e baixa
Ç serviço em customização. São baseados em modelos relativamente estáveis e em produtos
O massa “padrão”.
S Processo de É caracterizado por níveis de contato com cliente, customização, volume de cliente e
“loja” de liberdade de decisão pessoal, que o coloca entre os extremos do serviço profissional
serviços e de massa. O processo é baseado em serviço de front office e back office, o
primeiro pessoal e parcialmente planejado e o segundo completamente planejado.
❑ TIPO DE PROCESSO EM NEGÓCIOS DE MANUFATURA
73
❑ TIPOS DE PROCESSO EM OPERAÇÕES DE SERVIÇO
● Forma de Disparo
Os processos podem ser ativados por estímulos, ou
agirem por decisão própria. A esta característica, damos duas
classificações:
 Reativa
Processos de natureza reativa são aqueles que iniciam
como reação a estímulos, sejam eles procedentes de entidades externas
ou de outros processos, por exemplo:
 Comprar item planejado para produção;
 Produzir item encomendado pelo cliente.
 Proativa
Processos de natureza proativa são aqueles que têm
início por decisão dos processadores (classes de pessoas) do próprio
processo. Os estímulos (eventos) têm como sujeito, os responsáveis
pelo próprio processo.
Processos desta natureza normalmente são identificados
em um nível de observação muito alto, e estão condicionados a decisões
tomadas pela própria empresa.
Possuem eventos de decisão que disparam seu início,
porém não possuem estímulos definidos, por exemplo: Aplicar recursos
financeiros no mercado de capital, gerir campanha de marketing.
74
 Forma de Execução (Quanto à Natureza das Atividades)

▪ Planejada
É aquela cuja forma de execução (procedimentos e
especificação), é invariável e predeterminada (padrão) que reage a todos
os estímulos previstos. Esses processos são tipicamente passíveis de
otimização, pois podem ter uma arquitetura com alto nível de
padronização sem, para isso, ter a dependência de análise e decisões
humanas, em tempo de processamento. Um processo de atividades
planejadas pode conter trechos de atividades ad hoc, por exemplo:
planejar ordens de produção, receber itens comprados de fornecedor;
▪ Casual (ad hoc)

É aquela cuja forma de execução (procedimentos e
especificação) é variável. Esses processos não são padronizáveis, e tem
sua e arquitetura detalhada estabelecida para cada caso de
processamento.
Esses processos podem ter uma arquitetura com baixo
nível de padronização, e são dependentes de análise e decisões
humanas, em tempo de processamento.
A capacitação especialista, conhecimento profundo do
negócio e a autoridade delegada são fundamentais para as pessoas que
participam do processamento, embora este possa ser auxiliado por
tecnologia de informação. Exemplo: gerir campanha de marketing.
 Finalidade
Um processo pode ter diferentes finalidades, de acordo
com o relacionamento que possui com a atividade fim da empresa. As
finalidades são:
▪ Linha
Refere-se aos processos que tem como objetivo, gerar os
produtos da empresa. São compostos por ações que agregam valor real
aos produtos, por exemplo: gerir venda de produto, desenvolver e
manter produto.
▪ Controle
75
Refere-se aos processos que tem como objetivo,

monitorar a operação de outros processos. São compostos por ações que
não agregam valor aos produtos da empresa, por exemplo: administrar
contabilidade societária, planejar e controlar produção, administrar
contabilidade de custo.
▪ Suporte
Refere-se aos processos que suportam à operação de
outros processos através do suprimento de recursos, quer esses recursos
sejam insumos ou não do produto desses processos. São compostos que
por ações que agregam valor de negócio, por exemplo: gerir compra de
bens e serviços, etc.
▪ Custódia
Refere-se aos processos que custodiam (tomam
conta/mantêm) as regras de negócio e objetos de negócio e suas
relações “estáticas” que precisarão existir previamente (antes do
processamento propriamente dito) para possibilitar o disparo e a
operação do negócio, por exemplo: gerir cadastro de item (material,
produto, serviço, etc.).
A Notação Segundo as Técnicas IDEF0 e IDEF3 - Ajustadas:

Selecionamos, dentre as técnicas mais conhecidas, o
conjunto de técnicas IDEF0 e IDEF3, respectivamente decomposição
funcional e processo de negócio como sendo a base conceitual para
aplicação do BPM-M.
Embora originalmente as técnicas sejam excludentes e
complementares, foram unidas e ajustadas a fim de permitir a utilização
de uma única notação para a representação do modelo de processo de
negócio.
IDEF 0
Regulamentada nos Estados Unidos pelo NIST desde
1993 como: Name of Standard. Integration Definition for Function
Modeling (IDEF0). Category of Standard. Software Standard,
Modeling Techniques.
76
Originária da técnica SADT (Structured Analysis and

Design Technique) estabelece um conjunto de conceitos que norteiam a
modelagem funcional sem a preocupação da compreensão de sua
ordenação no tempo ou espaço (processo).
Preocupa-se essencialmente com composição e
decomposição de ATIVIDADES (funções) e suas interações com
CONTROLES, MECANISMOS, INPUTS e OUTPUTS.
Tradicionalmente conhecido como o conceito ICOM (Input, Control,
Output, Mechanism).
IDEF 3
Também originária da técnica SADT estabelece um
conjunto de conceitos que suportam a modelagem de processos com a
preocupação fundamental de demonstrar a ordenação no tempo e espaço
de atividades e suas condições de desvios e junções. Não demonstra as
relações entre ATIVIDADE, CONTROLE, MECANISMOS, INPUTS
E OUTPUTS.
Nossa Notação IDEF 0 e IDEF 3 - AJUSTADA
Fundimos as técnicas IDEF 0 e 3 a fim de suportar a

definição simultânea da ordenação no tempo e espaço das atividades e
suas relações com controles, mecanismos, inputs e outputs. Ajustamos o
produto desta fusão inserindo os conceitos de:
77
a) Evento de negócio e entidades externas a fim de permitir a

definição do gatilho ou disparo dos processos bem como o
conhecimento da origem e destino de inputs e outputs.
b) Classe de ator a fim de permitir a definição dos operadores das
atividades e;
c) Local de processamento a fim de permitir a definição do local
de processamento de cada atividade.
d) Ajustamos o significado dos inputs e outputs para grupo de
dados, o significado de controles para regras de negócio, e o
significado de mecanismos para suporte de tecnologia (use case
segundo a técnica OOSE).
Desta forma obtivemos uma técnica que suporta
engenhar operações de negócio considerando simultaneamente as sete
dimensões e/ou elementos no ambiente empresarial:
1. Atividade;
2. Relações com o mercado;
3. Regra de negócio;
4. Informação;
5. Tecnologia de informação;
6. Recurso humano;
7. Meio ambiente.
A Representação Gráfica da Arquitetura dos Processos de Negócio

O Objetivo da representação gráfica:
 Estabelecer um instrumento que permita uma visão
multidimensional do modelo de processo;
 Ser o elo de comunicação entre os engenheiros e os diversos
especialistas, gestores, operadores e “stakeholders” envolvidos
no processo;
 Permitir a compreensão da arquitetura temporal e espacial
envolvida no modelo do processo;
 Tornar a engenharia e a análise do modelo de processo algo
visível e “tangível”;
 Permitir aos gestores e operadores participarem da modelagem
de uma forma “intuitiva”.
78
Características Fundamentais ao Produto da Representação Gráfica;

 Ser agradável aos olhos (não utilizar excesso de cores,
espessuras de linhas ou de setas);
 Ser simétrico e alinhado (manter simetria de distâncias e
alinhamento de símbolos);
 Ser “leve” a medida do possível do tocante ao volume de
informações contidas;
 Ser a medida do possível “navegável” na estrutura de
subordinação de atividades.
Diagrama de Processo de Negócio - DPN
O diagrama de fluxo de processos é uma ferramenta de
representação gráfica de modelo de processos, que permite demonstrar
de forma integrada a visão completa de todos os elementos envolvidos
no processo. Com o diagrama é possível demonstrar simultaneamente:
 As relações com as entidades externas ao negócio (Eventos de
negócio);
 A arquitetura de ordenação das ações;
 Os desvios e decisões na cadeia de ações do processo;
 As regras de negócio que orientam a execução das ações;
 A existência de tecnologia suportando a execução das ações;
 As classes de atores responsáveis pela execução das ações;
 A conexão dos processos com outros processos da empresa;
 A localização no tempo e no espaço de cada ação e/ou processo.
Simbologia Gráfica
79
A História do IDEF
A abordagem do BPM-M tem como base um conjunto de
técnicas, dentre as quais uma destaca-se como a principal por suportar
a modelagem do elemento atividade. Esta técnica é conhecida como
IDEF (Integrated definition).
A técnica IDEF foi desenvolvida por Doug Ross nos
anos 60, e originalmente conhecida por SADT (Structured Analysis and
Design Technique). No começo dos anos 80, a U.S.A Air Force,
adotou SADT como ferramenta primária para apoiar seu programa
chamado ICAM (Integrated Computer Aided Manufacturing).
O objetivo do programa ICAM era encorajar os
fornecedores da indústria de defesa a melhorar sua produtividade, e
reduzir custos e prazos através da reestruturação dos seus processos de
negócio. O SADT tornou-se uma das duas técnicas de modelagem de
negócios usadas no programa ICAM, que mudou o nome de SADT para
IDEF0 (IDEF derivado de ICAM Definition Language). Hoje, o
acrônimo tem o significado de Integrated Definition.
O sufixo zero distingue as técnicas de modelagem de
atividade da técnica de modelagem da regra de negócio, que é chamada
de IDEF1 estendida, ou IDEF1X. Foram essas técnicas desenvolvidas
pela coalizão de indústrias formada pela Força Aérea Americana, e
liderada por D. Appleton Company (DACOM). Juntas, as duas técnicas
de modelagem de negócios, são simplesmente chamadas IDEF.
Começando no início dos anos 80, times de fornecedores
da indústria de defesa construíram centenas de modelos IDEF (IDEF0 e
IDEF1X),usando-os para entender e melhorar todo tipo de processos
empresariais de controle do chão-de-fábrica, inventário gerencial,
mudança de engenharia gerencial, controles, Design Conceitual do
produto, design detalhado do produto, controle de qualidade, apoio
logístico, engenharia de suporte, e assim segue.
O ICAM teve dois objetivos para esses projetos de
modelagem. O primeiro objetivo era construir modelos padrões de
processos empresariais críticos.
Esses modelos seriam usados para avaliar os processos
dos fornecedores da indústria de defesa para determinar áreas de
problemas potenciais. Eles também seriam usados como Benchmarks
80
para melhores práticas: isto é, um Fornecedor poderia usar um modelo

IDEF ICAM como um referencial para auto melhoria.
O segundo Objetivo, e em muitos casos o mais
importante dos dois, era dar aos fornecedores uma simples, mas
rigorosa, linguagem que poderia ser empregada por qualquer um, não
apenas pessoal técnico em análise de negócios.
Dado a esta linguagem, os fornecedores puderam então
estabelecer um programa interno de engenharia de negócios, similar ao
emergente programa TQM (Total Quality Management), e melhorar o
passo da modernização industrial, como então foi chamado.
Ambos os Objetivos foram atingidos, mas o segundo
excedeu os sonhos do ICAM. Milhares de pessoas, de executivos a
empregados, foram treinados pelo IDEF, e começou a ter vida própria.
Não somente foi abraçado pelos fornecedores da
indústria de defesa, em todas as formas e tamanhos, mas alastrou-se
para fora do segmento, encontrando seu caminho dentro de companhias
como General Motors, IBM, Motorola, Bank of America, American
Airlines, GTE, GE, Westinghouse e Digital Equipment. Ao mesmo
tempo começou a funcionar dentro do Departamento de Defesa Norte
Americano, tornando-se uma linguagem padrão interna (DoD) parte do
padrão do programa CIM (Corporate Information Processing) e
subsequentemente, um padrão do governo federal inteiro, chamado de
padrão FIP (Federal Information Processing).
A técnica IDEF está sendo padronizada pelo Instituto
Americano de Padrões Nacionais (ANSI) sob os auspícios do Instituto
Nacional de Padrões e Tecnologia (NIST) do Departamento de
Comércio Norte Americano.
Até 1994, com programa CIM do Pentágono, a técnica
IDEF foi responsável por permitir a identificação de mais de US$ 2
Bilhões em economias e na época o Governo Norte Americano,
Administração Clinton, estava analisando a adoção da técnica como
base para o programa de Reinvenção do Governo.
81
Representação do Disparo do Processo (Evento de Negócio)
Forma de Ordenação (Arquitetura Interna do Processo)
A forma de ordenação das atividades do processo é uma

característica importante de sua arquitetura interna, e um dos recursos
que deve ser utilizado para a redução do seu ciclo de tempo de
processamento (lead time), sincronização de execução de atividades não
concorrentes e sequenciamento de atividades interdependentes.
Esse aspecto do processo pode ser estudado com
profundidade através da técnica PERT (Program Evaluation Review
Technique) - CPM que buscam identificar o caminho crítico da
sequência de atividades.
As ações podem estar ordenadas de diferentes formas
através do processo, identificamos três formas de ordenação:
 Sequencial
82
Quando as ações são ordenadas para execução uma após

a outra, numa relação de interdependência e precedência. São do
tipo “finish to start”.
 Paralela
Quando as atividades são ordenadas para execução
simultânea e têm independência total entre si, porem tem um “ponto”
comum de predecessão na cadeia de atividades.
Sincronismo de Execução entre as Atividades

 Síncrona
Quando as atividades são ordenadas em paralelo, mesmo
quando em cadeias totalmente independente, porém com uma
relação de dependência do tipo “finish to finish” ou “start to
start”.
O sincronismo pode ser estabelecido de duas maneiras:
ou através da determinação de tempos adequados de duração da
atividade, ou através da definição de eventos do tipo temporal ou
condicional que provoquem um sincronismo.
 Assíncrona
Quando as atividades são ordenadas em paralela ou
sequencialmente, porém sem nenhuma relação de dependência do
tipo “finish to finish” ou “start to start”, ou “finish to start”.
Aplicação da Junção ou Desvio

83
Estabelecem conexões múltiplas ou desvios entre

atividades de um processo, podem ser do tipo:
Determina um desvio no fluxo do processo e depende de

uma condição preestabelecida em forma de regra de negócio ou de uma
característica do data group produzido pela atividade imediatamente
anterior à junção. Determina uma ou um conjunto de derivações
obrigatórias (multiplicação) no fluxo do processo a partir daquele ponto
de junção.
Determina uma ou um conjunto de derivações

obrigatórias (multiplicação) no fluxo do processo a partir daquele ponto
de junção.
84
Princípios de Otimização e Refinamento

Otimizar processos de negócio é uma tarefa que, como
vimos no início do Capítulo 1, objetiva conduzir o ambiente
empresarial à excelência. A excelência implica na otimização dos níveis
das características:
1. Assertividade
2. Eficiência
3. Segurança e Risco
4. Flexibilidade
5. Repetitividade
6. Escalabilidade e portabilidade
7. Controlabilidade
Uma abordagem focada na otimização das sete

dimensões: relações com mercado, atividade, informação, regras de
negócio, tecnologia de informação, recursos humanos e meio ambiente,
é o caminho para excelência da arquitetura do processo. A tarefa de
otimização se constitui na avaliação da arquitetura de combinação das
dimensões e da própria configuração de cada uma.
A Eficiência é a resultante da otimização da arquitetura
maximizando o rendimento dos ativos físicos: Recursos Humanos, TI e
Meio Ambiente, através da redução dos ciclos de tempo e adequação do
nível de qualidade e controle à natureza do processo.
85
A Assertividade é a resultante da compreensão dos

requerimentos de arquitetura do processo orientados pela ótica da
expectativa de produto do Stakeholder, em termos de: valor, prazo,
nível de qualidade, liberdade de configuração e escolha e acessibilidade.
Assertividade - Atendimento às demandas do Stakeholder

 Avaliar todas as variações de relações com os stakeholders do
processo a fim de decidir quais são mandatórias para resposta
planejada e quais devem ser consideradas, adicionalmente, para
uma resposta planejada;
 Reavaliar as expectativas do produto do processo sob a ótica do
stakeholder;
 Avaliar as expectativas do nível de qualidade e prazos
adequados para satisfazer o stakeholder;
 Avaliar a possibilidade de disponibilizar recursos para a
iteratividade direta do stakeholder com o processo.
Eficiência
 Procurar manter somente ações e processos essenciais, que
agregam valor ao negócio e que sejam mandatórios sob a ótica
de regularidade (compliance);
 Eliminar as ações de conferência;
 Eliminar ações duplicadas e redundantes;
 Aplicar, quando possível, o conceito Rede Pert - CPM a fim de
balancear a operação do processo;
 Eliminar os processos e ações gargalo;
 Combinar ações dependentes;
 Sempre que possível, utilizar o paralelismo na ordenação das
ações;
 Eliminar os intervalos de tempo inativo entre as ações.
 Separar, da cadeia principal de atividade, as atividades de
finalidade Custodial;
 Avaliar a adequação do modelo “físico” de organização do
processo;
 Eliminar sobre - produção;
86
 Eliminar tempo de espera;

 Otimizar a movimentação e transporte;
 Eliminar as perdas de processamento;
 Eliminar a movimentação de pessoas para obter recursos ou
informação necessários à execução das atividades;
 Eliminar os defeitos de produtos, retrabalho.
Segurança e Risco
 Reduzir as ações de controle aos níveis adequados à natureza do
processo;
 Estabelecer atividades de controle em pontos coerentes na
arquitetura de acordo com a natureza do processo;
 Estabelecer a matriz de responsabilidades;
 Prever rastreabilidade de processamento.
Flexibilidade (Adaptabilidade)
 Transformar variáveis de processamento em parâmetros para
regras de negócio estruturadas;
 Prever na arquitetura do processo as variâncias de
processamento para o volume predominante;
 Transformar regras de negócio custodiadas pela equipe de TI,
em regras de negócio parametrizadas mantidas pelos gestores;
 Para processos ad hoc, prever a configuração dinâmica da
arquitetura a cada processamento.
Repetitividade
 Definir e especificar todas as dimensões de forma que sejam
claras e completas, base do conhecimento de um modelo de
repetição;
 Considerar as exceções mais frequentes e/ou relevantes na
arquitetura do processo, de forma que elas também possam ser
processadas de maneira repetitiva e não ad hoc;
 Manter os envolvidos capacitados sobre a arquitetura do
processo de forma transparente e constante.
Escalabilidade & Portabilidade
87
 Considerar a evolução do cenário de volume de processamento

na configuração da solução arquitetônica;
 Considerar os cenários previsíveis para migração de local de
processamento na concepção da solução da arquitetura do
processo.
Controlabilidade
 Definir com clareza a responsabilidade de gestão sobre o
processo;
 Orientar o planejamento orçamentário aos processos de negócio;
 Definir indicadores táticos para os processos com base no
desdobramento dos indicadores estratégicos;
 Estabelecer indicadores para monitoramento em tempo real para
processos críticos;
 Estabelecer um modelo de ações (corretivas, remediadores,
reparadora) para arquitetura do processo com base nos desvios
dos indicadores.
Capítulo 04
RELAÇÕES COM O MERCADO
88
Índice do Capítulo:
 Introdução
 Conceito
 Os Tipos de Evento de Negócio
 Encontrando os Eventos de Negócio (relações com o mercado)
 Princípios de refinamento e Otimização
O Conceito de Evento de Negócio

O Conceito que utilizamos para compreender as
Relações com o Mercado foi emprestado da técnica de Análise &
Projeto de Sistemas Aplicativos chamada Essential Analisys, em
português análise essencial. A Análise Essencial foi proposta, pelos srs.
Palmer & McMenamim em 1984, como uma evolução da tradicional
Análise Estruturada.
A Análise Essencial propõe a compreensão de um
sistema aplicativo através dos eventos para os quais o sistema deve ter a
capacidade de responder com eficácia. Desta forma, um sistema é
constituído por um conjunto de respostas predeterminadas a estímulos.
O conceito básico inclui a análise de eventos, estímulos, ações,
produtos, destinos dos produtos.
Desta forma, compreendemos a empresa como um
sistema, um conjunto de processos de negócio inter-relacionados, que
têm o objetivo primário de responder direta ou indiretamente aos
estímulos da entidade externa “Cliente”. Como decorrência dessas
respostas primárias, são geradas outras relações com diversas entidades
externas, as quais existem para suportar e controlar essas respostas
primárias.
No contexto empresarial as Respostas Planejadas são
processos de negócio, e uma empresa é composta por uma rede de
processos de negócio interligados e interdependentes. A compreensão
das relações com o mercado é o ponto de partida para a compreensão da
arquitetura de negócio de uma empresa, pois determina para quais
relações a empresa necessita se organizar para produzir uma resposta
planejada, seja ela completamente estruturada ao não.
89
Imaginar uma empresa eficaz é ter a capacidade de

reconhecer todas as relações mandatórias para o negócio e estruturar
respostas planejadas quando for possível e prever respostas não
estruturadas ou semiestruturadas para quando não for possível estruturá-
las. Cada resposta planejada é um processo de negócio, e neles,
engenhamos todos os ativos necessários para a geração do “produto” da
resposta que satisfaça à expectativa do “cliente” do processo.
Através do BPM-M, essas relações com o mercado são
percebidas em forma de “Eventos de Negócio”. Um evento de negócio
é um acontecimento que ocorre no ambiente externo à operação em
foco, e que é reconhecido como um “gatilho” para a reação planejada.
Definição Fundamental
“Evento de Negócio é um acontecimento referente à ação
de alguém, à passagem do tempo ou ao atendimento de determinada
condição. São acontecimentos sobre os quais não se tem controle, e
somente pode-se estabelecer um padrão de identificação e
reconhecimento, para serem reconhecidos quando ocorrerem. Eventos
são instantâneos, espontâneos e não consomem tempo.”
Os Tipos de Eventos de Negócio
 Normal
É um acontecimento referente à ação de alguém que está fora
do contexto da operação em foco. Sua ocorrência não tem um ciclo de
tempo previsível. Reconhecer eventos normais é, basicamente,
identificar acontecimentos gerados por entidades externas, que
interagem com a empresa estimulando sua resposta.
Eventos normais devem ser descritos com uma frase composta
por: Sujeito, Verbo e Objeto.
90
 Temporal
É um acontecimento referente à passagem do tempo, ou
ao atendimento de uma determinada condição de ciclo de tempo.
Reconhecer eventos temporais é, basicamente, identificar
os ciclos de tempo que disparam um processo ou um trecho específico
de sua cadeia de atividades procedurais
Todo evento do tipo temporal exige a determinação do
valor do ciclo de tempo no formato de “duração do ciclo” (mensal,
diário, anual, etc.) ou no formato de “coordenada temporal” (hora/dia/
mês, etc.).
Exemplo:
Ciclo de tempo = Mensal
Coordenada temporal = dia primeiro às 12:30 h
Eventos temporais devem ser descritos com uma frase

composta por: É hora de, Verbo e Objeto.
 Condicional
É um acontecimento referente à satisfação de uma
condição preestabelecida para um dado objeto. Reconhecer eventos
condicionais é, basicamente, identificar condições sob as quais uma
operação ou um trecho específico de sua cadeia de atividades
procedurais deve ser disparada. Todo evento do tipo condicional exige a
determinação de um objeto ou atributo e do seu respectivo valor a ser
considerado como condição a ser satisfeita.
Exemplo:
Objeto = Meio ambiente
Atributo = temperatura nível crítico
91
Valor da condição = 40ºC
Eventos condicionais devem ser descritos com uma frase

composta por: Objeto ou seu Atributo, Verbo, Condição.
Encontrando os Eventos de Negócio (as relações com o mercado)

Um evento de negócio é um acontecimento que ocorre
fora dos limites da operação em foco e que provoca uma resposta
planejada desta operação. Portanto partindo da compreensão do
“Objetivo de Negócio (empresa)” quando o ponto de partida da Enga.
for o Ideal ou do “Objetivo da Área de Interesse” quando o ponto de
partida for o prático devemos:
Identificar os Eventos Normais

Identificar todo acontecimento que a princípio deva ser
reconhecido como uma “demanda” a ser satisfeita ou uma “entrega”
a ser processada oriundas de entidades externas à operação.
Para cada evento identificado aplicamos o questionário
abaixo com o objetivo de identificar novos eventos correlacionados aos
principais. Para cada um dos novos eventos identificados aplicamos
repetidamente e recursivamente o mesmo questionário:
 Existe algum evento que seja uma variação significativa do
evento identificado. Normalmente esses eventos podem ser
escritos com as mesmas palavras do evento original, trocando-se
apenas o Verbo;
 Existe algum evento oposto ao evento identificado. Exemplo:
Pagar / Receber;
 Existe algum evento negativo em relação ao evento
identificado. Consiste na negação do evento: aprovar / reprovar;
pagar/não pagar;
92
 Existe algum evento que deve preceder ao evento identificado.

Normalmente esses eventos são pré-requisitos do evento em
questão. Exemplo: para que um pagamento seja realizado é
necessária a realização anterior de uma compra;
 Existe algum evento que seja consequência ou sucessão do
evento identificado. Estes eventos, normalmente devem
acontecer após o evento original;
 Existe algum evento que represente a antecipação ou
retardamento em relação a um evento identificado.
Nota: Nas operações de retaguarda administrativa os
eventos derivados normalmente são referentes a alteração,
cancelamento, antecipação, atraso, negação, etc.
Identificar os Eventos Temporais

 Identificar todo acontecimento que a princípio deva ser
reconhecido como um “Ciclo” de tempo que dispare um trecho
de uma cadeia de atividades da operação com o objetivo de
processar um “lote” de itens (processamento batch). Exemplo:
É hora de aprovar solicitações de crédito do período;
reconhecido como um “Ciclo” de tempo que deva ser
reconhecido como necessário para o “estabelecimento de
sincronismo temporal” de processamento entre cadeias de
atividades independentes ou acontecimentos periódicos do
mundo exterior. Exemplo: É hora de fechar movimento do
período;
reconhecido como um “Ciclo” de tempo adequado para a
“representação de condições sazonais”. Exemplo: É hora de
avaliar satisfação de cliente”.
Identificar os Eventos Condicionais
Para cada evento identificado aplicamos o questionário
abaixo com o objetivo de identificar novos eventos correlacionados aos
principais. Para cada um dos novos eventos identificados aplicamos
repetidamente e recursivamente o mesmo questionário até termos
atingido a “estabilização” da lista de eventos correlatos.
93

reconhecido como uma “condição” que pode ser atingida e que
demande um processamento;
 Existe algum evento que represente uma variação significativa
do evento identificado. Normalmente esses eventos podem ser
escritos com as mesmas palavras do evento original, trocando-se
apenas a condição ou o valor da condição preestabelecido.
 Existe algum evento oposto ao evento identificado;
 Existe algum evento que represente uma condição negativa em
relação ao evento identificado. Consiste na negação do evento:
atinge/não atinge;
 Existe algum evento que represente uma condição consequente
do evento identificado;
 Existe algum evento que represente uma condição antecipada
ou retardada em relação a um evento identificado.
Exemplo: Temperatura ambiente atinge nível crítico.

Surge necessidade de avaliação de mercado.
Descobrindo os Eventos Normais sob Ótica Especifica
Buscar compreender o comportamento do “cliente” -

Stakeholder é fundamental para a adequada concepção do modelo de
operação negócio. As operações chamadas de “Front Office” são
geralmente responsáveis pela interação da empresa com essas entidades
externas e é, principalmente, através destas operações que as entidades
“percebem” a “qualidade” dos serviços da empresa. Portanto, descobrir
relações relevantes com as entidades é compreender as expectativas
destas entidades em relação às respostas da empresa e decidir sobre
quais expectativas serão atendidas com modelos de respostas
planejadas.
É Claro que a compreensão destas relações pressupõe a
definição e conhecimento dos objetivos do negócio em questão.
Esta cadeia de ações, do nosso ponto de vista
“EVENTOS”, é uma forma de análise das possibilidades de
comportamento destas entidades e nos permite construir um “mapa” de
eventos representando esta possível linha de comportamento. Este mapa
94
possibilita a realização de uma análise e ponderação sobre quais destas

ações “EVENTOS” são relevantes para o negócio a ponto de serem
considerados com EVENTOS A SEREM RESPONDIDOS POR
OPERAÇÕES DE NEGÓCIO.
São esses os eventos que estimularão operações
especificas a serem alvo de engenharia operacional. Desta mesma
análise podemos conhecer a “predecessão” das operações, visto que os
eventos que as disparam também são predecessores.
Localizando-os no Tempo (Predecessão)

Eventos podem ser encontrados analisando-se a cadeia
de ações sequenciais que podem ser realizadas pelas entidades externas
num determinado contexto de negócio.
Exemplo:
O Primeiro passo é identificar o evento mais cedo

possível a ser detectado e que tenha uma correlação com o domínio do
negócio. E o último passo é identificar o evento mais tardio possível.
Entre os dois eventos encontraremos todos aqueles referentes ao
“desenrolar’ das relações com a entidade externa – stakeholder.
Eventos Derivados (variantes)

São derivados dos primeiros eventos sequenciais
(primordiais) encontrados. Podem ser referentes à variação, negação,
alteração, cancelamento, atraso, oposição ou tipificação.
95
Os Atributos do Evento de Negócio

Na especificação da Evento de Negócio estabelecemos um conjunto de
informações essenciais sobre sua compreensão. Estas informações são:
 ID da Evento de negócio;
 Título da Evento de negócio;
 Tipo de Evento de negócio (normal, temporal, condicional);
 Entidade Externa envolvida quando do tipo normal);
 Descrição explicativa suplementar (quando do tipo normal);
 Ciclo de disparo (quando do tipo temporal);
 Coordenada temporal (quando do tipo temporal);
 Descrição da condição de disparo (quando do tipo condicional).
Princípios de Refinamento e Otimização (Avaliando os Problemas

nas Relações com o Mercado)
 Analisando os Possíveis Problemas referentes às Relações não

Reconhecidas (Eventos de Negócio Não Considerados na
Engenharia da Operação)
Podemos encontrar problemas decorrentes da resposta à

determinada classe de eventos de negócio (relações não reconhecidas).
96
A empresa neste caso pode não perceber os problemas

pois a resposta planejada simplesmente não existe como elemento a ser
observado. O problema somente pode ser percebido quando da
observação da questão do ponto de vista externo.
O que a entidade externa (agente do evento – sujeito)
pode estar fazendo em decorrência de não haver uma resposta
planejada para aquele tipo de evento (relação)?
Exemplo:
Evento Inexistente: Cliente solicita assistência técnica.
Possível Problema decorrente:
 Queda do nível de satisfação do cliente;
 Risco de difamação da empresa;
 Deficiência do processo de aperfeiçoamento do produto;
 Risco de queda de vendas.
 Analisando os Possíveis Problemas referentes às Relações

Reconhecidas (Eventos de Negócio Considerados na Engenharia
da Operação)
Podemos identificar os problemas através da observação

das respectivas operações em funcionamento. Porém ainda adotando o
ponto de vista da entidade externa e ponto de vista interno.
O que a entidade externa (agente do evento – sujeito)
percebe como problema no relacionamento específico e o que a
empresa reconhece como problema no mesmo relacionamento?
Exemplo:
Evento Existente: Cliente solicita assistência técnica.
Possível Problema Percebido:
 Ponto de Vista Cliente:
 Alto índice de solicitações não atendidas;
 “Má qualidade” do serviço da equipe de atendimento;
 Dificuldade em contatar o atendimento ao cliente;
 Ponto de Vista Empresa;
 Queda do nível de satisfação do cliente;
97
 Risco de difamação da empresa;

 Deficiência do processo de aperfeiçoamento do produto;
 Risco de queda de vendas.
Expectativas de Valor do Ponto de Vista do “Stakeholder”

O processo de análise de problemas nas relações com os
clientes (stakeholders), pressupõe o conhecimento das expectativas e
necessidades do cliente no processo em análise referentes ao produto
gerado por este processo. Para tanto adotamos o conceito de
stakeholder para nossa aplicação, definido como “Classe de Ator –
Entidade Externa” (ao processo). Segundo o padrão da Norma série ISO
9000 (ANSI/ISO/ASQC Q9000-1-1994), existem oito classes de
stakeholder.
Classe de Pessoa da Metaclasse Stakeholder

 Cliente
 Fornecedor Primário
 Colaborador (empregados)
 Credor
 Investidor
 Governo
 Comunidade
 Administrador
A seguir, estão relacionadas as expectativas sobre o

output dos processos segundo o ponto de vista de cada classe de ator.
Este conhecimento é a base para investigação dos
problemas no relacionamento com o mercado visto que são
considerados como problemas, do ponto de vista do “stakeholder”
todo o fato relacionado ao não atendimento e suas expectativas
primarias no tocante ao produto do processo!
Fornecedor Primário
Preço favorável;
Repetição de pedidos;
Pagamentos no prazo;
98
Conveniência de transação;
Comunicação aberta e honesta;
Rápida resolução de problemas;
Procedimento padrão.
Credor
Pagamento de empréstimos no prazo;
Reporte acurado e temporário;
Boa relação com empregados;
Administração competente.
Governo
Pronto pagamento de impostos e taxas;
Pronta emissão de relatórios;
Abertura para revisões e inspeções;
Conformidade c/ leis/regulamentações.
Cliente
Qualidade percebida;
Variedade de escolha;
Conveniência de transação;
Serviço amigável;
Pronta entrega;
Rápida resolução de problemas.
Empregado
Trabalho desafiador;
Segurança de emprego;
Progresso de carreira;
Salário competitivo e benefícios;
Ambiente de trabalho saudável;
Vida familiar/profissional balanceada.
99
Investidor
Administração excelente;
Valor de mercado aumentado;
Dividendos consistentes;
Reporte financeiro acurado;
Relatórios financeiros exatos;
Responsabilidade para questionar.
Comunidade
Aderir às leis e regulamentações;
Conduta de comunicação aberta e honesta;
Provisão de fundos para projetos comunitários;
Resposta pronta às questões comunitárias;
Ação rápida sobre os assuntos comunitários.
Administrador
Posição desafiadora;
Responsabilidade e autoridade (poder);
Recompensa por performance;
Oportunidades de avanço de carreira;
Salário competitivo e benefícios;
Comunicação aberta e honesta.
Essas expectativas são utilizadas no capítulo de métricas

para aferirmos o aspecto qualitativo da métrica operacional, tomando
como critério de benchmark o ponto de vista de cada classe de
“stakeholder”.
100
Capítulo 05
ANÁLISE DE PROBLEMA
Índice do Capítulo
 Análise de Problema
 Os princípios da Análise de Problemas
 Ponto de Vista
 As Fases da Análise de Problemas
 Os Atributos da Análise de Problemas
Problema
“É o aspecto percebido sempre que há uma situação insatisfatória, um
desvio de padrão de desempenho ou de objetivo estabelecido, e que se
reconheça a necessidade de corrigi-lo.”
Na Engenharia Operacional de Negócio a técnica de

análise de problema é utilizada como uma ferramenta para identificar
(descobrir) problemas operacionais uma vez que o ponto de partida para
o processo de melhoria depende da perfeita identificação dos aspectos
que impedem a harmonia do funcionamento das sete dimensões de uma
operação. Da forma oposta é a aplicação convencional da análise de
problema que parte do conhecimento de um dado problema para aí
então estudar sua cadeia de causa e efeito e associá-las a cada uma das
quatro dimensões originais do sr. Ishikawa.
Análise de Problema
A Análise de Problema representa uma “ferramenta”
fundamental para o processo de melhoria em qualquer contexto
empresarial. Especificamente para a Engenharia Operacional de
Negócio quando é um dos componentes chaves para o sucesso na
abordagem de operações existentes, considerando que a intervenção
pontual sobre operações correntes normalmente ocorre como resultante
da conscientização ou percepção do(s) gestor(es) da operação a
respeito do nível crítico dos problemas existentes, níveis esses críticos o
101
suficiente para comprometer o “bom funcionamento” de suas

operações. Esta percepção dos problemas, em nosso contexto,
especificamente problemas operacionais, está relacionada aos diversos
elementos (sete dimensões) que constituem a base do ambiente
operacional de qualquer negócio, e que se confundem numa relação de
causa-efeito aos olhos dos gestores e operadores.
Sendo assim, em nosso contexto, a Análise de Problemas
tem como objetivo básico estabelecer uma das balizas utilizadas para o
refinamento e/ou otimização da operação abordada. Isto se dá através
da:
 Identificação do conjunto de causas primordiais dos problemas;
 Identificação da verdadeira natureza dos problemas;
 Estabelecimento do plano de ações corretivas;
 Definição dos envolvidos e suas responsabilidades na
implementação das ações corretivas.
Os princípios da Análise de Problemas
 O Conceito de Causalidade (Relação Causa – Efeito)

O conceito da causalidade ou relação Causa – Efeito no contexto
operacional estabelece uma forma de compreensão das condições da
operação ao longo de duas “dimensões” - tempo e espaço:
No tempo No espaço
Passado Anterior
Presente Corrente
Futuro Posterior
Este conceito suporta a compreensão da “cadeia de

problemas” produzida pelas próprias disfunções da operação.
Desta forma o conjunto dos problemas percebidos a cada
“passo” o anterior (predecessor) ao passo observado formam sua
condição corrente, ou seja, os “problemas” do “passo” observado
gerarão os problemas dos “passos” posteriores (sucessores). Assim
podemos dizer que a condição de uma determinada operação não é
absoluta no tempo e espaço, pois além de suas próprias “disfunções”,
102
está sendo transformada pelos problemas dos passos anteriores de

acordo com o princípio de Causa – Efeito.
Passo a passo, numa operação, são produzidas novas
disfunções (Causas) a manifestarem-se nos próximos passos como
efeitos, e que representarão novas Causas para novos Efeitos nessa
cadeia operacional. Portanto podemos concluir que há uma
simultaneidade existencial entre causa e efeito. Ou seja, o efeito de uma
dada causa é simultaneamente a causa para um outro efeito.
Algumas relações entre Causa e Efeito são aparentes,
enquanto que outras são tão profundamente enraizadas no início das
cadeias operacionais ou nas bases conceituais da gestão dos negócios
que se tornam difíceis de serem percebidas.
Embora muitas operações sejam modeladas para
funcionar segundo seus próprios princípios e componentes, elas estão,
na realidade, “gozando” de liberdade relativa dentro das “balizas”
restritivas estabelecidas e/ou geradas pela disfunção de operações que
as precedem e/ou sucedem. Isso pode ser comparado ao “gado que se
move dentro da cerca, sem, contudo, poder escapar dela”. “Para
conhecer a causa do passado, entenda o efeito do presente. Para
conhecer o efeito no futuro, entenda a causa no presente”.
Embora o conceito da relação de Causa – Efeito
esteja sendo aqui utilizado para a compreensão dos problemas
manifestados dentro das operações, o mesmo princípio serve para
explanar o funcionamento harmônico e excelente de operações
precedidas por outras adequadamente engenhadas.
 A Causa
É a razão geradora dos problemas observados. Para um
dado problema podemos encontrar um conjunto de causas. Porém
através de um processo “investigativo” podemos encontrar a causa
“primordial”, que pode ser encontrada “fora” do contexto da operação
abordada, onde talvez não possamos agir ou interferir, o que nos
obrigará a ajustar (reduzir) a “amplitude” da análise investigativa para
encontrar a primeira causa dentro do contexto operacional abordado. A
causa constitui a razão existencial dos problemas observados, e deve ser
o alvo das ações corretivas a serem estabelecidas.
103
 O Efeito
Normalmente é percebido como o Problema pelas
pessoas afetadas. Um efeito está diretamente associado a uma ou a um
conjunto de causas e podem ser mensuráveis ou imensuráveis. Para os
leigos os efeitos constituem exclusivamente o problema, e como tal são
erroneamente tratados não promovendo soluções eficazes. Os efeitos
são o ponto de partida do processo investigativo da Análise de
Problemas.
Portanto, à luz da análise de problemas e do princípio da
Causalidade, os problemas operacionais percebidos num determinado
“ponto” do tempo e espaço da operação são a resultantes da totalidade
das “disfunções” (causas) existentes nos “pontos” anteriores da
operação.
 A Ação Corretiva
As ações corretivas constituem o objetivo final da análise
de problemas, ou seja, uma vez conhecidos os problemas e suas causas
nos tornamos aptos a definir quais ações devem ser realizadas para
“sanar”, “eliminar” ou minimizar os problemas observados. As ações
corretivas devem visar atingir a Causa dos problemas e não seu efeito
observado. As ações corretivas devem estar diretamente associadas às
dimensões abordadas pela Engenharia Operacional de Negócio. A
especificação de uma ação corretiva deve, preferencialmente, ser feita
de forma que as informações ali contidas sejam suficientes –
necessárias para a compreensão exata do que fazer.
 Ação Remediadora:
As ações remediadoras constituem as ações que visam
tratar as causas dos problemas de forma provisória até que se possa
efetivamente eliminar ou “mitigar” as causas de forma definitiva. A
especificação de uma ação remediadora deve, preferencialmente, ser
feita de forma que as informações ali contidas sejam suficientes –
necessárias para a compreensão exata do que fazer.
 A Ação Reparadora:
104
As ações reparadoras constituem as ações a serem

realizadas sobre os efeitos passados gerados, que ainda possuem
“resíduos” não tratados. A especificação de uma ação reparadora deve,
preferencialmente, ser feita de forma que as informações ali contidas
sejam suficientes – necessárias para a compreensão exata do que fazer.
 A Natureza Multidimensional
Este conceito estabelece que cada Causa e Ação
Corretiva são diretamente associadas a uma das sete dimensões
abordadas pela Engenharia Operacional de Negócio. Estas dimensões
são: Atividade, Informação, Regra de Negócio, Recurso Humano,
Tecnologia de Informação, Relações de Mercado e Meio Ambiente.
Desta forma toda Causa e Ação Corretiva são
compreendidas através do Elemento sob o qual ela se manifesta ou se
manifestou. Isto nos possibilita estabelecer um plano de ações precisa e
multidimensional para as soluções dos problemas de essência
operacional.
 Ponto de Vista
Para a observação dos problemas operacionais é
necessário adotar diferentes pontos de vista a fim de perceber a
manifestação de problemas perceptíveis a partir de cada ponto de vista.
 O observador como Operador:

Operador se refere efetivamente as Classes de Pessoas
que estão envolvidas com a execução das atividades contidas na
operação observada extrapola os limites da operação observada, bem
como para encontrar problemas afetos as disfunções.
 O Observador como o “especialista” da Operação:

O “especialista” da operação representa a classe de
pessoa responsável pela execução e comando da operação propriamente
dita. Normalmente é um especialista, líder, coordenador, supervisor ou
especialista que tem a visão prática, ampla e completa da arquitetura do
processo. O especialista tem, normalmente, uma visão restrita ao
“trecho” do processo que “passa” por sua unidade organizacional
105
(departamento, divisão, seção, etc.). Um processo pode ter identificado

mais que um especialista, um ou mais para cada unidade organizacional
por onde “passa”.
 O Observador como o “Stakeholder” da Operação:
O “stakeholder” da operação representa as classes de
pessoas para as quais a referida operação existe, ou seja, são aqueles
normalmente denominados de “clientes” da operação embora não sejam
eles necessariamente Clientes do negócio.
 O Observador como o Engenheiro da Operação:

Como “Engenheiro da Operação” nos referimos à Classe
de Pessoas que são diretamente responsáveis pela concepção ou
especificação de arquitetura da operação abordada, portanto
conhecedores dos “detalhes” operacionais do negócio. Por outro lado,
as pessoas desta classe não possuem uma visão ampla da operação o
suficiente para permitir a compreensão de toda a cadeira de causa-
efeito.
 O Observador como Gestor da Operação:

Como gestor entendemos a Classe de Pessoas
responsável pela Gestão da operação observada. O ponto de vista de
Gestor da Operação é importante para a compreensão ampla da relação
de causa-efeito mesmo quando ela.
Análise de Risco Operacional (Classificação dos Aspectos Críticos)

Podemos realizar uma classificação dos aspectos críticos
encontrados considerando três formas de considerá-los a fim de avaliar
sua relevância para a construção de plano de ação corretiva e orientar
sua priorização. Apesar de ser uma análise e classificação subjetiva,
pode auxiliar muito na priorização do plano de ações corretivas visto
que podem haver centenas de ações corretivas mapeadas ao longo da
análise de problema em conformidade com o tamanho e o estado de
criticidade da operação em estudo.
Impacto
106
Objetiva classificar os aspectos críticos encontrados

quanto a seu impacto negativo sobre as características de performance
(eficiência, eficácia, segurança, flexibilidade, controlabilidade,
continuidade) da operação na qual é manifestado. Também podemos
valorá-los como:
● Nenhum:
Não provoca nenhum efeito perceptível sobre as
características de performance da operação;
● Leve:
Provoca um baixo impacto sobre as características de
performance da operação;
● Moderado:
Provoca um impacto moderado sobre as características
de eficiência, eficácia da operação;
● Severo:
Provoca um impacto severo sobre as características de
eficiência (perda de recursos), eficácia (quebra da qualidade e satisfação
percebida pelo cliente), segurança, flexibilidade da operação;
● Catastrófico
Provoca um impacto catastrófico sobre as características
de continuidade (interrupção de operação), eficácia (quebra da
qualidade e satisfação percebida pelo cliente).
Probabilidade
Objetiva classificar os aspectos críticos encontrados
quanto a probabilidade de sua ocorrência na operação. Também
podemos valorá-los como:
● 12% (muito baixa)
● 25% (baixa)
● 50% (média)
● 75% (alta)
● 100% (ABSOLUTA)
Complexidade
107
Objetiva classificar as ações corretivas definidas no

plano de ações corretivas segunda sua complexidade de “construção” e
implementação. Também podemos valorá-los como:
● 12% (muito baixa)
● 25% (baixa)
● 50% (média)
● 75% (alta)
● 100% (ALTISSIMA)
Matriz de vulnerabilidade
Esta classificação combina as possibilidades de
IMPACTO e PROBABILIDADE e demonstra quão vulnerável ao
problema está a operação em questão numa escala de 1 a 4.
108
Capítulo 06
REGRA DE NEGÓCIO
Conceito
Podemos conceituar como regra de negócio toda
definição conceitual que oriente ou determine executar uma atividade,
em um determinado contexto de negócio, seja esta de qual natureza for.
COMO
Especificação de um determinado método
estruturado e lógico que estabeleça como realizar: Um cálculo, uma
comparação, uma avaliação ou valorização, uma classificação, uma
consistência restritiva ou condicional.
Regras de negócio devem ser especificadas de forma
isolada da ATIVIDADE “o que fazer” a fim de flexibilizar a
arquitetura operacional. Assim é possível ajustar ou substituir regras de
negócio sem alterar o script de atividades gerando um impacto restrito
no modelo operacional.
Isto significa que identificar “métodos” que devem ser
considerados como regras de negócio é a base para flexibilização e
parametrização do modelo operacional.
109
Nominação da Regra de Negócio

As Regras de negócio devem ser tituladas de forma que
o título transmita seu objetivo básico. Deve ser titulada de forma
sucinta, através do emprego de um classificador da espécie da regra
(método, critério, tabela, formula, condição) associado a um Objetivo.
Exemplo:
Tipos de Regra
Para efeito de análise, dividiremos as regras de negócio
em dois grupos, a saber:
 Regras Orientativas
São diretrizes, regras que orientam quanto aos princípios
a serem observados na execução de uma determinada atividade. Não
são precisas e necessitam ser interpretadas a cada situação de aplicação,
necessariamente por pessoas.
No ambiente empresarial poderemos encontrar situações
onde não será possível definir uma regra de negócio determinística, seja
por motivos conjunturais (poder e autoridade) ou pela própria natureza
do negócio.
Um exemplo típico, embora fora do contexto
empresarial, de uma regra de negócio orientativa, é a constituição
inglesa. Outro exemplo típico é o conjunto de normas da série ISO
9000, sobre qualidade de processo, que orientam sobre os princípios na
qualidade, mas não determinam como o modelo é para cada caso.
Apesar de podermos imaginar que determinado conjunto
de pesquisas de mercado fossem requeridos, ainda assim a análise
110
conclusiva do quadro econômico-social e mercadológico onde atuaria o

novo negócio, dependeria da avaliação humana.
A regra de negócio, neste caso, deveria orientar o
“analista” de crédito, sobre os aspectos a serem observados e
considerados no quadro de análise, porém, não seria possível definir
uma regra precisa e determinística a ponto de cobrir todas as
possibilidades.
 Regras Determinísticas
São regras que determinam critérios, variáveis, e
parâmetros precisos e valorados a serem considerados na sua aplicação.
Este tipo de regra dispensa a interpretação humana. São especificadas
de modo a serem aplicadas “automaticamente”, pois consideram todas
as situações possíveis e a correspondente reação. No ambiente
empresarial encontraremos, predominantemente, situações onde será
possível definir regras de negócio determinísticas, pois os métodos são
normalmente precisos.
Deve-se primar por transformar as regras orientativas em
regras determinísticas, pois isso propicia a aplicação de tecnologia de
informação. Podemos encontrar vários exemplos de regras de negócio
determinísticas no ambiente empresarial, algumas classes são as mais
conhecidas, tais como: regras de cálculo, tabelas e árvores de decisão,
limites de alçada, etc. Um exemplo típico é a regra de abatimento de
dependentes no cálculo de imposto de renda de pessoa física.
Implementação e Aplicação
As regras de negócio podem ser implementadas, ou seja,
aplicadas aos processos de negócio de três formas:
 Aplicadas por pessoas e implementadas por documentação;
 Aplicadas por TI e implementadas no código dos sistemas de
informação;
 Aplicadas por TI e implementadas no banco de dados.
A especificação das regras de negócio deve ser elaborada
considerando-se uma máxima de Napoleão Bonaparte:
111
 Aplicada por Pessoas & Implementada por Documentação

Normalmente é utilizada para regras de negócio do tipo
orientativas, as quais exigem interpretação humana. Quando o ambiente
empresarial em questão não possuir um grau relativo de aplicação de
tecnologia de informação, pode-se encontrar ou necessitar definir regras
do tipo determinísticas, também desta forma.
Exemplo:
Política de compensação serviços
Objetivo:
Orientar quanto às formas de compensação a Clientes anunciantes em
casos de:
»Anúncios vendidos pagos e/ou em cobrança e não veiculados;

»Falhas e/ou erros, de responsabilidade da Abril S/A, nos anúncios
veiculados;
Descrição:
A compensação deve ser feita, preferencialmente, sem a devolução dos
valores pagos pelo Cliente. Em ordem de prioridade a compensação
deve ser negociada visando às opções:
1. Conceder o direito de anúncios futuros, com valor proporcional
àquele anúncio causa da compensação;
2. Estorno do valor na conta de controle de pagamentos
antecipados;
3. Prorrogar o prazo de pagamento do valor cobrado do Cliente;
4. Conceder um abatimento sobre o valor cobrado do Cliente;
5. Suspender a cobrança do pagamento do Cliente;
6. Reembolsar o valor pago pelo Cliente.
A adoção das opções 5. e 6. Devem ser aprovadas pela
Gerência de Vendas de Classificados.
Dados da Cli_ID
Especificação: Anuncio_ID
Anuncio_valor
112
Anuncio_parc_pagto_data
Anuncio_parc_pagto_valor
Forma da Manual
Aplicação:
Atividade onde é 06.11 -Informar cliente sobre
aplicada: anúncio não veiculado
09.03 -Definir ação a tomar
 Aplicada através da TI
Deve-se ponderar sobre o efeito do alto nível de
automaticidade de aplicação das regras, pois dependendo do contexto
de negócio, este efeito pode ser inadequado devido a sua
impessoalidade, que pode ao longo do tempo, se não monitorado,
tornar-se uma ferramenta de “engessamento” do processo de negócio.
 Aplicada através da TI & Implementada no Código do
Sistema Aplicativo
Esta forma de implementação é necessariamente
referente às regras de negócio do tipo determinísticas, e como tal, é de
aplicação totalmente automatizável.
A regra é implementada no código do sistema de

informação a fim de permitir que este a aplique através do tratamento
dos valores dos parâmetros, e valores informados pelas pessoas.
Esta forma de implementação de regra de negócio sugere
a aplicação do conceito de “Objeto de Controle” da OOSE, a fim de
113
isolar em um código (programa) a lógica correspondente à uma

determinada regra de negócio, otimizando assim, a sua manutenção e
reaproveitamento.
Exemplo 1: Cálculo do excesso individual máximo

Objetivo:
Determinar as condições sob as quais uma venda ou um Cliente deve
ser submetido à avaliação de crédito da Dir. de Classificados.
Descrição:
SE Retirada_de_administrador.qualificação = “conselheiro fiscal”
@limite_individual_máximo:= 0,10 * (valor_ufir * 900 * 15)
SE_NAO
@limite_individual_máximo:= (valor_ufir *900 * 15)
F_SE
@valor_excesso_limite_individual_maximo : @pp –
@limite_individual_maximo
SE @valor_excesso_limite_individual_maximo < “0”
@valor_excesso_limite_individual_maximo = “0”
F_SE
Exemplo 2: Política avaliação de crédito

Objetivo:
Determinar as condições sob as quais uma venda ou um Cliente deve
ser submetido à avaliação de crédito da Dir. de Classificados.
Descrição:
São submetidos à avaliação de crédito os Clientes que se enquadrarem,
no momento do processamento da venda, em uma das seguintes
condições:
1) Ser um Cliente que está realizando a compra de anúncios de
classificados pela primeira vez;
2) Estar sem realizar compras de anúncios de classificados há mais de
três (3) meses consecutivos;
3) Estar com a situação de crédito, igual a bloqueado;
4) Estar com o valor acumulado de compras não pagas acima do
Limite de valor acumulado de compra.
114
O Limite de valor acumulado de compra determina o

valor máximo de crédito acumulado de vendas para cada cliente. Venda
a Crédito: são as vendas com pagamentos parcelados diretamente pela
própria Abril S.A.
O limite máximo de crédito de vendas corresponde ao
valor total acumulado de vendas a crédito não quitadas. A cada venda a
crédito realizada para um Cliente deve ser atualizado o valor acumulado
de compras a crédito, e cada pagamento realizado deve ser atualizado o
mesmo valor através da subtração do valor pago.
Dados da Especificação: -
Forma da Aplicação: Tecnologia de Informação
Atividade onde é 03.00 - Solicitar venda de anúncio
aplicada: 03.07 - Registrar Venda
03.12 - Recepcionar chamado direto
03.14 - Confirmar anúncios
programados
 Aplicada através da TI & Implementada no Banco de Dados

Esta forma de implementação é necessariamente
referente às regras de negócio do tipo determinísticas, e como tal, é
também, de aplicação totalmente automatizável.
Estas regras, especificamente, são referentes aos
relacionamentos entre os Objetos de Negócio e suas “partes”. No
modelo de objetos de negócio, e no modelo de dados, essas regras de
negócio se manifestam em forma de:
Cardinalidade:
Determina, em um relacionamento, a quantidade máxima
de instâncias de uma entidade que podem estar associadas a cada
instância da outra entidade relacionada. Podem ser:
Uma(1) para Muitos(N)
Uma(1) para Uma(1)
Muitos(N) para Muitos(N)
115
Totalidade:
Determina, em um relacionamento, a quantidade mínima
de instâncias de uma entidade que podem estar associadas com cada
instância da outra entidade relacionada.
Os valores possíveis são: 0 (parcial) e 1 (total).
Restrição de Relacionamento (Constraint):

Determina quais as restrições a serem consideradas em
um relacionamento entre instâncias de entidades.
As restrições podem ser referentes a condições a serem
observadas tanto na criação, como na alteração e eliminação de
relacionamentos.
A restrição pode se referir a valores de atributos das
entidades, como à situação de outros relacionamentos existentes com a
mesma entidade.
A Descrição da Regra de Negócio

Descrição de regras de negócio são scripts para COMO
estabelecer o valor de alguma coisa que está sendo processada na
atividade, portanto devem ser adequados para interpretação por parte de
pessoas. Napoleão Bonaparte dizia sobre a qualidade das mensagens:
“Uma mensagem deve ser clara, objetiva em completa”
A descrição de regra deve essencialmente se ater a

descrever como deve ser realizada uma atividade por uma determinada
classe de ator ou pela máquina.
Sua estrutura deve considerar a escolha mais adequada
de verbos, adjetivos, objetos, e palavras reservadas (para descrever a
“lógica”).
Os objetos de negócio manipulados pela operação,
grupos de dados e/ou elementos de dados manipulados pela atividade
devem ser o centro da descrição de uma Regra de Negócio a qual
versará sobre como cálculos, comparações, avaliações ou valorizações,
classificações, consistências restritivas ou condicionais, aprovações ou
reprovações deve ser executada com esses objetos gramaticais.
116
Palavra Reservada
Tal formalismo pode ser definido utilizando conceitos e
termos próprios de cada ENGENHEIRO, porém, apresentaremos aqui
uma alternativa:
 Para definição de condições:
 Se;
 Se Não;
 Fim_Se;
 Entao;
 Para indicação de repetições:
 Para_Cada;
 Fim_Cada;
 Para definição de expressões e operadores;
 Comparação: < ; > ; := ; = ; #
 Operação: + ; - ; * ; / .
Os Elementos de dados da regra:

Como elementos de dados da regra de negócio são
declarados todos os dados utilizados pela “lógica” da especificação da
regra a fim de permitir sua análise como objetivo de considerá-los como
“parte” do modelo de informação a ser construído.
Princípios de Refinamento e Otimização:

● Isolar da descrição de atividades a parte do script que defina como
executá-la;
● Definir regras de negócio que orientem a decisão humana em
situações repetitivas;
● Especificar regras de negócio que traduzam em termos
interpretáveis, as regras de gestão do negócio;
● Definir, sempre que possível, regras de negócio estruturadas e
precisas, a fim de permitir a sua interpretação automática.
Os Atributos da regra de Negócio

 ID da regra de negócio;
117
 Tipo de regra de negócio;

 Título da regra de negócio;
 Forma de aplicação;
 Forma de implementação;
 Objetivo da regra de negócio;
 Descrição da regra de negócio;
 Elementos de dados utilizados na regra de negócio;
 Atividade onde é aplicada.
118
Capítulo 07
INFORMAÇÃO
A Arquitetura de informação, para EA e o BPM-M, é

composta por um conjunto de especificações referentes aos Objetos
(coisas), seus relacionamentos e características (atributos),
transformados/manipulados pelo processo de negócio.
Definir o modelo de informação para um determinado
contexto de negócio, consiste em conhecer os objetos de negócio
transformados/manipulados pelo Processo de Negócio e identificar os
atributos referentes a esses Objetos que são necessários para seu
processamento. Sob a ótica do BPM-M, processos de negócio existem
em função do processamento de Objetos. Processos de negócio
realizam, na essência, ações como criar, alterar, eliminar, associar,
movimentar, controlar e monitorar objetos de negócio.
Esses Objetos podem ser concretos ou abstratos e estão
diretamente correlacionados à atividade fim da empresa.
Os Objetos de Negócio processados podem ser
identificados e percebidos através de um alto nível de observação
quando definimos com clareza o objetivo do processo em termos de
ações que são realizadas com esse conjunto de Objetos. Por exemplo,
em um processo “Vender produtos” poderíamos definir,
resumidamente, seu objetivo como: Desenvolver e conquistar novos
“Clientes” e ofertar & vender “Produtos”.
Ainda percebendo a dimensão informação, à medida que
decompomos as atividades do processo em níveis de observação mais
detalhados, identificamos os Grupos de Dados e seus elementos de
dados. Os grupos de dados são, comumente falando, os documentos,
formulários, mensagens, arquivos, conversas, etc., que são capturas
(recebidos) ou produzidos pelas atividades do processo.
Eles contêm os Elementos de Dados que são as
características ou atributos dos objetos agrupados de forma adequada
para satisfazer à necessidade de input e output de cada atividade do
processo. A dimensão Informação é composta por 5 elementos inter-
relacionados:
● Objeto de negócio
119
● Grupo de dados (data group)

● Elemento de dados
● Entidades (tabelas)
● Atributos
A Percepção do Elemento Informação

A Percepção da dimensão informação deve iniciar com a
compreensão do Objetivo do Processo de Negócio, que deve ser
descrito referindo-se à manipulação de um conjunto de objetos de
negócio, de forma declaratória.
Objeto de Negócio
É o ponto de partida para compreensão da razão
existencial de uma operação de negócio que existe com o objetivo
básico de:
 Criar/eliminar instâncias de objetos;
 Alterar características dos objetos;
 Criar e eliminar associações entre objetos;
 Transformar o estado/condição dos objetos de negócio;
 Movimentar instâncias de objetos;
 Controlar ou monitorar o estado e o valor das características dos
objetos;
120
 Divulgar informações sobre objetos.
Compreendendo a relação entre um objeto de negócio e

“entidades”, sob a ótica da teoria dos conjuntos, um objeto de Negócio
é uma “coisa” do mundo real capaz de assumir um estado
(características/informação) e de sofrer, ou executar uma quantidade de
operações (comportamento/métodos) que afetam estes estados.
Um objeto de negócio pode conter inúmeras partes , em decorrência de

sua composição, de suas especializações, generalizações, e de sua
“tipificação”.
“Um objeto é caracterizado por um conjunto de operações e estados,

os quais refletem os efeitos dessas operações.”
Ivar Jacobson
“Um objeto é uma abstração que modela todo aspecto relevante de

uma Entidade singular conceitual, ou tangível, ou de qualquer “coisa”
de um domínio de aplicação ou contexto de solução. Um objeto é uma
das primeiras entidades em uma aplicação orientada a objeto,
tipicamente corresponde a um modelo de sistema, e consiste de um
conjunto de tipos de atributos relacionados, atributos, mensagens,
exceções, operações, e objetos componentes opcionais.”
Donald G. Firesmith
“Um objeto é uma coisa. É criado como uma instância de um tipo de

objeto. Cada objeto possui uma única identidade que é distinta, e
independente de qualquer de suas características. Cada objeto oferta
uma ou mais operações.”
OMG - Object Management Group
“De uma perspectiva de cognitiva humana, um objeto pode ser um dos

conceitos: Uma coisa tangível e/ou intangível, alguma coisa que pode
ser compreendida intelectualmente, alguma coisa em direção a qual o
pensamento ou ação é dirigida. Um objeto tem estado, comportamento
e identidade. A estrutura e comportamento de objetos similares é
121
definida em sua classe comum, o termo instância e objeto são

intercambiáveis.”
Grady Booch
“Objeto é uma abstração de qualquer coisa em um domínio de

problema, refletindo as capacidades do sistema manter informações
sobre ela, interagir com ela, ou ambos, uma encapsulação de atributos,
valores e seus serviços exclusivos. Seu sinônimo é instância.”
Peter Coad and Ed Yourdon
“Um objeto é uma coisa real ou abstrata, sobre a qual nós guardamos
dados e seus métodos que manipulam tais dados.”
James Martin and James Odell
“Um objeto é uma abstração de coisas do mundo real. Todas as coisas

em conjunto de instâncias tem as mesmas características, e todas as
instâncias são subordinadas e estão conforme o mesmo conjunto de
regras e políticas.”
Sally Shlaer and Stephen Mellor
Na engenharia da informação procuramos compreender o

mundo ou os problemas em termos de objetos e classes de objetos.
Muitas técnicas orientadas a objeto iniciam a modelagem a partir do
modelo de objetos, porém:
 O modelo de dados frequentemente já existe antes de
construirmos o modelo de objetos;
 Um bom modelo de objetos de negócio pode ser capaz de
nortear a construção de qualquer modelo de dados, e
frequentemente, um conjunto de características (elemento de
dados) de um objeto pode ser modelado como uma ou mais
tabelas, ou entidades num modelo de dados.
Descobrindo Objetos de Negócio

Na abordagem do BPM-M, a descoberta dos objetos de
negócio está restrita ao contexto do processo de negócio contexto da
engenharia. O texto da descrição da missão e objetivo do processo é a
122
matéria-prima básica para se iniciar a modelagem. A correta e completa

descrição da missão e objetivos do processo deve conter o conjunto de
Objetos manipulados pelo processo e tipos de “operações” realizadas
com eles.
● Análise Sintática
Neste método de descoberta, foca-se a análise em textos,
estruturados ou não, a fim de encontrar os objetos gramaticais,
primeiros candidatos a objeto de negócio.
● Análise Semântica
Neste método de descoberta, foca-se a análise no
significado das palavras, partes de palavras ou combinações de
palavras, a fim de encontrar os candidatos a objeto.
● Forma Combinada
A forma prática de descoberta combina as duas formas
acadêmicas. Tomamos como base a descrição do objetivo e do contexto
dos processos de negócio, aplicamos a análise sintática, e uma vez
encontrados os candidatos a Objeto de Negócio, estes são validados
como objetos à luz dos conceitos descritos neste capítulo através de
análise semântica.
Cuidado a tomar, Barreiras Semânticas

Limitações que surgem das palavras com as quais nos
comunicamos. Para os analistas, essas barreiras surgem a cada passo e,
por isso, é frequente que as interpretações não captem exatamente o que
o cliente queria dizer. As barreiras semânticas são extremamente
comuns nos países em que o povo é naturalmente purista quanto ao
vernáculo.
Ponto de Vista
Identificar os objetos de negócio de um determinado
contexto exige a adoção de um ponto de vista por parte do observador.
Dependendo do ponto de vista adotado, pode-se identificar conjuntos de
objetos de negócio diferentes, visto que mudam os interesses e as
interações observadas.
123
Exemplificando, tomando como contexto de

financiamento de bens, como no caso de estudo da ABC Crédito, sob o
ponto de vista da ABC Crédito (processadora do referido processo), não
há interesse sobre o objeto de negócio “produto”, pois o processo tem
por objetivo estabelecer apenas a relação entre cliente e financiamento.
Já sob o ponto de vista da ABC Mundial, também envolvida no
processo, o objeto “produto” é importante, porém, para outro processo,
o processo de venda da ABC Mundial. Já se adotarmos o ponto de vista
do cliente, o próprio objeto de negócio cliente não teria sentido,
somente o objeto de negócio “financiamento” interessaria.
Portanto, o ponto de vista a ser adotado, sempre como
regra, deve estar dentro do contexto do processo de negócio em questão,
ou seja, adote a posição dos processadores do processo em questão, e
dali identifique os objetos a serem manipulados pelo processo.
Modelar objetos de negócio é identificar o conjunto de “coisas”

concernentes ao objetivo do negócio da operação. Esses modelos
ultrapassam a fronteira dos processos de negócio,
porém, não a da empresa, e expressam as regras de alto nível da
empresa, ou seja, a natureza do seu negócio.
Nominação do Objeto de Negócio

A nominação ou titulação do Objeto de Negócio deve
considerar a utilização de palavras que não representem “ação -
verbos”, mas sim palavras que indiquem “substantivos” (coisas) do
mundo real (afetos à realidade do negócio) sejam eles substantivos
abstratos ou substantivos concretos. Exemplo: cliente, produto, viagem,
veículo, consumidor, loja, unidade organizacional, local, pessoa, etc.
Relações entre os Objetos
 Relações Estáticas
São as relações permanentes existentes por um longo
período (indeterminado ou ilimitado), e significa que um Objeto
conhece a existência de cada outro Objeto.
124
 Relações Dinâmicas
São relações conhecidas por objetos que se comunicam
e/ou se relacionam somente em determinados momentos e/ou
circunstâncias. Não possuem uma relação permanente, relacionam-se
somente quando necessitam trocar mensagens, prestar e/ou solicitar
serviços.
As relações entre os objetos também devem ser
representadas no modelo de Objetos de Negócio como uma “classe de
objetos”. Esta “classe de objetos” representa em muitas operações a sua
exata razão existencial.
Classes de Processamento de Objetos de Negócio

As classes dos Objetos de Negócio serão definidas de
acordo com dois critérios. São eles:
▪ Quantos processos transformam um objeto de negócio;
▪ Quantos processos consultam um objeto de negócio.
De acordo com estes dois critérios, teremos quatro
classes de objetos de negócio, descritos a seguir.
Múltiplos Processos Um Processo

Transforma Consultam Transforma Consulta
m m m
CLASSE X X
1
CLASSE X X
2
CLASSE X X
3
CLASSE X X
4
Este conceito objetiva identificar e classificar os objetos

de negócio e/ou entidades de um contexto a fim de estudar e definir a
forma de conduzir.
125
O Modelo de Objetos de Negócio
Construído em conjunto com a Modelagem de Processo

de Negócio, pois é percebido na camada do mundo real e é de
compreensão natural para os homens de negócio, representa os objetos
do mundo real e suas regras de relacionamento naturais ao contexto do
negócio.
A representação gráfica que utilizamos é a ER com a
notação de James Martin. A representação identifica cardinalidade e
totalidade no relacionamento entre os objetos de negócio, da mesma
forma que em um diagrama ER.
Conceitos da Modelagem de Objetos de Negócio

A tarefa de definir atributos para entidades e definir as
próprias entidades, consiste em associar os elementos de dados
manipulados nos processos de negócio (através dos grupos de dados)
aos seus respectivos objetos de negócio.
Então, após o que, aplicar os conceitos de orientação a
objeto e normalização de bancos de dados relacionais a fim de descobrir
a “anatomia interna” de cada objeto de negócio.
Esta tarefa resulta no modelo de entidade relacionamento
de cada objeto de negócio. Uma explosão de cada objeto de negócio do
modelo de objetos de negócio, concebido na modelagem de processo de
negócio.
126
 Decomposição (Agregação ou Consiste de)
Decomposição significa que um objeto pode ser

estruturado em partes (partições hierárquicas), e a razão para isto pode
depender de muitos fatores que implicam na forma de descrever um
objeto em detalhes, melhorando sua compreensão e obtendo partes
reutilizáveis.
No sentido oposto ao da decomposição, está a agregação,
que significa que objetos podem associar-se ou juntar-se, constituindo
um outro objeto, mesmo que este seja uma forma singular de
compreender uma entidade do mundo real. Ambos os conceitos
exprimem a mesma ideia de conjunto e subconjunto, porém, um
partindo do “pai” para encontrar os “filhos” e o outro partindo dos
“filhos” para encontrar o “pai”, sendo a diferença apenas no sentido de
observação.
 Classe e Instância
Uma classe representa um padrão abstrato comum a

diversos objetos, descreve como estes objetos são estruturados
internamente, definindo sua estrutura de comportamento
(operação/métodos) e de informação (atributos/características).
127
Uma instância é um objeto criado a partir de uma classe

de objetos. O estado corrente de uma instância de objeto é definido
pelas operações executadas na instância. Em um sistema orientado a
objeto, todo objeto pertence a uma classe, e tal objeto é denominado
instância. Frequentemente os termos classe e instância são utilizados
como sinônimos.
 Herança
Esse conceito se refere ao relacionamento de hierarquia

entre classes de objetos. É um relacionamento entre classes de objetos,
que permite a uma classe herdar a estrutura de comportamento e de
informação definidas em outra classe mais genérica superior a primeira,
sob uma visão de hierarquia. A classe mais genérica (pai) é denominada
de superclasse, e a classe mais específica (filho) é denominada de
subclasse. Esta relação é recursiva e teoricamente ilimitada.
 Generalização
Através da extração de características e/ou
comportamentos compartilháveis de uma classe, podemos atribuir estas
características a uma nova classe hierarquicamente superior.
Com a generalização podemos encontrar superclasses “ancestrais”

das classes iniciais.
128
 Especialização
A especialização é exatamente o oposto da
generalização, quando extraímos um conjunto de características e/ou
comportamentos de uma superclasse e atribuímos estas a subclasses
específicas tornando-as especialidades da superclasse.
 Múltipla Herança.
É a característica que permite a uma classe de objetos
poder possuir mais que uma classe ancestral direta, resultando na
herança das características e comportamentos de todas as suas classes
ancestrais.
Com a especialização podemos encontrar subclasses “descendentes”

das classes iniciais.
 Relacionamentos
Representa um conjunto de associações que persiste
planejadamente como regra, entre objetos de negócio e/ou entidades de
um determinado contexto.
É representado por conexões entre as tabelas, com
informações em suas extremidades, indicando valores de cardinalidade
e totalidade. Cada tipo de relacionamento deve ser representado por
uma associação independente.
 Entidade Associativa
São as entidades que existem, ou precisam existir, para
adotar um relacionamento de atributos próprios. Enquanto entidade
associativa, portanto o próprio relacionamento, liga uma ou mais
entidades.
Enquanto entidade pode relacionar-se a outras entidades.
Surge principalmente da normalização de relacionamentos muitos para
muitos e relacionamentos múltiplos.
129
 Autorrelacionamento
É todo relacionamento que ocorre com a própria
entidade. Ou seja, instâncias diferentes da mesma entidade podem se
relacionar, e da mesma forma que um relacionamento entre duas
entidades possui cardinalidade e totalidade definíveis.
 Relacionamento Simples:
É todo aquele onde participam apenas duas entidades. Os
relacionamentos podem ocorrer na razão de muitos para um ou um para
um.
 Unário:
É um Tipo de Relacionamento que envolve um único Tipo de Entidade.
 Relacionamento Binário:
É um Tipo de Relacionamento que envolve dois Tipos de Entidades.
 Relacionamento Múltiplo:
É todo aquele onde participam mais que duas entidades
ao mesmo tempo.
Para a compreensão da sua cardinalidade e totalidade,
toma-se como ponto de partida da análise o isolamento das entidades, e
toma-se como ponto de vista, uma por uma das entidades participantes
do relacionamento considerando um relacionamento de muitos para
um.
130
Este tipo de relacionamento normalmente demanda a

criação de uma entidade associativa.
 Cardinalidade
Indica, em um relacionamento, a quantidade máxima de
instâncias de uma entidade que podem estar associadas com cada
instância da outra entidade relacionada. Podem ser:
Uma (1) para Muitos (N)
Uma (1) para Uma (1)
Muitos (N) para Muitos (N)
A quantidade de Entidades envolvida em cada
Relacionamento é determinada pela Cardinalidade do Tipo de
Relacionamento, ou seja, pode-se estabelecer a quantidade mínima e
máxima de Entidades envolvidas com cada Entidade relacionada.
A Cardinalidade Mínima
Determina a quantidade mínima de Entidades
relacionadas, é determinada pelo número representativo, ou seja, O
(zero) 1, 2, ...., N (muitos).
131
A Cardinalidade Máxima
Determine a quantidade máxima de Entidades
relacionadas, é determinada pelo número representativo, ou seja, O
(zero) 1, 2, ...., N (muitos). Quando se desconhece alguma
Cardinalidade (mínima ou máxima) de um Tipo de relacionamento ou
quando se sabe que é maior que 1 então se generaliza descrevendo
como sendo muitos. Para os Tipos de Relacionamento Binários (que são
mais comuns) podemos citar que as Cardinalidades Máximas são as
seguintes:
▪ Totalidade
Indica, em um relacionamento, a quantidade mínima de
instâncias de uma entidade que podem estar associadas com cada
instância da outra entidade relacionada.
Os valores possíveis são 0 (parcial) e 1 (total).
Notação Gráfica do Modelo de Objetos de Negócio

O Modelo Entidade - Relacionamento (MER) foi
originalmente criado pelo norte americano Peter Chen enquanto
trabalhava no Massachusetts Institute of Technology. O MER foi
colocado para conhecimento público durante a conferência
internacional VLDB no ano de 1975.
O principal motivo do grande sucesso do MER durante
todos estes anos em que foi utilizado nas universidades como ponto de
partida para diversas pesquisas e estudos, e nas empresas como
instrumento para a organização de suas informações, foi a facilidade
com que pode ser utilizado e a clareza com que apresenta seus
resultados.
A notação que adotaremos é a da IE-Information
Engineering, criada por James Martin.
Normalização do Modelo de Objetos

Primeira Forma Normal
Uma entidade é dita normalizada na primeira forma
normal, quando atributos não pertencentes a sua chave primária não
132
possuírem entre eles atributos multivalorados (atributos com mais que

uma ocorrência de valor).
A aplicação desta forma normal gera como efeito,
quando avaliadas entidades participantes de um relacionamento do tipo
muitos para muitos, a criação de uma entidade associativa.
Comparativamente, a aplicação da primeira forma
normal está para seu resultado, assim como a aplicação do conceito de
decomposição/agregação da orientação a objeto está para o seu
resultado.
Segunda Forma Normal

Uma entidade é dita normalizada na segunda forma
normal quando além de estar normalizada na primeira forma normal,
todos os seus atributos não pertencentes a sua chave primária, for
completa e funcionalmente dependente da chave primária da entidade.
Ou seja, características exclusivas da chave primária da entidade e seus
dependentes.
Atributos que não sejam dependentes da mesma chave
devem ser separados em outras entidades.
Comparativamente, a aplicação da segunda forma normal
está para seu resultado, assim como a aplicação do conceito de
decomposição/agregação e herança (generalização e especialização)
da orientação a objeto está para o seu resultado.
Terceira Forma Normal

Uma entidade é dita normalizada na terceira forma
normal quando, além de estar normalizada na segunda forma normal,
todos os seus atributos não pertencentes a sua chave primária, for
mutuamente independente. Ou seja, atributos de uma entidade não
podem caracterizar outros atributos da mesma entidade.
Atributos envolvidos em uma dependência funcional
mútua devem ser separados em outras entidades.
Comparativamente, a aplicação da segunda forma normal
está para seu resultado, assim como a aplicação do conceito de objeto
de negócio, decomposição/agregação e herança (generalização e
especialização) da orientação a objeto, está para o seu resultado.
133
12- Elemento de Dado (ou Atributo)

Um elemento de dado representa uma característica útil
que se quer definir sobre uma determinada “coisa” (objeto de negócio)
que está sendo modelado. É o terceiro componente do elemento
informação encontrado no processo de negócio.
Ele representa a menor partícula de informação útil (de
valor agregado) sobre objetos de negócio manipulados. Sua razão
existencial é suprir os processadores de cada atividade do processo com
informação suficiente necessária para execução de uma atividade
segundo as regras de negócio e a tecnologia ali aplicada, produzindo ou
não um output.
É importante relembrar que elementos de dados quando
isolados de um contexto e de um grupo de dados não têm significado
para o negócio.
Grupo de Dados: Conjunto de Elementos de Dados Úteis ao Processo

Elemento de dados: “Matéria–Prima transformada e manipulada”.
Nominação do Elemento de Dados

O elemento de dados deve ser nominado utilizando como título palavras
que signifiquem características de coisas.
Exemplo:
- Número de identificação;
- Peso médio;
- Sexo;
- Data de emissão;
- Valor bruto;
- Discriminação;
- Título.
As características do Elemento de Dados
Os elementos de dados, que representam as
características das “coisas” manipuladas pelo processo de negócio é por
sua vez também caracterizado através de suas propriedades de formato,
134
valor etc. Estas propriedades podem ser reduzidas um padrão básico

composto por:
 Nome;
 Título;
 Tamanho (quantidade de caracteres);
 Tipo de dado ou formato (data, valor, inteiro, texto, variável
etc.);
 Domínio (conjunto de valores possíveis de serem assumidos);
 Descrição;
 Obrigatoriedade;
 Nulidade;
 Valor default.
Exemplo:
 Nome: Sexo;
 Título: Sexo do colaborador;
 Tamanho: 9 caracteres;
 Tipo de dado ou formato: Texto;
 Domínio: Masculino, Feminino, Híbrido;
 Descrição: Classe sexual do colaborador;
 Obrigatoriedade: Obrigatório;
 Nulidade: Não;
 Valor default: Masculino.
13 - Os Grupos de Dados (Inputs e Outputs do Processo)

É o segundo componente do elemento informação
encontrado no processo de negócio. Ele representa um conjunto de
elementos de dados organizados de forma específica. Este conjunto de
dados tem como objetivo, transportar informação útil (de valor
agregado) sobre objetos de negócio manipulados.
Sua razão existencial é agrupar elementos de dados, de
forma organizada e que expresse um significado, a fim de transportá-los
para os processadores de cada atividade do processo.
135
Input
Grupos de dados úteis ao processo, utilizados na ação do
processo, tanto como “insumos” para produção de outputs, como
“parâmetro ou instrução” para execução da ação. São originados de
entidades externas, internas ou de outros processos determinando suas
interdependências. Toda ação recebe no mínimo um input.
Output
Grupos de dados úteis ao processo, que:
 Foram produzidos pela ação do processo;
 Foram ora recebidos pela ação do processo como inputs e estão
sendo destinados a outras ações.
São destinadas a entidades externas, internas, depósitos
de informação ou outros processos, determinando suas
interdependências. Nem toda ação possui um output, porém pode
produzir vários outputs.
A Especificação
Contém, de forma não “normalizada”, os elementos de
dados referentes aos objetos “manipulados” pela ação do processo e
suas respectivas características.
Para cada Input e Output relacionado ao processo de
negócio, especifica-se textualmente de forma sintática os dados que o
compõe, e a forma como estão ali estruturados. Para esta especificação
utiliza-se o seguinte formalismo:
Símbolo Significado
= Composição
E, indica composição de conjunto de
+ elem_dado
dados.
Indica início e fim de várias
{elem_dado + elem_dado}
ocorrências de um conjunto de dados.
[elem_dado | elem_dado] Indica início e fim de um conjunto de
dados com obrigatoriedade de escolha
136
de apenas um dado entre o conjunto.

Indica início e fim de um conjunto de
(elem_dado + elem_dado) dados com opcionalidade total de
escolha.
Indica início e fim de um conjunto de
<elem_dado | elem_dado> dados com opcionalidade de escolha
de vários dados entre o conjunto.
** texto Comentário.
@ elem_dado Indica identificador do grupo de dados.
Exemplo A:
Novo projeto de apuração =
@Projeto
+ Cliente
+ {ano_fiscal
+ Tipo_de_imposto
+ {Projeto. tipo_de_serviço + (Consultor_responsável )}
Exemplo B:
@Sócio
+ endereço_do_sócio
+ ({fone_do_sócio})
+ [CPF_do_sócio + RG_do_sócio / CGC_do_sócio]
A Nominação
O grupo de dados deve ser nominado utilizando-se como
título frases compostas pela combinação:
Verbo substantivado/Objeto/Característica/Adjetivo qualificativo
Exemplos:
 Solicitação de compra;
 Pendência de aprovação de compra;
 Pedido de compra;
137
 Orçamento do período;
 Liberação de despacho;
 Movimento de entradas do período.
14 - Atributo
É o elemento de dado que caracteriza exclusivamente
uma determinada entidade sob a ótica de armazenagem através da
tecnologia de informação. Um atributo pode ser originado da
necessidade de armazenar um elemento de dados manipulado em vários
processos de negócio.
Um mesmo atributo, de uma mesma entidade, pode ser
nomeado no mundo real de várias formas. Cada forma com que este
atributo é nomeado, é um elemento de dados diferente. Porém, todos
esses elementos de dados fazem referência ao mesmo atributo da
mesma entidade. Isso se justifica pelo fato de um atributo possuir um
significado diferente em cada contexto, ou seja, para cada processo de
negócio um mesmo atributo pode ter nomes diferentes.
Atributo Identificador
Um atributo pode ser Identificador de uma determinada
entidade. Neste caso ele é classificado como sendo PK – Primary Key
(chave primária) da respectiva entidade. Um atributo para ser “chave
primária” de uma entidade deve obrigatoriamente ser único e de valor
não passível de repetição.
Exemplo:
a-Processo de Cobrança: Elemento de dado relacionado:
CGC_cliente_cobrado
b-Processo de protesto: Elemento de dado relacionado:
cod_cliente_protestado
c-Processo de avaliação de satisfação de cliente: Elemento de dado
relacionado: ID_cliente_avaliado
15-A Construção do Modelo de Informação

A seguir um “roteiro” para se determinar uma primeira
versão do Modelo de Informação, pode ser descrito pelos seguintes
138
passos:
1. Identificar os Objetos de Negócio;

2. Determinar os Relacionamentos entre os Objetos de negócio;
3. Criar o modelo gráfico dos objetos de negócio;
4. Definir os grupos de dados do processo;
5. Definir os elementos de dados úteis contidos nos grupos de
dados;
6. Definir as regras de negócio do processo;
7. Definir os elementos de dados úteis utilizados nas regras de
negócio;
8. Associar os elementos de dados úteis aos respectivos Objetos de
Negócio;
9. Definir os Elementos de Dados - ID dos Objetos de Negócio;
10. Aplicar as formas de normalização no modelo de Objetos de
Negócio;
11. Definir as Entidades resultantes da normalização;
12. Criar o modelo de Dados contendo entidades;
13. Definir os Relacionamentos entre as Entidades;
14. Definir as Cardinalidades Mínima e Máxima dos
relacionamentos entre Entidades;
15. Associar os Atributos às respectivas Entidades;
16. Definir os Atributos - ID das Entidades.
As versões do Modelo de Informação devem ser

apresentadas e refinadas sucessivamente junto ao cliente do projeto até
ser considerada estável.
139
16 - A Informação Percebida na Camada da Tecnologia (TI)
Considerando que a aplicação de tecnologia de

informação como mecanismo de suporte é parte integrante,
praticamente inseparável, dos processos de negócio, seja na situação
corrente ou mais ainda nos modelos de solução ideal, definir a forma de
armazenamento para os elementos de dados que caracterizam os objetos
de negócio, é uma tarefa que podemos considerar como natural no
processo de modelagem integral de solução operacional de negócio.
É claro que tal tarefa somente é demandada quando, de
fato, o foco do projeto em questão for direcionado também para
tecnologia de informação, especificamente quando a profundidade for
total para a construção de sistemas de informação.
Visto que o modelo de dados é um modelo que define a
visão lógica da memória permanente do sistema, e este é um aspecto de
natureza implementacional, ou seja, depende da tecnologia de
armazenagem aplicada (DBMS), o que adotamos neste capítulo é uma
abordagem que combina conceitos de modelagem orientada a objeto e
conceitos de normalização de tabelas para geração de modelos
relacionais.
O modelo gerado sobre percepção da informação na
camada da tecnologia representa uma visão lógica da armazenagem dos
elementos de dados, desta forma, pode-se tornar necessária a derivação
de modelos físicos diferentes dependendo do DBMS adotado.
140
Nosso objetivo é construir e especificar um modelo de

dados que represente com precisão a compreensão do requerimento
informação, e possa ser o ponto de partida para a derivação ou geração
de modelos físicos implementacionais, específicos para cada ambiente
de DBMS.
OOAD - Conceituação (Object Oriented Analysis and Design)

Para entender o que há de certo e errado com as técnicas
de OOAD, é necessário entender em que ponto essas técnicas se
localizam dentro do ciclo de vida do projeto de sistemas.
Essas técnicas não substituem as técnicas de abordagem
tradicionais (fluxo de dados, fluxo de processos e diagramas de estados
de transição), porém, provêm um novo e importante incremento para o
conjunto de ferramentas e técnicas.
Segundo Donald Firesmith em seu livro “Dicionário de
Tecnologias de Objeto - SIGS 1995”, análise é “Uma atividade de
desenvolvimento consistindo de descoberta, modelagem, especificação
e avaliação de requerimentos”, enquanto a análise orientada a objeto é
“Uma atividade de desenvolvimento consistindo de descoberta,
modelagem, especificação de requerimentos em termos de objetos com
identidade que encapsulam propriedades e operações, passagem de
mensagens, classes, herança, polimorfismo e ligação dinâmica”.
As técnicas de OOAD enquadram-se basicamente em
duas categorias:
A Ternária
É uma evolução natural das técnicas de análise
estruturada e possui três notações separadas para: dados, dinâmicas,
processos.
A Unária
Define que devido aos objetos combinarem processos
(métodos) e dados, somente uma notação é necessária.
Quadro Comparativo entre Técnicas de OOAD
Aplicaçã
Técnica Tipo Escopo Amplitude
o Inicial
Jacobson Ciclo completo
Ternária Complexa, rica Todas
OOSE (sistema)
141
Yourdom
Complexa, rica, Ciclo completo Client/
Mainstream Ternária
pragmática (PB - Sistema) Server
Objects
Shlaer and
Ciclo completo Real-
Mellor Ternária Complexa, rica
(sistema) time
OOA
Meio do
LBMS Ciclo completo Client/
Ternária caminho,
SEOO (sistema) Server
pragmática
Complexa, rica, Ciclo completo
Fusion Ternária Todas
pragmática (sistema)
Complexa, rica,
Todas,
Rumbaugh Alguns Análise e
Ternária Real-
OMT elementos Projeto
time
pragmáticos
Complexa, rica,
Booch Ternária Projeto Todas
pragmática
Coad and Complexa, rica, Client/
Unária Análise
Yourdon pragmática Server
● Fonte: Revista DBMS Tools & Strategies for IS
Professionals - artigo assinado por Michael Gora.
Anatomia do Objeto
A Memória Permanente dos Sistemas
Da mesma forma que o modelo de Objetos de Negócio
tende a representar a realidade da empresa extrapolando a fronteira do
processo através do qual foi percebida, a memória permanente dos
sistemas deve representar a Base de Dados Corporativa.
Deve haver, por excelência, uma única “base de dados”,
o modelo de memória permanente é de fato o modelo de Objetos de
Negócio implementado fisicamente, e como tal deve refletir de forma
íntegra e consistente, o conjunto de dados de interesse da empresa.
Uma vez conhecido o verdadeiro requerimento de
informação do processo de negócio (objetos de negócio, grupos de
dados e elementos de dados) passa-se a definir a forma de manter essas
informações armazenadas, ou seja, define-se a memória permanente do
sistema de informação.
142
A modelagem da memória permanente é executada

através da construção do Modelo Lógico de Dados e toma como ponto
de partida os seguintes elementos:
 Os Objetos de Negócio encontrados na camada do mundo real e

identificados no modelo de informação (alto nível);
 Os Elementos de Dados identificados em cada grupo de dados
especificado na camada do mundo real;
 As Regras de Negócio identificadas no processo de negócio na
camada do mundo real.
17- Princípios de Refinamento e Otimização

Essencialidade
Compor inputs e outputs (grupos de dados) apenas com
elementos de dados úteis ao processo, ao negócio;
Considerar a agregação de valor da informação aos
próximos passos do processo;
Eliminar inputs e outputs desnecessários.
Acesso
Estabelecer níveis de acesso adequados às informações;
Disponibilizar informações, para consultas Ad hoc, em
qualquer ponto do processo;
Adotar mídias (formulários, telas, relatórios, etc.)
eficientes e amigáveis para transmissão e manipulação de informações.
Guarda ou Armazenagem
Restringir o depósito de informações as informações
historicamente úteis e essencialmente necessárias;
Utilizar informações sumariadas e acumuladas para
sintetizar dados históricos não essenciais;
Perseguir a implementação física de uma única “base de
dados” referente à empresa (mesmo que distribuída fisicamente), caso
não seja possível, promover a integridade entre as diversas bases através
da criação de regras de relacionamento.
143
Organização
Organizar os elementos de dados, dos grupos de dados,
de forma ergonômica, simples e intuitiva.
144
Capítulo 08
MODELAGEM DE SISTEMAS – ORIENTADO À OPERAÇÃO
DO NEGÓCIO
1 - O Conceito de Sistema (Sistema Não Inteligente)

Mecanismo composto de várias partes que agem de
forma coordenada para atingir um objetivo.
Em nosso curso, utilizaremos esse conceito com o
objetivo específico de modelar sistemas de informação (Softwares)
voltados para ap FO ar a realização de atividades de processos de
negócio.
2 - A gestão de desenvolvimento de aplicações orientada à Processo

de Negócio
Apesar da evolução das técnicas de engenharia de
software, persiste um risco, um problema: “aplicações perfeitamente
especificadas, codificadas e testadas não promovem o resultado
esperado por seus clientes”. Observamos que a causa está na engenharia
de requerimentos desalinhada à operação ou “trecho” da operação a ser
suportado pela aplicação desenvolvida.
Nossa forma de conduzir projetos de desenvolvimento
parte da engenharia do processo a ser suportado pela aplicação e
“criamos” os casos de uso reordenando o modelo real de negócio, onde
normalmente reside a falha de arquitetura que é repassada para
requerimentos “defeituosos”.
145
Nesta camada a engenharia de processo redefine a

melhor forma de operar e de maneira “multidimensional” define um
modelo combinatório adequado considerando o workflow, seus casos de
uso, as responsabilidades, os produtos e informações necessários ao
negócio e as regras a serem aplicadas pelo sistema a ser desenvolvido.
Esta abordagem garante que o desenvolvimento
produzirá uma aplicação que além de ser bem especificada, codificada e
testada, resultara em melhoria para a operação do negócio e da empresa,
o resultado esperado por qualquer investidor.
3 - A Modelagem de Sistemas Aplicativos Integrada ao BPM-M

É consenso estabelecido que a tecnologia de informação
tem como finalidade exclusiva suportar a execução ótima de atividades
que visam atingir os objetivos do negócio, ela é sem dúvidas um dos
veículos através dos quais é possível transformar radicalmente a forma
de executar estas atividades e consequentemente toda a operação.
3.1 - As Abordagens Convencionais

É fácil reconhecer que a base sobre a qual os métodos
convencionais iniciam a modelagem de um sistema aplicativo não é
integra, ela depende exclusivamente da capacidade e habilidade pessoal
do modelador e do(s) cliente(s) envolvidos para:
146
 Reconhecer adequadamente as fronteiras do sistema;

 Identificar todos os papéis candidatos a Classe de ATOR;
 Investigar, descobrir, obter, abstrair os Casos de Uso do sistema,
e o próprio objetivo do sistema;
 Discernir entre os casos de uso que possuem correlação em um
mesmo contexto de negócio e os que não possuem;
 Distinguir entre o essencial, o não essencial e que deve ser
mudado;
 Materializar uma visão espacial, abstrata e atemporal de sistema,
diferente da visão processual natural aos “clientes” do projeto
envolvidos na operação do negócio;
 Adquirir conhecimento sobre o negócio, descobrir os problemas
operacionais a serem resolvidos e propor soluções, tudo
simultaneamente.
Todas estas “características” afetam a definição inicial
do modelo de requerimentos do sistema aplicativo a ser projetado.
A clara, objetiva e completa percepção das funções,
objetos (c FO sas), atores e Integridade sequencial dos diálogos homem-
máquina requeridas pelo negócio constituem o único ponto de partida
seguro para o projeto de uma aplicação.
Esta percepção somente pode ser obtida quando focamos
a percepção das necessidades de suporte tecnológico na camada do
negócio.
A concepção ou alteração da arquitetura da camada de
negócio estabelece esse conjunto de requerimentos que,
obrigatoriamente, precisam ser “engenhados” simultaneamente com as
demais dimensões da arquitetura para agregar real valor de performance
na operação do negócio, e não apenas automatizá-la.
Esta é a única forma de se compreender o “alinhamento
da tecnologia com o negócio” e a tecnologia como habilitadora de
transformação do negócio, são interdependentes.
3.2 - A Abordagem Baseada no BPM-M

A definição da base do modelo do sistema através da
modelagem de processo de negócio objetiva focar, em primeiro plano, a
realidade do negócio através do conhecimento e análise de sua
147
arquitetura multidimensional, definindo, a partir daí a melhor forma de

otimizar essa realidade através da utilização do suporte da tecnologia de
informação. Desta forma, esta abordagem objetiva essencialmente:
● Definir a interação e o diálogo entre processadores humanos
(atores) e o sistema de informação;
● Requerimentos verdadeiros:
 Interface homem-máquina (UI);
 Ações do sistema (programas, procedures, objetos de
programação);
 Memória permanente (base de dados).
4 - A Engenharia de Sistemas Aplicativos Através da Técnica: UML

– Unified Modeling Language
UML (Unified Modeling Language ou Linguagem de
Modelagem Unificada) é uma linguagem visual utilizada para modelar
sistemas computacionais por meio do paradigma de Orientação a
Objetos. Essa linguagem se tornou, nos últimos anos, a linguagem-
padrão de modelagem de software adotada internacionalmente pela
indústria de Engenharia de Software.
Deve ficar bem claro, no entanto, que a UML não é uma
linguagem de programação, mas uma linguagem de modelagem, cujo
objetivo é auxiliar os engenheiros de software a definir as
características do software, tais como seus requisitos, seu
comportamento, sua estrutura lógica, a dinâmica de seus processos e até
mesmo suas necessidades físicas em relação ao equipamento sobre o
qual o sistema deverá ser implantado. Todas essas características são
definidas por meio da UML antes de o software começar a ser
realmente desenvolvido.
A UML – Unified Modeling Language, é a técnica
resultante da fusão das três escolas OOSE (Ivar Jacobson), OMT-
Object Modeling Technique (James Rumbaugh), OOA - Object
Oriented Analysis (Grady Booch). O padrão f FO criado pela então
Rational Co. e f FO acolhido pela OMG – Object Management Group
em 1997.
148
Originalmente o método OOSE - Object Oriented

Software Engineering, f FO um método de modelagem de sistema
aplicativos, ternário e orientado a objeto criado pelo sr. Ivar Jacobson
em 1992. E f FO sob a ótica da OOSE que o diálogo entre homem e
maquina f FO definido como um dos pontos de partida para a
modelagem eficaz de sistemas aplicativos.
A essência desta técnica consiste, na descoberta dos
requerimentos do sistema aplicativo através da observação das
interações (diálogos) entre os Atores e o sistema aplicativo. Com base
nessas interações (diálogos), denominadas Use Cases, são modeladas as
três classes de Objetos que compõem o sistema aplicativo: Classe
Entidade, Classe Controle, Classe Fronteira.
4.1-Conceitos Principais da UML 2.X

Atores
Definimos ator como uma classe ou categoria de
“usuários”, mais propriamente uma classe de pessoas, ou um papel
interpretado por processadores humanos no mundo real, que interagem
com o sistema. Uma pessoa pode assumir e executar vários papéis de
ator.
Basicamente, compreendemos atores como pessoas,
porém, também podemos compreender como sendo outros sistemas que
se comunicam com o sistema sendo modelado, essencialmente é alguma
com FO sa externa aos limites do sistema e que necessita interagir com
ele.
O Conceito Use Case
O conceito de use case consiste da descrição da

interação entre um ator e o sistema. Um use case é a definição de uma
forma singular de usar um sistema, ou alguma classe de cenário de alto
149
nível, que captura como os atores utilizam suas aplicações “caixa-

preta”. Use case é basicamente utilizado para encontrar e identificar os
requerimentos em termos de diálogos com o sistema.
Um use case é então uma sequência específica e
completa de transações relacionadas (vários estímulos e respostas),
executadas por um ator e pelo sistema em um diálogo determinado a
prover algum valor mensurável no contexto de seu processo de negócio.
A Descrição do Use Case

Uma atenção especial tem que ser dada à descrição do
Use Case, pois é o primeiro passo para a concepção dos requerimentos
funcionais do sistema aplicativo a ser projetado.
Devemos produzir uma descrição clara e concisa do
funcionamento básico do Use Case e funcionamento alternativo
apropriado.
Os Principais Pontos de Atenção na Descrição de Use Cases

 Não escreva requerimentos funcionais ao invés de um texto de
uso;
 Não descreva atributos ou métodos a serem utilizados;
 Não descreva o Use case de forma muito concisa;
 Não se afaste do ponto de vista e percepção do ator para
descrever o Use Case;
 Descreva as interações entre o ator e as “respostas” dos
sistemas;
 Foque sua atenção em descrever o que deve ocorrer dentro do
Use case, não antes ou depois;
 Não invista muito tempo decidindo se você utilizará um Extend
ou Use.
150
4.2 - O BPM-M Integrado à UML 2.X

A definição do Modelo de Requerimentos Funcionais
do sistema (modelo de use cases), através da modelagem de processo,
objetiva focar, em primeiro plano, a realidade do negócio através do
conhecimento e análise de suas dimensões, definindo a partir daí a
melhor forma de otimizar essa realidade através do suporte da
Tecnologia. Desta forma, esta abordagem objetiva:
● A derivação do Modelo de Requerimentos (modelo

de use cases).
● Construção do Modelo de Classe: estrutura robusta de
objetos mutável.
4.3- O BPM-M e os Efeitos com a Utilização da UML 2.X Integrada

Qualificação das Atividades da Operação
As atividades passam a ser classificadas em Ação de
Processo de Negócio e Ação use case.
● Ação de Processo de Negócio:
são aquelas que não envolvem mecanismos de suporte
da Tecnologia de Informação, sua execução é de
natureza puramente humana ou manual.
● Ação Use Case:
são aquelas que envolvem mecanismos de suporte da
TI, pressupõem interação e diálogo com um sistema de
informação. Estas ações são os use cases do modelo de
requerimentos do sistema.
Nível de Decomposição
Limite Prático de Decomposição
Passa a encontrar-se em um nível mais superior de
observação, a regra para a detecção deste nível é:
● A decomposição das atividades da operação deve cessar
quando as atividades resultantes desta decomposição
não puderem ser compreendidas separadamente, ou seja,
quando estas forem atividades relacionadas com a
151
produção de um único output de real valor para

operação. Estas atividades são, sob o ponto de vista da
nova abordagem, partes inseparáveis do conjunto de
interações ou diálogo com o sistema, portanto, nosso
use case.
● A decomposição deve levar em consideração que uma
determinada atividade deve possuir somente uma
Classe de Ator como processador, ou seja, deve-se
decompor as atividades que tenham a execução
partilhada por Classes de Atores distintas.
● Deve-se agrupar atividades imediatamente
subsequentes executadas pela mesma Classe de Ator,
desde que não exista nenhuma condição de desvio entre
elas.
Processador e Ator
Os processadores das ações do processo passam ser
considerados como Atores na relação com os use cases dos sistemas.
Inputs e Outputs das Atividades
Maior atenção deve ser dada aos grupos de dados
referentes aos inputs e outputs das atividades do processo, visto que
serão estes os elementos de dados e/ou informações que estarão sendo
manipuladas através dos use cases do sistema, especificamente contidas
nos objetos de interface.
 Descrição dos Objetivos do Sistema
Descrever os objetivos que se pretende atingir com a
utilização do sistema no suporte à execução das ações do processo de
negócio.
152
Não confundir a descrição dos objetivos a serem

atingidos com a descrição das “funções do sistema”, isto é muito
comum e não agrega valor nesta etapa de modelagem.
Tais objetivos podem se confundir ou serem idênticos
aos objetivos da modelagem do processo de negócio, pois ambas as
fases de trabalho (modelagem do processo de negócio e modelagem do
sistema de informação) objetivam otimizar do processo de negócio e o
atendimento ideal dos objetivos do próprio negócio.
4.4- Encontrando os use cases na situação corrente do Processo de

Negócio
O conceito de use case f FO basicamente desenvolvido
para projetarmos os requerimentos do sistema aplicativo a partir da
percepção do que ele deverá contemplar em termos de diálogo homem-
máquina, entretanto, quando estamos realizando o levantamento da
situação corrente de um processo de negócio, podemos utilizar o mesmo
conceito para identificar e qualificar as atividades em seu estado atual
de acordo com o uso ou não de suporte de sistemas aplicativos
Na fase de levantamento da situação corrente e
diagnostico do processo de negócio, identificamos como use case as
atividades que utilizam de “sistemas aplicativos” para suportar sua
execução. Para estas atividades identificadas como Casos de Uso
devemos “mapear” todas as “funções” dos sistemas aplicativos
utilizadas por ela.
Essa qualificação das atividades, em seu estado atual,
como Casos de Uso possibilitará a análise da qualidade do suporte
tecnológico ao processo de negócio em estudo.
153
O “índice de suporte sistemas aplicativos” é dos índices

que podemos utilizar para medir a qualidade arquitetura do processo de
negócio de acordo com sua natureza.A correlação entre as “Funções” de

Sistema e as Atividades do Processo (Use Cases)
4.5- Conceitos sobre os Elementos da UML 2.X

Conceitos Básicos
Associações do Modelo de Use Cases

Use cases podem relacionar-se com outros use cases que
não são estimulados diretamente por atores do mundo exterior. Esses
relacionamentos são denominados de:
154
Comunicação
Ponto de partida da compreensão do modelo de Use Cases uma vez
derivados do modelo operacional de negócio. Comunicação entre o
Ator e o sistema “Use Case”.
Extends
Trata-se de um relacionamento que determina que um

dado Use Case pode englobar (encadear) a ocorrência de outros use
cases. Este relacionamento pode ser utilizado nos seguintes casos:
● Para modelar partes opcionais de um use case;
● Para modelar roteiros complexos e alternativos que
raramente acontecem;
● Para modelar sub-roteiros (subclasses de use case)
separadamente, as quais são executadas somente em
determinados casos;
● Para modelar a situação onde diversos use cases podem
ser “inseridos” dentro de um (compartilharem de um)
use case especial;
● Em outras palavras, um use case extended pode ser uma
decomposição de um determinado use case.
155
Uses
Um dado use case pode ser decomposto, ou seja,
podemos segregar determinadas características de use case referentes a
roteiros comuns a outros use cases e criar um novo use case
compartilhável com outros use cases, ou ainda, podemos agregar um
conjunto de use cases em um novo use case abstrato para compartilhar
características comuns a todos, como uma relação de classe e subclasse.
Conceitos do Modelo de Classes – UML 2.X

Após a construção do modelo de requerimentos (use
cases e atores), é focada a estrutura do sistema através da análise dos
objetos que serão manipulados por cada use case. Estes objetos são
referentes a três classes: objetos de interface, objetos de controle e
objetos entidade.
Com base nessas classes de objetos, é construído o
Modelo de Análise do sistema, demonstrando a estrutura de objetos do
sistema e sua forma de relacionamento. Cada um destes objetos tem seu
próprio propósito e modela um aspecto específico do sistema.
Classe de Fronteira (FO)
156
São objetos através dos quais os atores se comunicam e

interagem com o sistema. A tarefa do objeto de interface é traduzir o
input do ator para o sistema, dentro de eventos para o sistema, e traduzir
esses eventos do sistema, os quais o ator está interessado, em alguma
coisa a ser apresentada ao ator.
Desta forma, os Classes de Fronteira podem descrever a
transação bidirecional de interação entre Ator e Sistema. Relações entre
Classes de Fronteira são denominadas associações conhecidas, pois as
instâncias se conhecem e as associações possuem um título e uma
cardinalidade pré-determinados.
Como conceituado anteriormente, também os Classes de
Fronteira podem possuir relações do tipo estático e podem ser
decompostos ou agregados, hierarquizados e generalizados ou
especializados.
Classe Entidade (EO)
Para modelar a informação que o sistema manipulará ao

longo de período, nós utilizamos o Objeto Entidade.
Tipicamente, refere-se às informações que necessitam
permanecer no sistema após o use case ser completado, ou seja, as
informações devem fazer parte da memória permanente do sistema.
Aqui são representadas as entidades (tabelas)
encontradas através da Modelagem de Informação (objetos de negócio)
e refinadas na Modelagem de Dados.
Classe de Controle (CO)

Objetos de Controle são utilizados, em um use case,
quando restam comportamentos do sistema que não foram apropriados a
Classes de Fronteira ou objetos entidade.
157
Os Classe de Controle agem tipicamente como uma

“cola” que une os objetos que formam o use case, e essencialmente
contém comportamento referente à Lógica de Negócio (manipulação de
informação e de regras), sequências de controle específicas ou
funcionalidades que separam Classes de Fronteira de Classe entidade.
Num primeiro instante, deve ser criado um objeto de
controle para cada use case.
Subsistema
A representação de subsistemas é utilizada quando temos
que expressar a associação uma determinada classe de objeto e um
subsistema ou sistema de fora do contexto do sistema foco da
engenharia.
O Relacionamento entre Os Objetos do Sistema
O Modelo de Colaboração (Modelo de Objetos de Use Case)

Em nossa versão ajustada da OOSE acoplada à
engenharia operacional de negócio o Modelo de Colaboração é, dentre
158
os modelos originais da técnica, o único modelo adotado. Pois o

objetivo do modelo gerado na fase de engenharia operacional de
negócio é produzir a base do projeto de engenharia do software,
cabendo aos engenheiros de software optar pela utilização ou não dos
demais modelos originais da técnica. Os demais modelos originais da
técnica são:
Modelos Dinâmicos
Modelo de Use Case
Modelo de Colaboração
Diagrama de Sequência
Modelos Estáticos
Modelo de Domínio
Diagrama de Classes
Modelo de Colaboração
Os principais Pontos de Atenção na Construção do Modelo de

Colaboração
● Não viole as regras de associações entre os objetos;

● Use o Modelo de Colaboração para auxiliá-lo a formatar o que foi
descrito no texto do Use Case;
● Inclua os cursos alternativos no modelo;
● Não inclua muitos nem poucos objetos de controle;
● Não invista muito tempo tentando aperfeiçoar o modelo antes de
“mergulhar” na especificação dos objetos;
159
● Não tente criar um projeto detalhado utilizando o Modelo de

Colaboração;
● Realize um batimento visual entre a descrição do Use Case e
Modelo de Colaboração;
● Refine seu modelo à medida que o conceito de “funcionamento” do
use for se depurando na sua especificação.
Especificação da FO – Classe de fronteira

O objeto de interface FO deve ser especificado através dos seguintes
atributos:
Título:
ID: Código interno:
Objetivo:
Processamento:
Especificação:
Inibir em
Parâmetr
Elemento de dado estado
o consulta
edição
Relação de eventos
Este padrão refere-se à organização, estrutura de relacionamento entre

os Classes de Fronteira e seus eventos contidos em um mesmo use case,
e os eventos.
160
São definidos d FO s conceitos básicos de relacionamento entre Classes

de Fronteira contidos em use case:
 Relacionamento Encadeado (ou sequencial)
obrigatório;
 Relacionamento Opcional “Radial”.
Relacionamento entre Classes de fronteira - FO’s
 Relacionamento Encadeado (ou sequencial) Obrigatório:
Este conceito se refere a um conjunto de FO organizados
de forma sequencial obrigatória, uma cadeia planejada de FO.
Representa um “processo” de navegação entre FO, onde o ator é
obrigado a navegar através da sequência pré-estabelecida de FO até sua
conclusão.
Tal forma de implementação objetiva conduzir o ator,

uma vez “dentro” de um determinado use case, a executar os diálogos
com sistema de forma planejada e ergonômica, otimizando seu trabalho
através do estabelecimento, em tempo de modelagem, de padrão
simples.
 Relacionamento Opcional “Radial”:
161
Este conceito se refere a um conjunto de FO organizados

de forma não sequencial e não obrigatória. Representa as opções de
navegação “radial” a partir de um único FO para outros FO
relacionados a ele, porém não relacionados entre si. O Ator tem por
opção navegar para estes FO, porém obrigatoriamente retornar para o
FO do ponto de partida.
162
Um exemplo:
Use Case aplicando ambos os conceitos de
relacionamento (encadeado obrigatório e opcional).
Padrão de Especificação da Classe de Fronteira

Regra de Determinação de ESTADO da Classe de Fronteira - FO
 Estados do Objeto de Interface
Os estados possíveis para os FO são, independentemente
de sua posição relativa no use case, os seguintes:
● Estado de Novo, o FO está habilitado a executar a inclusão de um
ou um conjunto de registro(s) de uma ou um conjunto de tabelas
manipuladas no banco de dados.
● Estado de Edição, o FO está habilitado a permitir a edição de um
ou um conjunto de registro(s) de uma ou um conjunto de tabelas
manipuladas no banco de dados.
● Estado de Consulta, o FO está habilitado a permitir a consulta de
um ou um conjunto de registro(s) de uma ou um conjunto de
tabelas manipuladas no banco de dados.
163
 Estado Inicial
Para os FO identificados como o primeiro objeto de
interface do conjunto de FO do Use Case com o qual o Ator dialoga,
fica definido como ESTADO default “nulo”.
O ator deve disparar o evento correspondente ao estado
desejado através do acionamento do objeto visual correlacionado. Os
demais FO do use case são abertos assumindo como ESTADO default,
o estado corrente do FO de entrada do use case.
 Mudança de Estado
A mudança de estado deve obedecer à tabela Regra de
Validade de Eventos.
Eventos Sobre os Objetos de Interface

Para organizar o diálogo do Ator com os Classes de
Fronteira - FO são definidas como padrão, três classes de eventos,
através dos quais o Ator age sobre os FO de acordo com seu estado e
sua posição relativa na estrutura de relacionamento “dentro” de um
determinado use case.
Para cada evento definido em um determinado FO deve
haver a especificação correspondente da “ação” do sistema. Este evento
no modelo lógico não ainda associado a um objeto físico de
desenvolvimento, porém, quando interpretado na fase do projeto físico
de construção do Use Case irá corresponder a um determinado evento
de programação para o qual um determinado objeto acionará seu
método.
Cada Objeto de Interface pode possuir vários eventos
definidos sobre ele. A seguir definimos um conjunto de classes de
eventos e suas famílias de valores, com os quais acreditamos poder ser
representada toda forma de diálogo entre o Ator e o FO.
 Classe Eventos de Navegação

Agrupa os eventos que agem sobre os FO conduzindo o ator aos
demais FO do use case obedecendo a estrutura de relacionamento pré-
estabelecida. Estes eventos são:
164
<AVANÇAR_ ... >

Avança para o próximo FO obrigatório da cadeia de FO
do use case e dispara a consistência do Grupo de Dados do FO corrente.
<VOLTAR_ ... >
Retorna para o FO no “passo” imediatamente anterior da
navegação, podendo ser aplicado no relacionamento encadeado (ou
sequencial) obrigatório e/ou no relacionamento opcional radial.
<SAIR_ ... >
Retorna, de qualquer ponto do use case, para o menu
principal (tree view) do aplicativo “abortando” a operação do FO
corrente. Quando ocorrido no FO “Menu Principal”, retorna para o
sistema operacional (desativa o aplicativo).
<IR_PARA_ ... >
Navega para um determinado FO opcional, relacionado
radialmente com o FO onde o ator se encontra.
 Classe Eventos de Transação com Banco de Dados

Agrupa os eventos que agem sobre os FO
executando ações sobre o banco de dados do aplicativo. Sintaxe
comando_nometabela
<ENCONTRAR_ ... > (READ)

Selecionar registros de tabelas segundo uma condição.
<ATUALIZAR_ ... > (UPDATE)
Gravar fisicamente na tabela o registro editado exibido
no “FO” corrente.
<CRIAR_ ...> (CREATE)
Grava fisicamente na tabela, um registro novo exibido no
FO corrente, sem efetivar atualização no banco.
<REMOVER_ ...> (DELETE)
Exclui fisicamente do banco de dados o registro exibido
no FO corrente. A ação do aplicativo deve observar as regras de
integridade do modelo de dados.
<EFETIVAR_ ... > (COMMIT)
Gravar fisicamente na.
165
 Classe Eventos de Mudança de Estado do FO

Os estados possíveis para os FO são, independentemente
de sua posição relativa no use case, os abaixo relacionados. Para os FO
identificados como o primeiro objeto de interface do conjunto de FO do
Use Case com o qual o Ator dialoga, fica definido como estado default
“CONSULTA”.
<MUDAR_PNOVO>
Limpa/apaga, do FO corrente, os dados referentes ao
registro exibido, e transforma o ESTADO do FO corrente para
“Novo”.
<MUDAR_PEDIÇÃO>
Transforma o ESTADO do FO corrente para “Edição”.
Somente deve ocorrer após a ocorrência do evento “consultar registro”.
<MUDAR_PCONSULTA>
Transforma o ESTADO do FO corrente para “Novo”.
Recupera um registro ou um conjunto de registros da(s) tabela(s)
manipulada(s) no banco de dados.
Regra de validade de Eventos sobre Objetos de Interface
O quadro abaixo estabelece a regra a ser aplicada na
modelagem de Classes de Fronteira implementado em forma de
166
“inibição” e “habilitação” de componentes visuais que percebam os

eventos pré-definidos.
 Especificação do OC – Objeto de Controle
A especificação da lógica ou método do objeto de
controle é semelhante à especificação de um evento do FO. Como
Objetos de Controle são métodos e não tem interação direta com
Classes de Ator, não possuem elementos de dados a serem
especificados como layout de interface homem-máquina.
Seu Template:
Título:
ID: Código interno:
Objetivo:
Processamento:
Especificação:
Especificação Textual do Método dos Objetos (Lógica)

É descrição textual da lógica contida no método de cada
objeto do Use Case, ou seja, quais ações que o sistema deve executar e
quais as condições a serem consideradas nessa execução. Cada Use
Case deve ser especificado de forma objetiva, clara e completa no
tocante ao:
 Método contido em cada evento de FO a ser percebido
sobre os objetos de interface;
 Método contido em cada objeto de controle (OC).
Formalismo da Especificação Textual

Para a perfeita compreensão da especificação textual é
necessário o estabelecimento de um conjunto formal de palavras chaves
que tenham um significado claro e padrão, e permitam a mesma
interpretação, independentemente de quem construa tal especificação.
167
Tal formalismo pode ser definido utilizando-se conceitos

e termos próprios de cada modelador, porém apresentaremos aqui uma
alternativa:
● Para manipulação de Objetos da memória
permanente:
<ENCONTRAR_ ... > (READ)
Selecionar registros de tabelas segundo uma condição.
<ATUALIZAR_ ... > (UPDATE)
Gravar fisicamente na tabela o registro editado.
<CRIAR_ ...> (CREATE)
Grava fisicamente na tabela, um registro novo, sem
efetivar atualização no banco.
<REMOVER_ ...> (DELETE)
Exclui fisicamente do banco de dados o registro. A ação
do aplicativo deve observar as regras de integridade do modelo de
dados.
<EFETIVAR_ ... > (COMMIT)
Gravar fisicamente na tabela, um registro novo, somente
após a inclusão de todos os campos obrigatórios das tabelas.
 Para definição de condições:
Se;
Se Não;
Fim_Se.
 Para indicação de repetições:
Para_Cada;
Fim_Cada.
 Para definição de expressões e operadores:
Comparação: < ; > ; := ; = ; #
Operação: + ; - ; * ; / .
 Para a recepção e produção de fluxo de dados:
<RECEBER>
Receber dados ou parâmetros.
<PRODUZIR>
 Para comunicação entre objetos:
<CHAMAR>
Chamar ação de outro objeto.
168
<RETORNAR>
Retornar informação para objeto que realizou a chamada.
Exemplo: método de um provável OBJETO DE CONTROLE

“Calcular Redução Atividade Incentivada BRB”
Receba os parâmetros:
nome_da_atividade
@valor_do_imposto_basico
SE nome_da_atividade = "atividade_para_calculo_brb"
Tipo_de_imposto.sigla:= "ir"
@base_calculo_imp:= (@jj/100 * @kk * 0.05)
Funcao.calc_val_basico_imp(Ano_fiscal., Projeto.,
Tipo_de_imposto.,
@base_calculo_imp)
@valor_do_ir_basico_brb := @valor_do_imposto_basico
@valor_reducao_atividade_brb:= (@valor_do_ir_basico_brb *
@c)
F_SE
Produza
@valor_reducao_atividade_brb
Exemplo: método de um provável OBJETO DE INTERFACE -

EVENTO
“Cria Versão de Apuração (Parcial)”
RECEBA versão de apuração

PARA_CADA composicao EM versao_de_apuracao
CRIE Composicao. DE
Valor_de_componente.
Versao_apuracao.
F_PARA
PARA_CADA retirada_de_administrador EM versao_de_apuracao
CRIE Retiradas_adotadas. DE
Retirada_de_administrador.
Versao_apuracao.
169
F_PARA
PRODUZA resultado_parcial_de_versao_de_apuracao
 Nivelamento do Modelo do Sistema (Composição dos
Módulos Funcionais)
O nivelamento do modelo de Use Case, objetiva
particionar e organizar o sistema em conjuntos de Use Cases, de forma
que se possa ter uma perfeita compreensão da estrutura do sistema de
acordo com a afinidade de suas “funções”.
Seu objetivo é basicamente criar um modelo de menu,
ou organização de acesso às funcionalidades (use cases) do sistema
para uma simples orientação do uso do sistema por parte das diversas
classes de ator. Este nivelamento pode ser executado basicamente de
duas formas:
 Orientado por objeto de negócio

É uma forma, ainda, pouco utilizada devido à falta de um
conceito comum para a obtenção do Modelo de Objetos de Negócio.
Esta forma utiliza-se de um Modelo de Classes de

Objeto (abstração do DER do modelo lógico de dados) para associar a
essas “Classes de Objetos”, todas as ações do sistema que tem como
objetivo “exclusivo” mantê-las. Desta associação pode-se definir os
conjuntos de ações do sistema.
Figura: “A Associação de Objeto de Negócio e Ações do Sistema”
 Orientado pela operação do negócio
170
Esta forma utiliza-se de uma visão da operação do

negócio (estrutura de decomposição do sistema em subprocessos) para a
definição do agrupamento das “funções” Use Cases do sistema,

segundo a sua utilização nas ações do processo. O agrupamento deve
ser efetuado tomando como nível de observação do processo, os níveis
superiores de consolidação do processo.
A Modelagem de Processadores
Tem como objetivo definir a distribuição do
processamento dos Use Cases ou especificamente dos Objetos do
Sistema (FO, OE, OC). A base para a elaboração deste modelo é o
Modelo de Processo de Negócio e Modelo de Topologia dos
Processadores.
Do modelo de processo de negócio obtém-se a
informação das necessidades de processamento do sistema como
decorrência da distribuição do processamento do próprio processo de
negócio. Por exemplo:
Outros sistemas que se comunicam com sistema focado
O Modelo de Processadores pode ser representado

graficamente ou textualmente. Consiste em relacionar as ações do
171
sistema a cada processador que irá executá-las. Pode-se, também,

demonstrar o fluxo de informação que trafegará entre os processadores.
O Modelo de Controle de Acesso
Tem como objetivo definir a classe de acesso que cada
classe de ator deve ter ao conjunto de use cases do sistema projetado.
O modelo de controle de acesso é derivado do modelo de processo de
negócio onde se obtém a informação referente à classe de ator que está
apropriada a cada atividade da operação que seja do tipo use case.
Sr. Antônio B. CLASSE DE ATOR - A:

Ser. Francisco S. R. Use case 1
Use case 2
Use case 3
Use case n
Sr. Manoel P.F. CLASSE DE ATOR - B

Sr. Eduardo K. T Use case 4
Use case 5
Use case 3
Use case n
Princípios de Refinamento e Otimização
Na Mudança da Arquitetura do Processo

Utilizar a tecnologia para viabilizar a mudança da forma
de ordenação das atividades do processo. Permitir a implementação
excelente das duas formas de processamento físico (distribuição em
localidades diferentes) de processo, centralizado e descentralizado,
combinado com as duas formas de distribuição de dados (informação),
centralizada e distribuída.
Na Execução das Atividades do Processo

Utilizar a tecnologia para suportar o fluxo do processo, e
monitorar seu status de evolução em cada instanciação do processo.
Automatizar (total ou parcialmente) ações humanas que não necessitem
de conhecimento e decisão de pessoas;
172
Utilizar a tecnologia para a coordenação automática das

atividades dos processos através do monitoramento do status. Utilizar a
tecnologia para aplicação e interpretação automática de regras de
negócio.
Na Armazenagem e Tratamento da Informação

Observar a garantia de consistência e principalmente
integridade para as informações do processo. Aplicar tecnologia.
Melhorar a capacidade de análise da informação e de tomada de
decisão. Capturar e distribuir conhecimento. Capturar informação sobre
o processo, para melhor entendê-lo (métricas, performance, etc.) auto
monitoramento.
Na Melhoria da Comunicação
Aplicar, para permitir a coordenação de processos à
distância. Aplicar, para permitir interação de atividades executadas à
distância.
No Projeto de Sistemas de Informação

Projetar sistemas de informação com base nos
requerimentos funcionais e de informação derivados com base no
processo de negócio, ou seja, modelar sistemas orientados a processo de
negócio. Dotar de ergonomia e simplicidade, as interfaces homem-
máquina dos sistemas.
173
Capítulo 09
AVALIAÇÃO DE PACOTES DE SISTEMAS DE INFORMAÇÃO
Pacotes de sistemas aplicativos são ferramentas que

suportam a operação do negócio, trazem consigo modelos operacionais
não declarados que podem conduzir, por si só, a empresa para um
determinado estado de organização operacional otimizado, deteriorado,
idêntico aos dos concorrentes, ou simplesmente desconhecido.
Para obtermos o resultado esperado de uma implantação
de pacotes de sistemas aplicativos, o que normalmente é esperado como
sendo: a eficiência operacional, melhoria da segurança, controlabilidade
do negócio, velocidade na obtenção da informação, flexibilidade
relativa e compliance, é preciso avaliar a “semelhança” ou a capacidade
de adaptação do pacote à arquitetura da operação que será suportada
pela aplicação.
É fato que muitas empresas buscam soluções de pacotes
de sistemas aplicativos para “ impor” à sua operação uma arquitetura de
“boas práticas”, e isso certamente pode ser considerado adequado
quando estamos tratando de funções ou módulos da aplicação maduras
que suportam operações commodities de cadeias de valor como: Gestão
de recursos financeiros, Controladoria, Gestão de recursos humanos,
etc.
Como vimos no capítulo “Atividades”, quanto mais a
operação for associada ao core do negócio, menos commodity será sua
arquitetura, mais específica para a empresa ela será afim de preservar,
muitas vezes, o diferencial operacional em relação aos concorrentes.
Nesta situação a tarefa da escolha e implementação de
pacotes de sistemas aplicativos fica mais complexa e repleta de
variáveis. Há ainda o risco de escolher e implementar pacotes de
174
sistemas aplicativos orientados à arquitetura da operação do negócio a

ser suportado, e esta arquitetura não estar madura, mas sim, repleta de
falhas que comprometem a performance no negócio, neste caso teremos
um projeto de resultados frustrantes caso não venhamos a realizar
primeiro ou concomitantemente uma revisão da arquitetura da operação.
Então avaliar e implementar pacotes de sistemas
aplicativos é uma tarefa que depende do domínio de três variáveis
fundamentais: arquitetura do pacote, arquitetura de informação e
arquitetura de negócio da operação alvo. Se desconhecermos essas
variáveis, então, teremos um grande problema a ser vivenciado no
projeto!
Este capítulo tem o objetivo de explorar, à luz da EA e
do BPM – M, uma forma prática de garantirmos um nível mínimo de
domínio sobre o processo de avaliação e implantação de pacotes de
sistemas aplicativos.
1) Categorias de pacotes de sistemas aplicativos

Para efeito de estudo relacionamos as categorias de
software que são pertinentes ao objetivo deste capítulo. Existem muitas
outras categorias de pacotes e ferramentas que não estão diretamente
ligadas o tema de nossa obra.
a. Pacotes de suporte à operação de negócio

Nesta categoria encontramos os pacotes de sistemas
aplicativos que tem como missão suportar a operação e gestão do
negócio. São aplicações que normalmente dispensam desenvolvimento
de código e possuem recursos de configuração para se adaptar às
necessidades do negócio. Aplicações das categorias como as que
seguem, são exemplos de pacotes de suporte à operação de negócio:
ERP (Enterprise Resource Planning), TMS –
transportation management system, LMS – labor management system,
WMS – warehouse management system, YMS – yard management
system, TOS – Terminal operation system, MRP II – Master resource
planning, SMS – School Management System, MMS – Maintenance
Management System, HMS – Hotel Management System, HMS –
Health Management System, RMS – Risk Management System, VMS –
175
Vendor Management System, HSEMS – Health, Safety and

Environmental Management System, DMS – Distribution Management
System, FMS – Flight Management System.
Essas aplicações contêm de forma explícita ou implícita
uma arquitetura de operação. As aplicações mais maduras possuem
recursos de configuração que permitem ajustar sua arquitetura, dentro
de um intervalo de ajuste, à arquitetura da operação. Para sua adequada
avaliação e implantação, a utilização da arquitetura de negócio e de
informação é fundamental.
As funcionalidades estão associadas a casos de uso,
atividades dos processos de negócio e podem ter sua lógica
compreendida na sequência de execução dos processos de negócio.
Interferem diretamente na eficiência, eficácia, segurança e flexibilidade
da operação de um negócio.
b. Ferramentas de orquestração ou automação de processos de

negócio
Nesta categoria encontramos as aplicações que são
ferramentas que são uma plataforma de desenvolvimento e recursos
para orquestração de processos de negócio. Genericamente
denominadas de BPMS – Business Process Management Systems.
Por serem de aplicação genérica, prescindem de
configuração e codificação para suportar a um processo específico.
Normalmente estão estruturadas em quatro grupos funcionais:
Modelador de processo, codificador e gerador de script, motor de
orquestração, monitor de processamento.
Para sua aplicação é necessária a definição da arquitetura
do processo a ser orquestrado, os pontos de controle, tempos de
referência de processamento, matriz de responsabilidade, mensageria,
etc. Os produtos mais maduros permitem a integração com aplicações
específicas nos passos do processo orquestrado.
Interferem diretamente na eficiência, eficácia, segurança
e flexibilidade da operação de um negócio.
c. Ferramentais de gestão de performance empresarial
176
Nesta categoria classificamos as ferramentas de EPM –

Enterprise Performance Management e/ou ferramentas de BI –
Business Intelligence. Essas aplicações são plataformas que tem como
missão básica a análise e apresentação de informações para a apuração
de indicadores chave para o monitoramento de performance do negócio
ou investigação de tendências diversas. São aplicações, ferramentas,
que também prescindem de desenvolvimento e configuração para
geração do seu produto.
Podem ser compostas por recursos de ETL – Extração
Tratamento e Carga e Construção/Divulgação de Dashboards
multidimensionais.
Não interferem diretamente na eficiência; eficácia;
segurança e flexibilidade da operação de um negócio. Podem contribuir
para com a melhoria do controle da operação de negócio.
d. Ferramentas de gestão de conteúdo

Nesta categoria classificamos as ferramentas de ECM –
Enterprise Content Management. Essas aplicações têm como missão
básica a classificação, armazenagem e recuperação segura e organizada
de conteúdos em diversas mídias: documentos, e-mails, plantas, sons,
textos, imagens etc.
São aplicações configuráveis e podem ser compostas por
recursos que suportam o ciclo de vida integral de conteúdo: captura,
classificação, armazenagem, consulta, recuperação, circulação, e
descarte de conteúdo.
Interferem de forma indireta na eficiência, eficácia,
segurança da operação de um negócio.
2) Definição do Contexto operacional do projeto de Implementação

de Pacote de sistemas aplicativos
O primeiro passo para assegurar o sucesso do projeto é a
definição do contexto operacional que será alvo de suporte do pacote de
sistema aplicativo.
Para definirmos o contexto operacional alvo utilizamos a
Arquitetura de Negócio através da identificação das Cadeias de Valor e
seus respectivos Processos de Negócio que serão suportados pelo pacote
de sistema aplicativo.
177
Esta fase deve ocorrer antes da definição dos pacotes de

sistemas aplicativos a serem avaliados. Nela construímos a arquitetura
de Cadeia de Valor e a lista de seus respectivos Processos de Negócio

como vimos no capítulo “Atividade”. Uma vez construída a arquitetura,
definimos restrição de abrangência de cobertura funcional do pacote,
selecionando, de acordo com as expectativas da Organização, as cadeias
de valor e processos de negócio da Arquitetura que serão o contexto de
suporte dos pacotes de aplicação a serem avaliados. Veja lista exemplo:
Cada processo deve ter seu objetivo descrito de forma
sucinta e breve a fim de orientar a interpretação da lista.
Nesta abordagem é fundamental termos identificados os
processos alvo visto que deverão ser o drive da configuração, teste e
implantação, um a um.
A abrangência da cobertura funcional do pacote de
sistema aplicativo a ser avaliado está diretamente relacionada ao
conjunto de Cadeias de Valor e Processos de Negócio relacionados no
contexto do projeto.
Por exemplo, um pacote CRM (customer relationship
management) está associado ao suporte a um conjunto de processos de
negócio que estão contidos nas cadeias “conquistar e manter cliente”;
“prestar serviço a cliente” e outras dependendo da Vertical do negócio;
um pacote de WMS (Warehouse Management System) ou TMS
178
(Transportation Management System) estão associados às cadeias de

valor de inbound e outbound “gerir suprimento de mercadoria”, “gerir
distribuição de mercadorias”, um pacote de ERPS (Enterprise Resouce
Planning System) está associado às cadeias de valor commodities como
“ planejar operação”, ”controlar operação”, gerir recursos financeiros”,
“gerir compliance”, “gerir recursos humanos”, “conquistar e manter
cliente”, “gerir fabricação de produto”, “gerir suprimento de bens e
serviços”, etc.
Pacotes especialistas tem, normalmente, uma
abrangência de suporte funcional mais restrita como por exemplo
Soluções Fiscais, estão associadas a alguns processos específicos dentro
da cadeia “controlar operação” e “ Gerir compliance”.
3) Definição dos pacotes a serem avaliados

Com base nas informações de marcado selecione os
pacotes de sistemas aplicativos que tem a amplitude de cobertura
funcional correspondente ao Contexto Operacional a ser suportado
pela solução.
Evite a escolha de aplicações sem ter a noção exata do
que é necessário em termos de amplitude de cobertura funcional, essa
situação pode se tornar uma armadilha com a aquisição de soluções que,
posteriormente, são descartadas. Nem todos os fornecedores se
empenham em entender as necessidades operacionais para ofertarem
seus produtos e, de fato, essa responsabilidade é de ambas as partes e
deve balizar as conversações iniciais de expectativas sobre cobertura
funcional.
É claro que o ideal em um processo de escolha de
solução é que tenhamos a maior cobertura funcional possível dentro de
uma mesma solução de pacote de sistema aplicativo. Os motivos são a
provável simplicidade de implementação sem integrações complexas e
arriscadas, unicidade de plataforma de DBMS e Linguagem, menor
risco e custo de continuidade e manutenção.
179
Atenção especial deve ser dada para os pacotes

aplicativos declarados como passiveis de integração nativa,
normalmente pacotes “satélites” que complementam a cobertura
funcional de pacotes principais, normalmente ERP’s; e foram
desenvolvidos na mesma plataforma com integração nativa
garantida pelos fornecedores. Essas relações oferecem um menor
risco e custo no que se refere a implantação e manutenção.
4) Definição de Requisitos para Avaliação de Aderência dos Pacotes

de Sistemas Aplicativos
Este é um item de absoluta importância para o processo
de avaliação e implementação de pacotes de sistemas aplicativos.
Invariavelmente presenciamos processos que mergulham
nas profundezas do detalhamento de requisitos funcionais ou se valem
de definições muito rasas e amplas na primeira fase de avaliação,
gerando um custo elevado de definição e análise ou criando uma
situação de relativo risco na escolha quando adotada a generalização
dos requisitos.
Recomendamos que você utilize, para cada fase do
processo de avaliação e implementação, um nível diferente de
detalhamento, tendo como foco a velocidade, risco e o custo de cada
uma dessas fases.
a) Fase de avaliação preliminar

Utilizamos esta fase para descartar ou selecionar pacotes
candidatos quando temos muitas opções participando do processo de
seleção.
Para esta fase recomendamos a utilização da Arquitetura
de Cadeia de Valor e Macroprocessos de negócio como mapa de
contexto operacional. Cada processo deve ser descrito com a definição
sucinta de sua missão o que ele faz, e não como ele faz.
Ao avaliarmos a existência de cobertura funcional para
cada processo, independentemente do detalhe de como é o
processamento, podemos garantir que os fornecedores das soluções
suportam ou não cada processo, mesmo que cada qual à sua maneira
(arquitetura). Essa comparação de requisitos permite a classificação das
180
soluções de pacotes de sistemas aplicativos segundo sua cobertura por

processo. É possível de uma forma rápida, segura e de baixo custo,
identificar os pacotes candidatos que mais se aproximam da cobertura
desejada pelo projeto e seleciona-los para seguir o processo de escolha.
Nesta etapa recomendamos que sejam dados pesos para
cada processo de acordo com sua importância para a operação do core
business. Isso evita uma avaliação equivocada da pontuação final onde
temos candidatos com pontuações semelhantes, porém, coberturas
diferentes em termos de processos críticos, os quais devem ter maior
relevância na avaliação. Desta forma, recomendamos que os processos
sejam classificados em 4 (quatro) níveis de criticidade para operação do
negócio, a saber:
● Grau 3:
Afeta de forma direta a continuidade da produção, a
qualidade percebida do produto pelo cliente, a rápida resolução de
problemas para o cliente, a satisfação e segurança do cliente com a
entrega;
● Grau 2:
Afeta o suprimento de recursos (materiais e financeiros)
para a operação, a legalidade da operação do negócio;
● Grau 1:
Afeta o planejamento e controle da operação do
negócio;
● Grau 0:
Não afeta de forma direta continuidade da operação do
negócio, seu controle ou suprimento de recursos;
● Nível de Atendimento do requisito:
Não é recomendada a utilização do nível de atendimento
“EXCEDE”, pois a lista de quesitos e requerimentos devem possuir
somente os componentes considerados suficientes – necessários, o que
impossibilita a existência de algo que exceda a especificação, o que
corresponderia a um quesito não declarado.
TÍTULO DESCRIÇÃO VALO

R
AT-Atende Possui funcionalidades 1,0
181
Totalmente que suportam

plenamente ao objetivo
do processo
AP-Atende Possui alguma 1,5
Parcialmente funcionalidade que
suporta parcialmente ao
objetivo do processo
NA-Não Não possui nenhuma 0,0
Atende funcionalidade que
suporte o objetivo do
processo
A condução dessa avaliação sem a referência de

Arquitetura de Cadeia de Valor e macro processo de negócio pode gerar
os seguintes efeitos indesejáveis:
● Incapacidade para avaliar os pacotes com clareza

e autonomia, tornando-se vulneráveis aos argumentos envolventes e
subjetivos de cada fornecedor.
● Aquisição de soluções que, na realidade, não
atendem às reais e essenciais necessidades operacionais da empresa,
gerando desgaste na operação ou abandono parcial da solução.
● Equipes de implementação desorientadas e em
constante conflito devido ao desconhecimento do modelo de operação
adequado, resultando em longos e caros projetos de implementação.
● Descrédito do processo de transformação, perda
ou decréscimo da capacidade de conduzir o processo de aprimoramento
operacional.
b) Fase de avaliação final

Esta fase visa avaliar a aderência funcional final de cada
pacote de sistema aplicativo candidato.
Nesta fase recomendamos a utilização do mesmo mapa
de contexto operacional constituído de cadeias de Valor e Processos de
Negócio, porém, agora com a especificação dos requerimentos
funcionais definidos individualmente para cada processo de negócio.
182
Como requerimento funcional de cada processo

utilizamos três componentes da arquitetura de negócio: Descrição do
requerimento funcional de Caso de Uso, Titulação da regra de negócio
(quando existir) e Produto gerado pelo processo (quando existir). Os
requerimentos funcionais devem ser referentes ao desdobramento do
objetivo sucinto do processo (o que ele faz) e não deve se ater a
detalhes de como é implementado.
Da mesma forma que na avaliação preliminar
recomendamos utilizar o nível de criticidade do processo para ponderar
o peso de cada requerimento do respectivo processo de negócio.
Como resultado da avaliação teremos uma classificação
dos produtos dos fornecedores com o incide de aderência para cada
requerimento individual sumarizado por processo de negócio, e cadeia
de valor. Essa classificação nos permite avaliar a aderência do pacote de
sistema aplicativo a cada processo e identificar os pontos francos e
fortes de cada produto possibilitando a análise de uma composição e
produtos para atender ao contexto de cobertura funcional do projeto se
isso for interessante.
A especificação dos requerimentos funcionais de cada
processo pode ser obtida através de entrevistas rápidas com os
Especialistas e Gestores de cada processo. É possível usar a mesma
matriz de responsabilidades definida para criação da arquitetura
multidimensional dos processos, e é importante que os requerimentos
sejam homologados após serem coletados e compilados.
● Nível de Atendimento do requisito:
TITULO DESCRIÇÃO VALO

R
AT-Atende Possui a funcionalidade 1,0
Totalmente requerida
AP-Atende Possui parcialmente à 1,5
Parcialmente funcionalidade requerida.
NA-Não Não possui a 0,0
Atende funcionalidade requerida
c) Fase de configuração e customização

183
Nesta fase o pacote de sistema aplicativo já foi escolhido

e a aquisição foi realizada. O grau de assertividade desta fase, no
tocante a especificação de requerimento deve ser total. Para isso
recomendamos a atualização da Arquitetura Multidimensional de cada
processo de negócio considerando duas categorias de processos para um
tratamento de configuração e customização diferenciado:
● Processos com arquitetura consideradas commodity para o

mercado são aqueles processos de negócio classificados com nível de
criticidade 0, 1 ou 2 e de arquitetura comum ao mercado, tais como:
gerir contas a pagar, comprar bens e serviços, recrutar e admitir
colaborador, entre outros.
Para os processos com arquitetura commodity
recomendamos a configuração da aplicação através da validação do
próprio modelo de processo implícito na aplicação. Adotar as práticas
de operação de negócio embarcadas nos pacotes de sistemas aplicativos
que tenham maturidade tem se mostrado, nesses casos, muito adequado
para se obter um bom nível de eficiência, eficácia e segurança nos
processos suportados, isso sem onerar o custo de implantação da
solução.
Caso o pacote de sistema aplicativo não possua um
modelo explicito da arquitetura do processo suportado, recomendamos
criar um modelo referência da arquitetura proposta pelo pacote; crie um
modelo de processo com as atividades e use cases disponibilizados pela
aplicação e verifique sua integridade perante as necessidades da própria
empresa.
● Processos com arquitetura considerada específica
da empresa, que são normalmente os processos com nível de criticidade
“3” e eventualmente “2”.
Para os processos com arquitetura específica e particular
recomendamos a configuração da aplicação com base em Casos de Uso
definidos na arquitetura multidimensional de cada processo de negócio.
Conforme descrito no capítulo “ATIVIDADE” a
construção da arquitetura otimizada do processo deve conter as
atividades manuais e as suportadas pela aplicação (casos de uso). Nas
184
atividades do tipo casos de uso devem ser descritos, de forma objetiva,

os requerimentos funcionais para sistemas aplicativos.
Cada caso de uso mapeado na arquitetura do processo de
negócio deve ser associado a(s) respectiva(s) funcionalidade(s) do
sistema aplicativo, definindo-se assim o mapeamento do uso das
funcionalidades da aplicação, isso deve ser feito através do
endereçamento de seus itens de menu a cada use case do processo.
A correlação entre Use Case e “Função” da Aplicação (item do

menu)
Nesta fase identificamos cinco condições de aderência

das funcionalidades do sistema aplicativo aos requerimentos funcionais
do processo:
a. AT – Atende Totalmente: Não há perdas para

arquitetura do processo e para o sistema aplicativo. Os componentes
185
do pacote de sistema aplicativo são configurados para suportar o

processo de negócio conforme os requerimentos do caso de uso, são
usados os recursos de configuração disponíveis no sistema aplicativo;
b. AT – Atende com Ajustes: Os componentes da
arquitetura do processo são ajustados, sem perda de qualidade para
o processo de negócio, para se utilizar as funcionalidades nativas do
pacote de sistema aplicativo, considerando a forma com que o sistema
aplicativo propõe a execução do Use Case;
c. AP – Atende Parcialmente: Os componentes
do sistema aplicativo são customizados para suportar à operação
conforme o requerimento do caso de uso . Esta situação é identificada
quando não é possível abdicar das características do requerimento
funcional do use case sem perdas significantes para a operação do
processo de negócio.
d. NA – Não Atende: Precisam ser construídos
novos componentes funcionais no pacote de sistema aplicativo para
serem “conectados e/ou adicionados” a sua arquitetura. Esta
situação ocorre quando não é possível abdicar dos requerimentos
funcionais do Use Case sem perdas significantes para a operação do
processo de negócio.;
e. NA – Não Atende: Os componentes da
arquitetura do processo são ajustados, com perda de qualidade
para operação do processo de negócio, mediante a forma com que o
sistema aplicativo propõe a realização do Use Case;
Os itens “A” e “B”, acima, são as situações de aderência

consideradas benéficas para um projeto de implementação de pacote de
sistema aplicativo, pois os ajustes mantêm-se dentro dos intervalos de
tolerância natural tanto do sistema aplicativo quanto do processo de
negócio e não há perdas de eficiência, eficácia, segurança e
flexibilidade para o processo de negócio;
Os itens “C”, ”D” e “E”, acima, normalmente são
alternativos entre si, e são as situações de aderência consideradas
inadequadas porem aceitáveis para um projeto de implementação de
pacote de sistema aplicativo. O impacto das perdas e do
186
desenvolvimento devem ser medidos em termos de prazo, custo e risco

a fim de avaliar qual opção é a mais adequada.
As opções “D” e “E” devem ser abordadas como projetos
de desenvolvimento de novas funcionalidades para o sistema aplicativo
e suportadas por artefatos conforme recomendamos no capítulo
“projeto de sistemas aplicativos”. Ao final do mapeamento teremos
uma associação das arquiteturas de negócio e da aplicação.
5) Testes, Homologação e Treinamento

Quando
6) Avaliação dos demais requisitos do pacote de sistema aplicativo
A avaliação completa de um pacote de sistema aplicativo

depende de outros fatores que não estão diretamente associados a
arquitetura de negócio ou de informação. Esses fatores também devem
ser avaliados em conjunto com a aderência aos requisitos funcionais
para se obter um quadro completo da classificação das aplicações
candidatas. Recomendamos dez grupos de requisitos como segue:
187
1. Requerimentos Tecnológicos;
2. Condições Contratuais;
3. Estrutura de Suporte e Manutenção;
4. Informações de Mercado;
5. Treinamento e Implantação;
6. Características Conceituais Básicas;
7. Requerimentos Funcionais Específicos da Operação Suportada;
8. Requerimentos de Informação Específicos da Operação
Suportada;
9. Confiabilidade e Segurança dos Dados;
10. Documentação Fornecida.
A seguir apresentamos um dos possíveis desdobramentos dos grupos de

requisitos.
I. Requerimentos Tecnológicos
● Plataforma de Processamento
● Ambiente (Operacional, Rede, Web, mobile)
● Arquitetura de Construção
● Ferramenta de desenvolvimento
● Implementação de Regras de Negócio (Stored Procedures,
executáveis etc.)
● Banco de Dados (Arquitetura de Banco, DBMS Requerido, Tipo de
Acesso - nativo, ODBC)
● Recursos nativos, Codificação (Construção/Customização de Telas,
Instalação automática de novas versões
● Customização da base de dados
● Customização de menu funcional
● Interface com Ferramentas de BACK OFFICE
● Requerimento de configuração de processadores (Máquina Servidor
de Dados, Máquina Servidor de Aplicações, Máquina Servidor
WEB, Máquina Client)
II. Características Contratuais

● Cobertura de Correção de problemas (Bugs ou disfunções
conceituais)
188
● Cobertura de novas funções pelo contrato de manutenção

● Garantia de operação no ambiente operacional contratado
● Disponibilidade de Fontes em caso de Dissolvência ou Mudança de
Foco/Produto/Estratégia
● “Localização” (Comprometimento com a atualização da
‘localização” mediante mudanças legais)
● Garantia de upgrade de versões sem comprometimento da base de
dados corrente.
● Garantia do tempo de atendimento e correção de problemas
III. Informações De Mercado

● Base instalada na plataforma contratada
● Informações sobre estabilidade e continuidade no mercado
● Abertura para possíveis Alianças ou Parcerias Comerciais
● Referências de Parceiros
● Referências de Concorrentes
● Referências de Clientes Atuais
IV. Suporte E Manutenção

● Proximidade física da equipe de suporte
● Suporte Local Técnico e conceitual
● Serviço “Hot Line” para consultas
● Serviços disponíveis (Internet, etc.)
V. Treinamento e Implantação
● Método de Implantação
● Garantia de treinamento para a equipe de interna de suporte e
desenvolvimento/manutenção
● Garantia de treinamento operacional para a equipe de usuários
● Transferência de Competência
● Proximidade da equipe de treinamento
● Garantia de treinamento para as novas versões
VI. Características Conceituais Básicas

● Multiempresa
● Multiusuário
189
● Multimoeda
● Recurso de Download e Upload para processadores portáteis
● Recursos de geração de relatórios transacionais
● Adm. do Controle de acesso flexível
● Nível de Parametrização
● Organização dos menus
● Help ON-LINE
VII. Requerimentos Funcionalidades Específicas Da Operação

Suportada
● Atendimento aos requerimentos de Use Cases (ação, produto,
aplicação regra de negócio)
● Suporte e controle de Workflow
VIII. Requerimento De Informação Específica Da Operação

Suportada
● Objetos de Negócio
● Elementos de Dados
● Regras de Relacionamentos (business constraints)
IX. Confidencialidade e Segurança

● Controle de acesso por Usuário
● Controle de acesso por Funções
● Controle de acesso por Perfil
● Log de Transações (Operador, Hora, etc.)
● Histórico de Movimentações
● Trilha para Auditoria
X. Documentação Fornecida
● Manual de usuário
● Manual de sistema
● Documentação técnica de suporte, manutenção e desenvolvimento
● Modelo de dados inteligível
● Documentação disponível no idioma desejado
190
7) Um pouco da História: O Difícil Começo dos Softwares de

Gestão no País
Boa parte das empresas que gastaram muito dinheiro e
tempo para introduzir pacotes de sistemas aplicativos, em sua
maioria ERP’s questionam os primeiros resultados, aponta uma
pesquisa da Fundação Getúlio Vargas realizada no final da década de
1990.
Ninguém resistiu ao último dos modismos da
computação corporativa. Todas as grandes empresas e, mais
recentemente, até o chamado mercado intermediário sucumbiram às
promessas de um software de gestão que amarra todos os processos
da companhia, do RH à encomenda de produtos, do controle de
estoques ao cálculo do lucro. Nem o preço astronômico ou a difícil
implantação foram obstáculos. Afinal os concorrentes estavam
mergulhando de cabeça nessa onda e não daria para perder o bonde
da racionalização digital de processos e ser taxado de jurássico mais
tarde.
Três anos depois da chegada dos ERP (Enterprise
Resource Planning) ao Brasil e muitos milhões de dólares a mais no
caixa das empresas de software e das consultorias que implementam
o sistema, as organizações começaram a avaliar os primeiros
resultados concretos dos projetos concluídos no País. E a eterna
dúvida sobre os benefícios práticos trazidos pelos investimentos em
tecnologia ainda não encontra uma resposta satisfatória.
Segundo o estudo da FGV, na época, 45% das empresas
consultadas não perceberam melhoria da vantagem competitiva e
43% não verificaram uma redução dos ciclos produtivos vantagens
que, segundo os especialistas, deveriam ser automáticas e 40% não
notaram ganho ao consumidor. “Os resultados são decepcionantes se
comparados ao dinheiro investido”, diz Thomaz Wood Junior,
professor do departamento de Produção da Escola de Administração
de Empresas da Fundação de Getúlio Vargas e um dos autores do
estudo.
191
A pesquisa foi realizada com 28 companhias de

diferentes áreas, como metalúrgica, farmacêutica, químicas e papel e
celulose, sendo que 85% delas são subsidiárias de multinacionais.
Para concluir o trabalho, foram realizadas 57 entrevistas, entre
diretores, consultores e os profissionais responsáveis pela
implantação do sistema “Muitas empresas estão colocando tempo,
dinheiro e energia em projetos mal elaborados, sem avaliar a
estratégia e visão de futuro da empresa”.
Resultados
O impacto nas empresas que adotaram softwares de gestão
45% não tiveram aumento da competitividade
43% não reduziram ciclos (estoques, rotinas administrativas processos
decisórios).
40% não registraram ganho ao consumidor.
36% buscavam ganhos em tecnologia da informação
24% estavam focadas no lado humano e na transformação
25% refariam a implantação de outra maneira
192
Capítulo 10
RECURSOS HUMANOS
Em contraposição às escolas humanistas, a preocupação

do BPM – Multidimensional é estabelecer uma base cartesiana para
compreensão da razão existencial das pessoas dentro das organizações
produtivas.
Essa base cartesiana é estabelecida através da
compreensão da relação direta entre classes de pessoa e atividades
engenhadas no modelo de processo de negócio.
A abordagem baseada no BPM – Multidimensional é
uma abordagem Top-down e Botton-up. Em sua abordagem Top-down o
BPM-M recomenda o alinhamento com as classes de médio comando
ou média gerência, com as cadeias de valor e grupos de macroprocessos
que demandam competência especializada de gestão, enquanto na
abordagem Botton-up recomenda-se a definição de classes operacionais
para cumprir papéis responsáveis por atividades planejadas e
repetitivas do modelo de negócio definido na arquitetura de processos
através do BPM-M.
Acreditamos que esta “abordagem cartesiana” deve ser a
base para a aplicação de qualquer abordagem humanista, pois julgamos
ser ilusório pressupor que pessoas podem se sentir felizes e realizadas
dentro de uma organização sem conhecer a verdadeira razão de suas
existências neste contexto.
193
A construção de um modelo operacional robusto e

completo deve dar atenção à dimensão Recursos Humanos, visto que as
Classes de Ator existentes na empresa constituem a força de
processamento predominante a ser transformada em qualquer modelo
de processo de negócio.
 1 - O Conceito de Modelo de Recursos Humanos no BPM -

Multidimensional
Como Modelo de Recursos Humanos, compreendemos
o conjunto de definições referentes às CLASSES DE PESSOA, que
constituem o ativo físico mais importante da empresa:
● Identificação das classes;
● Qualificação das classes;
● Quantificação das posições de trabalho das classes;
● Estruturação da organização e comando das classes;
● Determinação do modelo de distribuição física das posições de
classe.
Na realidade, falamos sobre a derivação dos requerimentos
de recursos humanos a partir dos processos de negócio da empresa, uma
vez que estas classes de pessoas têm sua razão existencial justificada
pelos próprios processos de negócio, assim como aquelas classes de
comando e Gerenciamento que existem em função das classes de
pessoas dedicadas à operação dos negócios.
 2 - Derivação dos Requerimentos Organizacionais

A derivação dos requerimentos de recursos humanos se
dá através da extração das classes de pessoas, já definidas e apropriadas
às atividades, a partir dos modelos de processo de negócio, mais
especificamente a partir do nível atômico do processo de negócio, onde
encontra-se a associação de classes de pessoas a atividades.
 3 - Identificação das classes de pessoa
Classe de Pessoa é o conceito utilizado para identificar

um “Papel” a ser representado por pessoas físicas ou jurídicas,
indivíduos ou seus agrupamentos, no contexto de determinada processo
194
de negócio. A uma classe de pessoa pode estar associada um conjunto

de atividades estabelecidas como sua “responsabilidade”. Surgem como
sujeitos dos eventos de negócio ou destinatários de outputs do processo.
“Classe de pessoa, papel a ser desempenhado por uma ou um conjunto

de pessoas”
ATIVIDA JUSTIFICA
DE A A
EXISTÊNCI
A DE
CLASSES DE
PESSOAS
definição de Classe de Pessoa deve ser feita, no
BPM – Multidimensional, no momento posterior à Definição de
atividades procedurais, a qual é concebida e configurada mediante a
influência recíproca da definição de Regras de Negócio, Suporte
Tecnológico e Informação. Definir Classe de Pessoa neste contexto
significa estabelecer um papel de pessoa adequado para execução de um
conjunto de determinadas atividades.
É natural que na maior parte das situações onde o BPM
Multidimensional é aplicado as classes de pessoa já existam e todas as
pessoas que as ocupam também, neste caso, uma maior atenção deve
ser dada às pessoas que ocupam a classe em transformação. Esta
atenção pode ser dada através da utilização de métodos de qualificação
de perfil pessoal, um dos métodos que consideramos está comentado no
tópico PAEI.
Caso as classes de pessoa existentes não satisfaçam à
conclusão da análise preliminar, pode-se chegar à necessidade de
criação de novas classes.
A definição da classe de pessoa adequada como
responsável pela execução das atividades, deve levar em consideração,
em sua primeira instância, os seguintes componentes:
● a aparente competência e conhecimento requerido;
● a aparente autoridade requerida;
195
● o aparente perfil pessoal requerido.
Titulação da Classe de Pessoa:

Deve-se titular uma classe de pessoa através da
identificação da(s) “classe(s)” do conjunto de atividades evidenciando-
se a principal, de modo que seja possível diferenciá-la das demais
existentes na empresa, isto pode ser feito com base em:
A - Classe funcional e/ou classe/atividade específica;

B - Senioridade ou nível de expertise;
C - Assunto (Processo) ou Objeto de Negócio “manipulado &
processado”.
Considerando uma possível estrutura de formação podemos

considerar:
a- Prefixo: Determina a palavra referente à classe funcional ou ao nível

funcional (hierárquico) ou à especialidade de execução em uma
determinada classe de atividade pela classe de pessoa.
Ou
O QUE - a classe faz
Ex.: diretor, coordenador, líder, programador, analista, operador,
mecânico.
b- Fixo: determina a palavra referente à classe de assunto ou objeto de

negócio/grupo preponderante no conjunto de responsabilidade da
classe de pessoa.
Ou
SOBRE O QUE FAZ
Ex.: Risco, produção, implantação, recrutamento, faturamento,
qualidade, recursos humanos, Materiais, Sistemas, patrimônio,
Recursos Financeiros, Orçamento, Produto, Produção, Manutenção
Elétrica.
196
c- Sufixo: Determina a palavra referente à senioridade/nível de

expertise ou condição classificatória da classe de pessoa.
Ou
COMO FAZ (QUALIDADE)
Ex.: especialista, adjunto; sênior, pleno, júnior, trainee, interino.
Líder - de produto - sênior
A composição do título da Classe de Pessoa dever ser

preferencialmente de três palavras e sempre que possível no singular. A
titulação das classes de pessoa deve obedecer sempre que possível aos
dispositivos constantes da consolidação da legislação trabalhista e/ou
às determinações do catálogo brasileiro de ocupações – CBO.
- Quando no exercício das funções é exigida a aplicação
do pleno conhecimento da profissão, deve-se seguir a legislação
específica;
- Quando no exercício das funções não é exigida a
aplicação do pleno conhecimento da profissão, deve-se criar a
classificação própria da empresa.
NOTA: A utilização do sufixo é opcional, visto que na

realidade quem Sênior, Júnior ou Pleno é a pessoa ocupante da classe de
pessoa e não especificamente a classe, tal denominação faz referência,
por exemplo, a fatores como habilidades e experiência.
 4 - Qualificação das classes de pessoas

As organizações podem ser concebidas como sistemas de
papeis. Cada indivíduo que ocupa uma posição na organização é
solicitado a desempenhar um papel executando um conjunto de
atividades e mantendo determinados comportamentos.
Somente a partir do momento em que as pessoas passam
a desempenhar papeis específicos é que as organizações começam a
funcionar adequadamente. Por isso, as organizações procuram
selecionar seus empregados de forma tal que passem a cumprir seus
papéis com a máxima eficácia.
197
Super-classe de Pessoas
Esta é uma forma de classificar as classes de pessoa
quanto à sua “grandeza” no mundo real. Uma Entidade Externa
(empresa) contém Unidades Organizacionais, uma Unidade
Organizacional (diretoria, depto, divisão, sessão) contém colaboradores.
A responsabilidade sobre as atividades do processo deve,
prioritariamente, ser atribuída às superclasses Colaborador ou Entidade
Externa. Unidades Organizacionais devem ser evitadas por serem
“etéreas” do ponto de vista de execução de atividades.
❑ Colaborador ou funcionário
É a especialidade mais significativa do modelo

operacional e representa as pessoas físicas responsáveis pela execução
das atividades procedurais (atômicas) do processo, ou as pessoas físicas
responsáveis pelo comando daquelas que executam as atividades. Estão
sempre obrigatoriamente associadas a atividades procedurais.
❑ Unidade organizacional
Representa o agrupamento de um conjunto de pessoas do

tipo “operador” cada qual pertencente a uma classe diferente. Somente
podem ser associadas a atividades sumárias (macro processos e
subprocessos). Surgem na criação das estruturas organizacionais
(organogramas).
198
❑ Entidade Externa
Classificamos como Entidade Externa toda classe de

pessoa, física ou jurídica, que está fora do contexto do processo
abordado e/ou fora do contexto da empresa abordada. É a superclasse
para a qual se destinam os outputs do processo, ou se originam inputs,
sejam eles estímulos do processo (gatilhos – eventos) ou não. Podem
ser Stakeholders do processo.
METACLASSE de pessoas
Esta é uma classificação das classes de pessoa segundo
seu envolvimento e conhecimento sobre a arquitetura do processo de
negócio.
❑ Operador:
É efetivamente a Classe de Pessoa que está envolvida

com a execução das atividades “procedurais” do processo. Portanto são
conhecedores dos “detalhes” operacionais do negócio. Esta metaclasse
detém conhecimento muito detalho, profundo e pontual, restritos ao
âmbito de suas atividades. Como classe de pessoas contidas nesta
metaclasse, podemos ter:
Ex.: Auxiliar de compras, comprador de bens e serviços,
analista de recursos financeiros, vendedor de produtos, auxiliar de
administração, porteiro, etc.
❑ Especialista no Processo:
É Metaclasse de Pessoa que pode tanto estar envolvida

com a execução de atividades “procedurais” como com atividades de
“comando” do processo. É uma metaclasse que detém conhecimento
sobre a arquitetura do processo a um nível detalhe suficiente para a
compreensão de toda cadeia de atividades, ou um trecho específico,
bem como as interações com outros processos. Como classe de pessoas
contidas nesta metaclasse, podemos ter:
199
Ex.: Especialista de crédito, Coordenador de Compras, Lidere de

recebimento, etc.
❑ Gestor do Processo (comando):
É a Metaclasse de Pessoa é responsável pela gestão e

comando do processo. Ela detém conhecimento referente à missão,
estratégia, pessoal, performance, relações com entidades externas e
problemas de alto nível do processo. Normalmente o gestor do processo
possui autoridade investida para tomar decisões sobre a arquitetura do
processo, e é o canal de comunicação direto com níveis superiores de
comando da empresa e com seus pares responsáveis por outros
processos.
Ex: Gerente de Suprimentos, Gerente comercial, Diretor de produto,
Chefe do Depto. de Crédito, etc.
❑ Stakeholder:
Esta Metaclasse de Pessoa representa o “cliente” do

processo abordado. Aquele que recebe o produto do processo direta ou
indiretamente. É a metaclasse capaz de avaliar a qualidade das Relações
com Mercado (recepção da demanda e produto do processo) sem ter a
visão da arquitetura interna do processo. Ela fornece conhecimento
sobre qualidade e problemas do vista externo do processo, enquanto o
gestor/especialista e operador fornecem conhecimento a partir de vista
interno. Um stakeholder pode pertencer à Superclasse “entidade
externa” ou ainda ser mesma pessoa que ocupa a metaclasse “gestor”
de um processo que sucede ao processo estudado.
Definição das Responsabilidades
200
É a exposição ordenada das tarefas ou atribuições de um cargo.

Descrição do que o ocupante do cargo faz, como faz e por que faz.
Avaliação de cargos consiste no estabelecimento do

valor relativo de cada cargo, com o objetivo de ordená-los de acordo
com sua importância na empresa. É por meio desse processo que a
empresa estabelece um sistema para determinar a remuneração a ser
aplicada. Constitui, pois, o instrumento mais adequado para promover o
equilíbrio interno da política de remuneração.
Especificação dos Requisitos da Classe de Pessoa
Consiste na identificação dos requisitos necessários para

o desempenho das tarefas ou atribuições (conjunto de atividades que
compõem o quadro de responsabilidades) da classe de pessoa. Ela deve
abranger a especificação de:
❑Características físicas;
❑Competências;
❑Formação;
❑Conhecimentos;
❑Habilidades manuais e/ou intelectuais;
201
❑Condições de trabalho;
❑Riscos envolvidos (insalubridade/periculosidade);
❑Responsabilidade sobre bens materiais ou imateriais, imagem da
empresa, seja de forma direta ou indireta.
Conceito PAEI
O conceito PAEI pode nos ser útil na compreensão das
características comportamentais requeridas para uma determinada
classe de pessoa. Em decorrência das responsabilidades atribuídas à
classe pode ser necessário um determinado “balanço” entre as
características de Integrador, Empreendedor, Produtor e Administrador.
As pessoas no contexto existencial possuem características pessoais
natas que podemos relacionar com conceito PAEI de Ichak Adizes.
Papel (I) → O Integrador

Papel (E) → O Empreendedor
Papel (P) → O Produtor
Papel (A) → O Administrador
Portanto é possível utilizar este conceito como um dos

critérios para associação de pessoas a classes de pessoas.
“Não há nada neste mundo que não exista para servir
a algum propósito relacionando-se funcionalmente a ele”.
I - Integrador
A capacidade de qualquer coisa funcionar é avaliada
através de como ela serve a seus clientes. O propósito final da
existência de qualquer sistema é integração. Por trás de todo problema
há um relacionamento que não funciona e a solução é torná-lo
funcional. O por que final de fazermos qualquer coisa, o
relacionamento, é o próprio papel (I) – “integração”.
202
E – Empreendedor
O processo de identificação de uma nova necessidade
que satisfaz esse propósito final - sair para uma caminhada em vez de
beber cerveja - é o empreendimento (E), o papel E.
O papel E focaliza o por que fazemos alguma coisa, o
para que de nossas ações. Ele focaliza a satisfação de nossa necessidade
a longo prazo.
P – Produtor
O ato em si de beber cerveja, ir até o lago, ou remover
uma pedra no caminho, o ato de fazer qualquer coisa que satisfaça o
propósito do relacionamento naquele instante, é a produção (P), o fator
P.
O papel (P) focaliza o que fazer agora, e deriva de por
que fazemos o que fazemos.
A - Administrador
Suponhamos agora que uma pessoa possua um método
para remover rochas com eficiência. Essa pessoa já fez isso muitas
vezes e desenvolveu um procedimento muito eficiente. Assim, o grupo
não precisará fazer o trabalho por tentativa e erro. Isso é administrar
(A), o papel A.
Ichak Adizez, Gerenciando Mudanças, Pioneira -

1995.
Quando definimos as classes de pessoas, podemos

identificar qual o papel predominante à classe, ou ainda, qual o peso de
cada papel a ser atribuído a uma determinada classe de pessoa.
Da mesma forma, no processo de seleção de pessoas para
a ocupação das classes podemos considerar o peso dos papéis desejados
na avaliação do perfil pessoal.
203
 5 - Normalização" das Classes de Pessoa
Uma vez derivados, a partir dos processos de negócio, os

requerimentos de recursos humanos, deve-se efetuar uma análise das
classes de pessoas a fim de identificar possíveis classes de pessoa que
sejam, em relação ao perfil da especificação da classe, redundantes,
semelhantes, extensões ou reduções de outras classes.
Considerando-se também a mutabilidade do ambiente, a
configuração de papéis ou classes de pessoas deve basear-se no
enriquecimento da sua razão existencial, o que consiste em:
 ampliar sua responsabilidade
 ampliar seus objetivos
 ampliar seus desafios
Pressupondo-se que isto conduzira à motivação para o
trabalho que decorre da satisfação na ocupação do papel e da liberdade
pessoal.
Esta tarefa de normalização objetiva otimizar o plano de
classes de pessoas (cargos) a fim de propiciar uma base mais simples e
adequada para:
 Ampliação da intercambialidade das pessoas,
 Plano de remuneração
 Plano treinamento e formação,
 Plano de carreira;
 Plano de sucessão;
Amplitude de Classe de Pessoa
A normalização das classes de pessoa deve levar em consideração
Classe (Cargo) Estreita:

É caracterizado pela atribuição direta a atividades
procedurais ou a suas decomposições específicas. Cria classes de pessoa
considerando um baixo “granulo” de cargos ou um alto grau de
“especificidade” em funções, tende a criar classes hiper-especialistas.
Foi utilizado pela indústria no auge da administração científica.
204
Vantagens:
- Identifica cada conjunto de atribuições pelo conteúdo e recebe uma
denominação própria que o distingue dos demais,
- Facilita a identificação por ocasião de pesquisas salariais;
- Permite acompanhar a evolução ou involução de cada classe de
pessoa na empresa e no mercado;
- Simplifica o processo de formação e capacitação pela alta
especialidade;
Desvantagens:
- Distingue conjunto de atividades sequenciais e complementares,
dificultando o remanejamento de funcionários;
- Aumenta significativamente a quantidade de titulações de classes de
pessoa dentro da empresa;
- Oferece menor objetivo e desafios ao ocupante da classe, podendo
gerar desinteresse e desmotivação levando à queda de qualidade e
produtividade;
- Oferece maior dificuldade para a absorção integral da capacidade
produtiva e ajuste do quadro de posições de trabalho;
Classe (Cargo) Ampla:

É caracterizado pelo agrupamento de atividades
sequenciais, equivalentes ou de mesma natureza, numa única descrição
de classe de pessoa. Cria classes de pessoa considerando um baixo grau
de “especificidade” em funções, tende a criar classes generalistas.
Vantagens:
- Facilita o remanejamento de pessoal para diferentes postos de
trabalho sem necessidade de alterar a titulação do cargo;
- Diminui sensivelmente a quantidade de titulações de cargos na
empresa;
- Tende a aumentar o interesse e motivação das pessoas ocupantes da
classe levando à melhoria de qualidade e produtividade;
- Facilita a absorção integral da capacidade produtiva e maior
estabilidade do quadro de posições de trabalho devido a flexibilidade
de alocação das classes;
205
Desvantagens:
- Torna mais ampla a necessidade de treinamento e capacitação.
- Dificulta a identificação por ocasião de pesquisas salariais;
- Proporciona tratamento igual para subclasses distintas que sofrem
alterações significativas no mercado;
- Possibilita o deslocamento de pessoal para execução de atividades
aquém de suas reais capacidades e potencial, provocando
desmotivação e obrigando a empresa, naquela posição, a pagar mais
do que deveria.
 6 - Quantificação das posições de classe de ator
A quantificação das posições de trabalho é o

dimensionamento da quantidade de pessoas que devem ocupar a Classe
para executar as atividades sob responsabilidade da classe dentro dos
prazos aceitáveis pelo processo e das condições de trabalho específicas.
Também conhecido como dimensionamento do headcouting.
O cálculo científico do headcounting de cada Classe de
Pessoa pode ser realizado com base em um modelo matemático que
considere:
- A lista de atividades sob a responsabilidade da classe de ator;

- O tempo de execução previsto de cada atividade;
- O volume de processamento previsto de cada atividade;
- O volume de horas anual de trabalho da classe de ator, conforme
duração da jornada de trabalho;
- Um coeficiente de perda, para ponderar o tempo de inatividade da
classe (paradas para descanso, necessidades fisiológicas, lanches, entre
outros);
HC = Headcouting da Classe
HT = total de horas de trabalho anuais disponíveis para a classe
TP = Tempo de processamento unitário das atividades da classe
VP = Volume de processamento das atividades da classe
CP = Coeficiente de perda das horas de trabalho
206
HC = [Somatória (TP* VP)] / [TP-(TP*CP)]
O headcouting calculado é um número que considera um modelo

de processamento linear, processos de negócio que tem picos de
processamento ou grandes flutuações de volume de processamento
devem ter uma ponderação do headcouting a fim de dimensioná-lo
de acordo a distribuição de carga ao longo dos períodos.
Uma atenção também deve ser dada ao efeito do índice de

ausência, que pode exigir compensações no headcounting,
principalmente quando se tratar de processos de negócio de alta
criticidade para o negócio onde deve haver planos de contingencia
inclusive.
 7 - Determinação do modelo de distribuição física das classes de

pessoa
A distribuição física das classes de pessoa e de suas

respectivas posições de trabalho é definida com base no modelo de
distribuição de processamento das atividades pelas quais é responsável.
A partir do modelo operacional de negócio são extraídas
as ATIVIDADES e seus LOCAIS DE PROCESSAMENTO, estes são
os critérios orientadores para a definição do modelo de distribuição de
classes de pessoa.
Qtde.
Classe de Ator
Local de Atividade Posições
Processamento
Filial Operacional ATIVIDADE A; J; Gerente de atendimento 1
ATIVIDADE B; N Supervisor de cobrança 1
ATIVIDADE C; Q;I; Z; Y Operador cobr. Usuário 22
ATIVIDADE D Operador cobr. est.
2
comercial
Escritório Central ATIVIDADE E; O Auxiliar de planejamento 1
ATIVIDADE F Assistente administrativo 0
ATIVIDADE G Comitê de planejamento 0
ATIVIDADE K; M; H;L Auxiliar administração 4
207
TOTAL 31
 9 - Estruturação da Organização e comando das classes
Por decorrência natural, no BPM-M, a Organização das

Estruturas de Comando ou Estruturas Organizacionais surgem uma
abordagem BOTOM-UP, onde as atividades procedurais justificam a
existência das classes de pessoa “operadoras” e a partir daí justifica-se
os possíveis níveis de comando na ESTRUTURA
ORGANIZACIONAL (Organograma).
Portanto o ORGANOGRAMA de uma determinada área
responsável por operações é elaborado a partir da Arquitetura dos
Processos de sua operação.
As Formas de Orientação da Estrutura Organizacional
A estrutura organizacional das classes de pessoa nada

mais é do que uma forma de agrupamento das classes de pessoas
segundo um determinado critério. Tal agrupamento objetiva estabelecer
uma cadeia de comando, que demanda a definição de novas classes de
pessoas para exercerem esse comando sobre as pessoas que ocupam as
classes agrupadas. Em decorrência destes agrupamentos podem surgir
vários níveis de subordinação, constituindo-se assim, uma cadeia
hierárquica.
Tal agrupamento objetiva, também, o estabelecimento de
unidades de comando, às quais, em tese, devem perseguir objetivos
determinados.
Como critério de agrupamento das classes de pessoa podemos citar

os seguintes critérios:
 Departamentalização por Cliente;

 Departamentalização por Período;
 Departamentalização por Projeto ou Matricial;
 Departamentalização por Combinação de Critérios.
 Departamentalização por Processo
208
 Departamentalização por Função;

 Departamentalização por Região;
 Departamentalização por Produto ou Serviço;
Cada segmento de negócio e área de interesse pode demandar um

critério de agrupamento específico para cada caso em particular.
Dos agrupamentos nascem as Unidades Organizacionais, que
passam por decorrência a agrupar além das classes de pessoas e
pessoas, também:
- recursos físicos (imóveis, móveis, equipamentos , edifícios e

áreas.);
- recursos financeiros,
Tornando-se também o direcionador da responsabilidade por bens

materiais e financeiros alocados a essas unidades organizacionais
para execução de suas atividades. Normalmente encontramos nas
empresas uma estrutura organizacional agrupando pessoas e
recursos físicos & financeiros sem a identificação clara da
responsabilidade sobre as atividades das classes de pessoa ali
agrupadas, uma missão, função ou objetivo é definido, mas
frequentemente, não há definição de responsabilidade sobre gestão
de processos de negócio ou suas atividades.
Considerações Sobre a Escolha da Forma de Orientação da

Estrutura Organizacional
A escolha do critério de Departamentalização, deve considerar os
seguintes aspectos:
 A adequada utilização da especialização das classes de pessoas;
 A adequada utilização dos recursos humanos já existentes e
disponíveis;
 Adequado controle das unidades organizacionais, pela forma de
agrupamento e hierarquização.
 A adequação do grau adequado de descentralização de
autoridade;
 A adequação em relação a aspectos do mercado;
209
 A minimização dos níveis hierárquicos.
O Alcance de Controle
 10 - O Conceito CAPI
Este conceito preconizado pelo Ichak Adizes, em sua

obra literária Gerenciando Mudanças, é extremamente amplo, e a partir
dele, resumimos uma interpretação aplicável no BPM –
Multidimensional.
Quando autoridade e poder se sobrepõem, temos o Poder

Autorizado, esse é o direito de punir e recompensar.
Quando autoridade, poder e influência se sobrepõem,

temos uma nova combinação denominada CAPI (C de conjugação).
210
A empresa possui pessoas cumprindo papéis

adequadamente definidos com autoridade para dizer o que fazer, com o
poder para punir ou recompensar, e pode influenciar a respeito da
validade daquilo que quer que seja feito.
Quando uma empresa dispõe do CAPI, não há razões
para deixar de seguir seu curso de crescimento. Esta organização possui
o controle sobre seu processo de evolução.
Autoridade
Este conceito é definido como sendo o “direito de dizer
sim ou não”. A delegação da autoridade deve ser completa ( autoridade
para dizer sim e dizer não) caso contrário o modelo de delegação pode
impedir as mudanças e burocratizar a organização.
A Relação entre Autoridade e Responsabilidade

Por definição, autoridade e responsabilidade não podem
ser compatibilizadas através de uma regra, pois são dois aspectos que
possuem suas próprias dinâmicas de mudança.
Ichak Adizes diz que só é possível possuir autoridade e
responsabilidade naturalmente compatíveis quando se está morto, pois é
esse o único estado onde “não há” mudanças. Na abordagem do BPM –
Multidimensional procuramos estabelecer as Como referencial, em uma
empresa jovem 40% da responsabilidade e autoridade são concedidas,
60% são tomadas. Já em uma empresa mais velha, 60% são cedidas e
40% são tomadas.
Assim sendo, devido à dinâmica natural das mudanças
do ambiente empresarial há o desequilíbrio entre autoridade e
responsabilidade, por isso que as pessoas não conhecem precisamente
sua autoridade e responsabilidades, isto significa que a organização é
jovem, está viva e mudando.
Responsabilidades das classes de ator “operador” e
definir o compatível nível de autoridade necessário para a pessoa que
assumir o papel poder cumpri-lo adequadamente.
Poder
211
Poder é a capacidade, e não o direito, de punir e/ou

recompensar. Se uma pessoa tem a capacidade de prejudicá-la ou torná-
la feliz, essa pessoa tem o poder sobre você.
Poder é a capacidade de conceder ou negar a cooperação
necessária. A medida do poder dos outros é proporcional ao quanto
você precisa deles e de quanto eles monopolizam aquilo de que você
precisa.
Nikos Kazantzakis, autor do livro Zorba o Grego, proferiu para seu

epitáfio:
Nos níveis mais altos da estrutura organizacional existe
mais autoridade, não poder. Talvez haja um certo poder autorizado, mas
o poder puro, sem autoridade, está nas mãos daqueles de quem a
empresa precisa para cumprir com suas responsabilidades: o
funcionário operacional.
Diretoria
Influência
Influência é a capacidade, e não o direito, de conduzir
outras pessoas a fazerem alguma coisa sem usar autoridade ou poder.
Quando as pessoas usam nossas ideias para tomar suas
próprias decisões, nós a influenciamos. Quando elas estão livres para
212
agir por vontade própria, elas foram influenciadas. Qualquer outra coisa
não é influência, pode ser uma combinação de poder, autoridade e/ou
influência.
Esta capacidade normalmente é nata a cada pessoa e
pode não se manifestar em todos os relacionamentos.
NOTA 1:
Quando autoridade e poder se sobrepõem, temos o Poder Autorizado,
esse é o direito de punir e recompensar, ESSENCIAL PARA AS
CLASSEs DE PESSOA DE COMANDO (ESPCIALISTAS E
GESTORES).
NOTA 2:
Quando autoridade, poder e influência se sobrepõem, temos uma nova
combinação denominada CAPI (C de conjugação).
213
Capítulo 11
MEIO AMBIENTE
O meio ambiente é uma das três dimensões que se

manifestam fisicamente no processo. Da boa qualidade de configuração
da dimensão do meio ambiente depende a adequada performance do
processo.
A configuração do meio-ambiente objetiva basicamente
o estabelecimento do arranjo físico do processo onde é definida a
organização física (layout) de:
❑ Fluxo do objeto transformado pelo processo;

❑ Pessoas alocadas as classes responsáveis pelas atividades do
processo engenhada;
❑ Mecanismos – tecnologia que suportam o processamento das
atividades do processo engenhado;
❑ Mobiliários necessários para as pessoas executarem as atividades do
processo engenhado;
❑ Espaço físico para a circulação e armazenagem de objetos em
processamento;
Com base nestes componentes são definidos os requerimentos de:

❑ Área física
❑ Segurança física (Controle de acesso)
❑ Iluminação
❑ Temperatura
❑ Nível de ruído
214
Ergonomia
Palavra originária do grego (leis do trabalho), passou a

ser empregada a partir da II Guerra Mundial exclusivamente pelo setor
militar, com a finalidade de identificar a origem das causas (falha
humana e/ou mecânica) dos diversos erros na utilização de
equipamentos complexos (aeronaves, radares, etc.), ganhando novos
campos para sua aplicação, a partir de estudos mais aprofundados
iniciados simultaneamente na Europa e Estados Unidos, onde sua
aplicação foi adotada em diversos setores. Estes estudos foram
desenvolvidos conjuntamente com psicólogos, engenheiros,
fisioterapeutas e antropólogos.
Podemos hoje definir ergonomia como sendo a ciência
que estuda as pessoas no desenvolvimento para execução de atividades
diversas (profissionais, domésticas, de lazer, etc.), visando configurar o
meio ambiente para o seu bem-estar e melhoria de sua performance.
Considerando o imenso universo para aplicabilidade dos
conceitos de ergonomia, estaremos ajustando o foco para o contexto
empresarial, mais especificamente na relação homem-atividade-
equipamento-ambiente.
O objetivo do estudo da ergonomia no ambiente de
trabalho é o de propiciar melhores resultados e produtividade no
trabalho, evitando, aos trabalhadores, desgastes excessivos que possam
conduzi-los às doenças correlacionadas ao trabalho.
Partindo do princípio de que quanto mais adequado o
posto de trabalho menor será o esforço do trabalhador para adaptar-se a
ele, já teremos, por consequência, a busca por melhores resultados na
produtividade e na minimização de doenças, principalmente das
chamadas DORT (Doenças Osteomusculares relacionadas ao Trabalho).
Podemos, também, observar que com a aplicação de
conceitos ergonômicos existe uma diminuição significativa do
absenteísmo e da prevenção de doenças crônicas a longo prazo,
resultantes dos trabalhos repetitivos. Salientamos que este último
aspecto tem motivado inúmeras ações judiciais trabalhistas,
215
relacionadas às lesões diversas (tendinites, bursites, inflamações de

articulações, etc.), gerando ônus adicionais para o empregador como,
por exemplo, indenizações vultuosas.
Arranjo físico do fluxo do processo relação processo – meio físico
As razões práticas para o arranjo físico de operações são as seguintes:

❑ O rearranjo físico de um processo existente pode interromper seu
funcionamento, levando à insatisfação do cliente ou a perdas na
produção.
❑ Se o arranjo físico está inadequado, pode levar a padrões de fluxo
excessivamente longos ou confusos , estoques altos de materiais,
filas de clientes ao longo do processo, tempos de processamento
desnecessariamente longos, operações inflexíveis, fluxos
imprevisíveis e altos custos.
O primeiro passo é a classificação do tipo de processo.
Em termos amplos, é a característica de volume-variedade que dita o
tipo de processo.
Cada tipo de processo de manufatura ou serviço implica
em uma forma diferente de organizar as atividades das operações com
diferentes características de volume e variedade.
 A Classificação dos Processos segundo a Relação
Volume – Variedade de Processamento
 Os tipos de processos são:
M Processo de Cada processamento possui um lead time diferente e longo, e o
A projeto modelo de processo é organizado, predominantemente, de forma ad–
N hoc em cada processamento.
U Processo de A maior parte dos processamentos é única ou de baixo grau de
F Jobbing repetição. Os recursos de transformação não são próprios, são
A compartilhados com os de outras operações e envolvem especialistas
T processadores, produzindo alta variedade e baixo volume. (ex.
U restaurar móveis, confeccionar roupa sobre medida).
R Processo de São relativamente repetitivos, produzem volumes elevados, porém
A lotes podem variar de modelo de processo para cada produto produzido.
Processo de Produzem produtos em alto volume e possuem um modelo de
produção processo relativamente estável para cada classe de produto, sendo que
em massa as variáveis de cada classe de produto não afetam o modelo
operacional.
Produzem produtos em altíssimo volume e possuem baixíssima
Processo
variedade sobre o modelo de processo. Normalmente operam por
216
períodos muito longos, chegando literalmente a serem contínuos e

contínuo
ininterruptos.
S Processo de São operações onde os clientes despendem tempo considerável do

E serviço processo, o modelo operacional considera para cada processamento
R profissional um alto nível de customização. São baseados em pessoas e não
V possuem modelo estáveis, são ad hoc.
I Processo de Compreendem muitas interações com clientes, demandando tempo
Ç serviço em limitado e baixa customização. São baseados em modelo
O massa relativamente estáveis e em produtos “padrão”.
S Processo de É caracterizado por níveis de contato com cliente, customização,
‘loja”de volume de cliente e liberdade de decisão pessoal, que o coloca entre os
serviços extremos do serviço profissional e de massa. A processo é baseada em
serviço de front office e back office, o primeiro pessoal e parcialmente
planejado e o segundo completamente planejado.
❑ TIPO DE PROCESSO EM SEGMENTO DE MANUFATURA
❑ TIPOS DE PROCESSO EM SEGMENTO DE SERVIÇO
 Tipo de Arranjo Físico
217
Os processos de negócio que são concebidos através de

modelos lógicos em primeira instância, quando referentes a
processamento de objetos físicos ou referentes a serviços, serão
implementados fisicamente através de um modelo de arranjo físico. São
cinco as classes de arranjo físico principais de processos de negócio:
❑ Arranjo físico posicional;

❑ Arranjo físico por processo;
❑ Arranjo físico celular;
❑ Arranjo físico por produto;
❑ Arranjo físico misto.
Arranjo físico posicional

É o tipo de arranjo básico onde os objetos processados
ficam “fixos” (estacionados) no ambiente e os recursos de
processamento (pessoas e mecanismos –tecnologia) são movimentados
até os objetos para a execução das atividades de transformação. É
aplicado quando não é possível ou não adequado movimentar o objeto a
ser transformado.
Ex: Processo de Cirurgia
Processo de atendimento de cliente em restaurante “a là carte”.
Processo de construção de um navio/aeronave de grande porte.
Arranjo físico por processo
É o tipo de arranjo físico onde os recursos de
processamento (pessoas e mecanismos – tecnologia) são organizados de
forma fixa no meio ambiente e os objetos transformados fluem através
dos agrupamentos destes recursos.
É aplicado quando a organização dos recursos
transformadores é mandatória e pode ser compartilhada com mais que
um processo, bem como os objetos transformados podem ser movidos
“ao longo” do processo.
Ex: Processo de atendimento de pacientes em hospital
(exames/diagnóstico)
Processo de usinagem de peças
218
Arranjo físico celular

É o tipo de arranjo físico em que os recursos de
processamento (pessoas e mecanismos –tecnologia) são organizados em
grupo para a execução de um determinado conjunto de atividades de
transformação que os utilizam. Os objetos transformados movimentam-
se para determinadas áreas físicas onde é executado conjunto de
atividades.
Um processo arranjado em célula pode possuir várias
células, o que pressupõe que o objeto transformado, para ser processado
totalmente no processo, deve fluir pelas células do processo (não
necessariamente todas).
A célula em si (dentro da célula) pode ser arranjada por
processo ou por produto. De fato, o arranjo físico celular é uma forma
de tentar organizar a complexidade de fluxo que caracteriza um arranjo
físico por processo.
Ex: Processo de faturamento de produto.
Processo de parto humano.
Arranjo físico por produto
É o tipo de arranjo físico onde os recursos de
transformação (pessoas e mecanismos –tecnologia) são organizados
segundo a sequência de atividades determinadas pelo modelo lógico do
processo. O arranjo visa a conveniência da transformação da classe de
objeto processado.
O fluxo do objeto transformado é muito claro o que faz
dele um arranjo relativamente fácil de ser controlado.
Predominantemente é a uniformidade dos requisitos do
objeto transformado que leva à adoção de um arranjo por produto.
Ex: Processo de montagem de automóveis.
Processo de triagem e endereçamento de cartas do correio.
Processo de lavagem de automóvel (lava carro automático).
Arranjo físico misto
Muitas operações adotam classes básicas de arranjo
físico puro em cada trecho do processo (subprocessos) ou adotam um
modelo misto/combinado de classes de arranjo físico.
219
Este tipo de arranjo é muito comum e pode ser aplicado a

qualquer tipo de processo.
 A Escolha da Classe de Arranjo Físico

A relação entre o tipo de processo e o tipo de arranjo
físico não é exatamente determinística. Um tipo de processo não
necessariamente determina o tipo de arranjo físico em particular. Como
a tabela abaixo demonstra, cada tipo de processo pode adotar diferentes
tipos básicos e arranjo físico.
220
ser adotada é influenciada por um entendimento correto das vantagens e

desvantagens de cada classe.
A posição do processo no contínuo volume – variedade
influência seu arranjo físico e, consequentemente, o fluxo físico dos
objetos transformados (arranjo físico).
 Vantagens e Desvantagens de cada Classe de Arranjo Físico.
Classe de Vantagens Desvantagens

arranjo
físico
Posicional Flexibilidade de mix de Custos unitários muito altos;
produtos (objetos) muito alta; Programação de ocupação e
Objeto não movido; espaços ou atividades pode
Alta variedade de tarefas para tornar-se complexa;
a mão-de-obra. Pode gerar excessiva
movimentação de materiais
equipamentos e mão-de-obra.
Processo Alta flexibilidade de mix de Baixa utilização e recursos;
produto (objetos); Pode gerar altos níveis de
Relativamente robusto em caso estoques em transformação ou
de interrupção de etapas; fila de clientes;
Supervisão de equipamentos e Fluxo complexo pode ser difícil
pessoas relativamente fácil. de controlar.
Celular Pode propiciar um bom Pode demandar altos custos
balanço em custo e para reconfiguração de layout;
flexibilidade para operações Pode requerer capacidade
com variedade relativamente adicional;
alta; Pode reduzir os níveis de
Atravessamento rápido; utilização de recursos.
Trabalho em grupo pode
resultar em melhor motivação.
221
Produto Baixos custos unitários para Pode propiciar baixa

altos volumes; flexibilidade de mix de
Propicia oportunidade para produtos (objetos);
especialização de Não é muito robusto contra
equipamento; interrupções;
Movimentação de Objetos Pode gerar trabalho repetitivo.
mais conveniente.
O projeto do Meio Ambiente

Consiste em configurar os componentes do meio-
ambiente no qual será instalada o processo considerando como base
para configuração o arranjo físico adotado para a processo. Esta
configuração refere-se a:
❑ Localização física (layout de organização física) de todo mecanismo-

tecnologia, mobiliário e pessoas alocadas ao processo;
❑ Dimensionamento do espaço requerido para a alocação destes
recursos e para as possíveis movimentações de Objetos, Pessoas e
outros Recursos de transformação.
❑ Alocação das atividades a cada “posto de trabalho” contido no
arranjo físico;
❑ Dimensionamento dos requerimentos de iluminação, temperatura e
nível de ruído.
Um bom Modelo de Organização do Meio Ambiente
deve proporcionar as seguintes características ao processo:
❑ Segurança inerente
❑ Extensão de fluxo
❑ Clareza de fluxo
❑ Conforto para a mão-de-obra
❑ Coordenação gerência
❑ Acesso
❑ Uso de espaço racional
❑ Flexibilidade a longo prazo
Projeto Ergonômico do meio Ambiente
222
O ambiente imediato no qual o trabalho acontece,

influencia a forma como ele é executado. As condições de trabalho que
são muito quentes, ou muito frias, insuficientemente iluminadas, ou
excessivamente claras, barulhentas ou irritantemente silenciosas, todas
vão influenciar a forma como o trabalho é levado avante. Um ponto
importante a notar é o impulso que este aspecto de ergonomia recebeu
com a introdução da legislação de saúde ocupacional. Um adequado
entendimento deste aspecto de ergonomia é necessário para trabalhar
dentro das linhas mestras da legislação.
Temperatura de Trabalho
Prever a reação dos indivíduos à temperatura de trabalho
não é simples. Os indivíduos variam de desempenho conforme a
variação do conforto devido à variação da temperatura. Além disso, a
maioria de nós julgando “temperatura” também é influenciada por
outros fatores como umidade e movimento do ar. Não obstante, alguns
pontos gerais relativos à temperatura de trabalho proporcionam guias
para os engenheiros operacionais.
❑ A faixa de temperatura confortável dependera do tipo de trabalho
que será executado
o Trabalhos mais leves requerem temperaturas mais altas
o Trabalhos mais pesados requerem temperaturas mais baixas.
❑ A eficácia das pessoas fazendo tarefas de vigilância é reduzida em
temperaturas acima de cerca de 29o.C; a temperatura equivalente
para pessoas fazendo trabalhos manuais leves e um pouco menor.
❑ As chances de ocorrerem acidentes/ erros aumenta em temperaturas
que estão acima ou abaixo da faixa confortável para o trabalho
envolvido.
❑ A temperatura do corpo humano em repouso é de aproximadamente
36o.C.
Níveis de Iluminação
A intensidade de iluminação requerida para desempenhar
qualquer trabalho satisfatoriamente depende da natureza do trabalho.
Alguns trabalhos que envolvem movimentos extremamente delicados e
precisos requerem níveis muito altos de iluminação.
223
Outros menos delicados não requerem níveis altos. A

tabela abaixo demonstra os níveis de iluminação recomendados
(medidos em LUX) para uma gama de atividades.
Classe de atividades Iluminação (Lux)

Atividades normais em casa, iluminação geral 50
Sala de forno em fábrica de vidro 150
Trabalho geral de escritório 500
Montagem de veículos 500
Revisão de amostras 750
Semelhança de cores em fábrica de tintas 1.000
Montagem eletrônica 1.000
Inspeção fina em roupas 1.500
Inspeção de testes de engenharia utilizando 3.000
pequenos instrumentos
Manufatura de relógios e joalheria 3.000
Cirurgia iluminação local 10.000 a 50.000
Fonte: Iluminating Engineering Society. IES Code for Interior
Lightining – 1977
Níveis de Ruído
Os efeitos negativos dos níveis de ruído excessivos são
talvez mais fáceis de entender o que outros fatores ambientais. A perda
de audição induzida por ruído é uma consequência de ambientes de
trabalho onde ruídos não são mantidos abaixo dos limites de segurança.
Os níveis de ruído de várias atividades são mostrados na tabela abaixo.
Quando consultada a tabela é necessário ter em mente
que o máximo nível de ruído é 90 dB (decibéis) (também
normalmente considerado o limite legal) a que as pessoas podem estar
sujeitas durante o período de trabalho é de 90 dB (decibéis) no reino
Unido (apesar do nível legal em alguns outros países ser menor do que
esse).
Ter também em mente que a unidade de medida de
ruídos Decibéis é baseada em uma escala logarítmica, o que significa
que os níveis de ruído dobram a cada cerca de 3 dB.
Além de efeitos nocivos, os altos níveis de ruído também
podem afetar o desempenho para níveis baixos – por exemplo, em
tarefas que requerem atenção e julgamento.
224
Classe de Ruído Ruído

(dB)
Fala silenciosa 40
Tráfego leve a 25 metros 50
Escritório grande movimentado 60
Rua movimentada de tráfego pesado 70
Britadeira a 20 metros 80
Fábrica têxtil 90
Serra circular – trabalho em ambiente fechado 100
Máquina de rebitagem – proximidade 110
Avião a jato decolando a 100 metros 120
Fonte: Agência de proteção ambiental E.U.A. EPA 1974
É importante considerar:
❑ Ruídos intermitentes imprevisíveis são mais perturbadores do que
ruídos constantes no mesmo nível;
❑ Ruídos de alta frequência (acima de cerca de 2.000Hz) usualmente
produzem mais interferência no desempenho do que os ruídos de
baixa frequência;
❑ O ruído afetará provavelmente, mais a taxa de erro (qualidade) do
trabalhador do que sua produtividade.
O que considerar para a aplicação da ergonomia

A ergonomia preocupa-se primeiramente com os
ambientes. Isso envolve dois aspectos: aspectos fisiológicos do
trabalho, isto é, com o corpo humano e como ele se ajusta ao meio
ambiente.
O primeiro preocupa-se em como a pessoa se confronta
com os aspectos físicos de seu local de trabalho, onde “local de
trabalho” inclui:
❑ Mobiliários;
❑ Equipamentos.
O segundo envolve como uma pessoa relaciona-se com
as condições ambientais de sua área de trabalho direta, com isso nos
referimos a:
❑ Temperatura;
❑ Iluminação;
❑ Ruído etc.
225
Ambos os aspectos estão ligados por duas ideias comuns

que permeiam a abordagem ergonômica do projeto de trabalho;
❑ Adaptar as pessoas ao meio;
❑ Adaptar o meio às pessoas;
O princípio ativo da ergonomia no contexto operacional
direciona para a segunda opção. Entender como os locais de trabalho
afetam o desempenho, a fadiga, e os danos físicos, é parte da
abordagem ergonômica do projeto do trabalho.
Espaço de trabalho
Além de considerar as diferenças de estatura e dimensões
dos trabalhadores, o espaço de trabalho deve permitir ao trabalhador:
 A postura correta de ombros, tronco, cotovelos, antebraços e punhos;
 Espaço suficiente para a mudança de postura.
Posturas de trabalho
Deve ser evitada a manutenção da mesma postura por
tempo prolongado, não permitindo, com isso, a compressão dos vasos
sanguíneos (redução do fluxo de sangue) que pode levar à fadiga.
Deve-se permitir pausas no desenvolvimento de trabalho
para descanso e exercícios de relaxamento. Algumas dicas para buscar a
boa postura de trabalho:
 Correto planejamento do posto de trabalho levando-se em
consideração a postura correta;
 Permitir a flexibilidade postural;
 Utilizar banquinhos em posições semi-sentadas;
 Buscar bom ajuste na relação mesa-cadeira;
 Prever superfícies macias para proteger pontas ósseas e
estruturas músculo-esqueléticas delicadas.
Trabalho na posição sentada ou em pé

Na definição da posição de trabalho devemos considerar o tipo de
trabalho a ser executado, priorizando, sempre que possível, o
trabalho sentado.
226
Manipulação
Não por acaso as mãos humanas são definidas como
nossas principais ferramentas, pois elas estão envolvidas na quase
totalidade de nossas tarefas. Devemos, contudo, atentar para os esforços
antinaturais, repetitivos, com muita vibração ou de grande esforço que
podem, a médio e longo prazo causar problemas de saúde. Devemos
considerar os seguintes fatores:
o Manter cotovelos em ângulos retos quando sob esforço;
o Manter punhos retos;
o Permitir rotação no trabalho;
o Permitir o apoio de membros;
o Minimizar a repetição;
o Permitir pausas para o descanso;
o Evitar posturas que requeiram força por período
prolongado.
Aspectos Antropométricos
A antropometria refere-se às dimensões métricas do
corpo humano. É fundamental para a adequada configuração
dimensional do local de trabalho (mobiliário, equipamentos, espaços).
A tabela abaixo ilustra dados antropométricos femininos/masculinos do
povo norte americano para idades de 20 a 60 anos.
Classe de 5o. (cm) 50o. (cm) 95o. (cm) Desvio

Medida percentil percentil percentil padrão
Estatura 149,5 160,5 171,3 6,6
Altura do 138,3 148,9 159,3 6,4
olho
Altura do 121,1 131,1 141,9 6,3
ombro
Altura do 93,6 101,2 108,8 4,6
cotovelo
Altura, 78,6 85,0 90,7 3,5
sentado
Altura do 67,5 73,3 78,5 3,3
olho,
sentado
Altura do 49,2 55,7 61,7 3,8
227
ombro,
sentado
Altura do 18,1 23,3 28,1 2,9
cotovelo,
sentado
Altura do 45,2 49,8 54,4 2,7
joelho,
sentado
Altura de 35,5 39,8 44,3 2,6
trás do
joelho,
sentado
Altura da 10,6 13,7 17,5 1,8
folga da
coxa,
sentado
Fonte: Adaptado do KROEMER, K.H.E Engineering
Anthromometry. Wiley 1983
Padrão Universal de medidas

Fonte Prof. Jorge Boueri – FAU São Paulo
Classe de Medida Altura Classe de Medida Altura
mínima mínima
(m) (m)
Pé-direito 2,70 Banqueta para 0,76
desenho
Porta 2,10 Mesa escritório 0,75
Prateleira mais alta 1,80 Máquina de costura 0,71
– homens
Centro de espelho 1,50 Mesa para 0,65
computador
Bancada e serviço 1,20 Braço cadeira 0,61
Mesa de telefone 1,04 Mesa de centro 0,28
Pia 0,90
228
Capítulo 12
ANÁLISE DE MÉTRICAS
Como métricas operacionais podemos classificar todo e

qualquer indicador que permita mensurar um determinado aspecto sobre
uma operação. De forma geral podemos classificar os Indicadores em:
❑ Volumétricos
❑ Temporais
❑ Qualitativos
❑ Financeiros
❑ De Performance
Abordaremos neste capítulo apenas algumas destas

classes de indicadores métricos operacionais. A classe de indicadores de
performance representa indicadores específicos para cada operação
abordada e não será alvo de estudo deste capítulo visto que uma
variação infinita de indicadores poderia estar aqui envolvida.
229
A aplicação dos conceitos de métricas pode ser utilizada

tanto para “medir” a situação corrente de uma dada operação quanto
para medir a sua situação transformada
 Métodos para Obtenção de Informação métricas

Método Descrição Comentário Classe Atores
Observar como Efetivo para produtos bem
e porque definidos ou serviços em área Clientes;
Observação
pessoas utilizam geográfica limitada com Fornecedores;
direta
produtos e população levantada limitada Empregados
serviços.
Facilita Efetivo para propósitos
pequenos específicos de mercado e
grupos como publicações onde uma pequena
Clientes;
membros amostra de uma grande
Foco no Fornecedores;
discutindo população é considerada
grupo Empregados
valores adequada devido à existência de
Comunidade
agregados de alguma diversidade de
importância necessidade e percepção.
para eles.
Efetiva para sondagem
Conversações detalhada, quando uma amostra
Entrevistas
executadas face- limitada é aceitável ou todos
pessoais
a-face. considerável tempo é
disponível.
Entrevistas Programada, Efetiva para sondagem em todos
telefônicas entrevistas por profundidade, quando uma
telefone grande amostra é necessária e o
estruturadas. tempo é curto, ou o acesso é
230
limitado
Efetivo para um volume de Clientes;
Questionário respostas em um bem definido Fornecedores;
Levantament
escrito questionário. Utilizável para Empregados
os escritos
estruturado. monitoramento contínuo e Investidores;
diversidade geográfica. Comunidade
Discussões Efetivo para sondagem em
facilitadas com profundidade, construção de
grupo de relacionamento para aumentar a Clientes;
pessoas integridade nos retornos e em Fornecedores;
Grupo de
selecionadas em monitoramento contínuo. Empregados
usuários
intervalos Investidores;
periódicos, por Comunidade
um longo
período.
Fonte: Understanding and applying Value-added assesment-William

E.Trischler -ASQC Quality Press-Milwaukee ,Wisconsin 1996/USA
 Indicadores qualitativos
Valor de Contribuição
A abordagem centrada no cliente, é baseada no conceito

de que todos os processos de negócio, devem estar voltados para
satisfazer as necessidades do cliente, sejam eles relacionados com o
produto de forma direta (em linha), ou indireta (controle ou suporte).
Com base neste conceito podemos classificar o Valor de
Contribuição das atividades atômicas e dos processos para com a
satisfação dessas necessidades. Este fator não é propriamente um fator
métrico, mas sim de classificação, pois permite avaliar os ciclos de
tempo e os custos, segundo o critério de utilidade. Existem quatro
categorias de valor de contribuição:
231
❑ RUT: Real utilidade, transformação

Refere-se às atividades atômicas que criam/eliminam
instâncias de objetos de negócio, transformam seu estado, criam ou
eliminam seus relacionamentos, alteram valor de suas características.
São essenciais ao processo para satisfazer às expectativas do cliente, ou
seja, a geração do produto e estão diretamente relacionadas ao objetivo
básico da operação. Em cada operação pode estar associada a um
conjunto de verbos de natureza diferenciada.
❑ RUC: Real utilidade, controle

Refere-se às atividades atômicas que não realizam
transformação dos objetos de negócio (não criam/eliminam instâncias
de objetos de negócio ou transformam seu estado ou criam ou eliminam
seus relacionamentos ou alteram valor de suas características). Esses
controles são referentes a:
o qualidade e/ou validade de transformações realizadas,
o tomada de decisões com base ou não em regras de negócio,
o Planejamento e controle de andamento;
o Custódia de objetos e regras;
o Monitoramento;
Adicionam custo ao processo, porém, não adicionam
valor do ponto de vista do cliente.
❑ NUO: Nenhuma utilidade, obrigatória

transformação, nem são necessárias à condução do negócio para a
realização de controles, porém, tem sua existência justificada por uma
obrigatoriedade de imposição legal, sindical, contratual etc. Ou ainda
por uma restrição natural e incorrigível do próprio negócio.
❑ NUD: Nenhuma utilidade, dispensável

transformação, não realizam controles, não são obrigatórias e nem
necessárias à condução do negócio. São anomalias da operação e devem
ser eliminadas por definição, portanto totalmente dispensáveis.
232
Grau de Suporte Tecnológico

Este indicador qualitativo mensura o grau de suporte
dado a uma determinada operação através da identificação e
contabilização das atividades procedurais classificadas em puramente
manuais e suportadas por tecnologia.
Valor Agregado a Produto (Ponto de Vista do “Stakeholder”)

O processo de análise de agregação de valor, pressupõe a
satisfação das expectativas e necessidades do cliente do processo.
Satisfação essa, dada pelo valor do output do processo.
Para avaliar o quanto as atividades contidas em um
processo agregam valor ao seu output, torna-se necessário primeiro
conhecer as expectativas do output sob o ponto de vista do cliente. Para
tanto adotamos o conceito de stakeholder para nossa aplicação,
definido como “Classe de Ator”.
Segundo o padrão de série ISO 9000, existem cinco
grupos de stakeholder. As categorias aqui relacionadas destacam
credores e investidores de proprietários, governo e comunidade de
sociedade, e administradores de empregados.
Referência: ANSI/ISO/ASQC Q9000-1-1994
Classe de Pessoa da Metaclasse Stakeholder

❑ Cliente;
❑ Fornecedor Primário;
❑ Colaborador (empregados);
❑ Credor;
❑ Investidor;
❑ Governo;
❑ Comunidade;
❑ Administrador.
 Indicadores temporais
233
Técnica de Revisão e Avaliação de Programa – PERT

(program evaluation and review technique). A técnica reconhece que o
tempo de duração das atividades em redes (operações) não é
determinístico (fixos) e que a teoria da probabilidade pode ser aplicada
para fazer estimativas. Na rede o tempo de duração de cada atividade
(TPU) é estimado de três formas:
- otimista
- provável
- pessimista
Tempo de Processamento Unitário (TPU):
Tempo de Processamento Inativo (TPI):
Tempo de Processamento Total (lead Time) -TPT:
Método do Caminho Crítico - CPM (Critical Path Method)

O método CPM modela uma operação esclarecendo os
relacionamentos entre as atividades da operação. Primariamente essa
arquitetura de relacionamento entre as atividades da operação pode ser
representada por um diagrama onde cada atividade é um arco (uma
linha), o qual é denominado de AoA – Activity on Arrow.
Na Engenharia Operacional de Negócio utilizamos a
representação alternativa de representação de rede denominada de AoN
– Activity on Node, que representamos utilizando a notação IDEF 0/3
ajustada onde cada atividade é representada por um símbolo quadrático
são os relacionamentos por uma linha com uma seta (demonstrando o
sentido do relacionamento) que os relaciona. Há três vantagens na
utilização da representação AoN:
234
É mais fácil partir da ideia de uma rede para sua

representação pelo método AoN do que o método AoA.
- A representação AoN não necessita de representação fictícia
para manter a lógica dos relacionamentos.
- A maioria dos softwares utiliza a notação AoN.
Em todos os diagramas de rede em que as atividades têm

algum relacionamento (forma de ordenação) paralelo haverá mais de
uma sequência de atividade que levará do início ao final da operação.
Essas sequências de atividade são chamadas de caminhos
através da rede. Cada caminho terá uma duração total que será o som da
duração das atividades nele contidas. O caminho que contem a
sequência de duração mais longa na rede é chamado de Caminho
Crítico da rede. Vale notar que pode haver mais de um caminho crítico
na mesma rede se eles possuírem o mesmo tempo mais longo.
É chamado de caminho crítico por que qualquer atraso
nas atividades do caminho atrasará toda a operação. São considerados
seis valores para a análise do caminho crítico da rede:
- data mais cedo de início = data mais cedo de término da

atv. anterior
- duração
- data mais cedo de término = data mais cedo de início +
duração
- data mais tarde de início
- data mais tarde de término
- folga total
 Indicador Volumétrico
Volume de Atividades
Volume de Disparos de Processamento
Refere-se ao volume de inputs ou de disparos (estímulos)
de cada atividade procedural da operação. É fundamental para o
235
dimensionamento de capacidades, seja de processadores, recursos de

processamento, ou de armazenamento de informações.
Os volumes de disparos de cada atividade da cadeia do
processo são calculados com base no percentual proporcional do
volume de input do passo anterior na cadeia ou com base no volume de
disparos provocados por eventos, sejam do tipo normal, temporal ou
condicional.
A Relação do cálculo dos volumes de disparo com a
anatomia da operação:
Volume de Armazenagem
“Volume” de Espaço
Volume de Posições de Trabalho das Classes de Pessoa
 Indicador Financeiro
Custeio Baseado em Atividade
Comumente chamado de ABC – Activity Based Costing,
o custeio baseado em atividade pode ser conceituado como:
“O método onde as atividades são o foco do custeio”
“É o processo de alocação de recursos para atividades e destas para os
objetos de custos”
Ao contrário da visão tradicional estruturada e
hierárquica estruturada o método ABC utiliza o modelo de
encadeamento de atividades (processo) para compreender o surgimento
236
e a apropriação dos componentes de custo. Portanto a aplicação do

conceito ABC é uma decorrência natural da compreensão da empresa
através da visão operacional de processos.
Os componentes do método:
❑ Recursos: o “insumo” que efetivamente é consumido na atividade
(água, ***mdo, material etc.)
Os recursos de custo, normalmente perceptíveis na
operação de negócio, podem ser classificados em:
- trabalho (mão-de-obra);
- material consumido;
- equipamentos e mecanismos – Tecnologia;
- meio ambiente, etc.
❑ Atividades: “onde” foi consumido o recurso (atividades de linha,
suporte, controle, custódia).
❑ Objeto de Custo: para que foi consumido o recurso, onde o recurso
foi “incorporado” (produtos, serviços etc.).
 Indicador Performance
Este conjunto de indicadores faz referência ao

monitoramento e medição da performance de processos de negócio
específicos. São hoje alvo da gestão através do conceito de BSC-
Balanced Score Card, e são definidos normalmente como uma
formulação matemática que pode combinar as quatro categorias básicas
de indicadores (volumétricos, temporais, financeiros e qualitativos)
sempre associados a dimensão tempo (período temporal, ex. mês, ano,
etc.).
Estes indicadores desassociados do modelo operacional
não apontam de forma eficaz as necessidades de ajuste dos modelos
operacionais da companhia envolvendo todas as suas dimensões.
237
Capítulo 13
O arquiteto empresarial
“Ser Arquiteto empresarial é ser o agente de transformação operacional

das organizações funcionais, é ser aquele através do qual a empresa
melhora a forma de atingir seus objetivos operacionais”.
O Papel
Ser o agente de transformação da organização
operacional de negócios através do aperfeiçoamento das operações
empresariais não fabris.
 Prover soluções focadas na abordagem das sete dimensões que

compõem o ambiente operacional empresarial (atividade,
informação, recursos humanos, tecnologia de informação, regras de
negócio, meio ambiente físico, relações com mercado),
transformando planos, filosofia e políticas de gestão de negócio em
modelos de operação que conduzam a empresa ao estado de
excelência criando o diferencial operacional de mercado;
 Visar o conhecimento global da verdadeira natureza e origem
dos problemas;
 Estar comprometido com soluções que harmonizem todos os
aspectos empresariais;
 Estar em contínua busca da situação ideal, e da estratégia de
como atingi-la;
 Cultivar uma postura de empreendedor junto aos clientes e à
equipe de trabalho;
 Envolver os clientes na engenharia disseminando a atitude de
agente de mudança;
238
 Ser o elo entre os diversos especialistas envolvidos nas

operações empresariais.
A Missão
A otimização operacional não constitui-se apenas das
tarefas racionais e técnicas para organizar a melhor combinação das sete
dimensões, mas muito além disto, constitui-se da arte de conduzir as
pessoas à consciência para, a partir daí, e junto com elas, estabelecer
um ambiente produtivo harmônico, eficiente, eficaz, flexível e seguro,
onde todas as coisas assume o seu melhor “lugar” dentro do contexto
empresarial.
Ser capaz de lidar com todas as classes de pessoas que
constituem a personalidade do ambiente empresarial, “conduzindo”
seus anseios, expectativas e receios, para torná-los propulsores do
processo de transformação.
A Arte de Comandar
Apresentamos aqui uma visão diferenciada sobre a
postura e alguns valores que podem ser cultuados pelo Arquiteto
empresarial ao longo de sua atuação em projetos de transformação
baseado da comparação entre o comando de situações de transformação
e comando de situações de combates, situações estas que podem ser, de
certa forma, comparadas pois envolvem confronto de ideias e objetivo
de “conquista” ou “vitória” na descoberta e defesa destas ideias.
Conceito de estratégia:
1)Atenção em si mesmos.
“O maior guerreiro conquista primeiro a si próprio”.
Aprender a controlar suas próprias ações e reações.
Treinar para resistir à pressão e não ficar paralisado quando há a
necessidade de pensar rápido e agir resolutamente. Avaliar com
exatidão seus pontos fortes e fracos.
2)Necessidade de compreender os outros

Compreender os outros e os mecanismos que os tornam vigorosos
aliados, débeis compatriotas ou grandiosos inimigos.
239
3)Interação entre si e os outros (campo de manobras ou de

mudanças).
Como será a reação ao meu movimento? De que modo posso bloquear
seu segundo ataque?
“O tempo e o poder de qualquer pessoa são limitados”.
Guenchin Funakoshi
Disciplina
“A arte do karatê é uma busca interminável de perfeição, de
desenvolver o espírito e o corpo para derrotar o adversário: você
mesmo”.
Tak Kubota
Tal como as artes marciais, a administração de empresas
é tanto ciência quanto arte. Autoconhecimento implica reconhecer que
toda força é uma fraqueza potencial, e vice-versa. Com perspectiva
ampliada e um ponto de vista “generalista”, você reconhecerá as inter-
relações existentes na sua empresa ou organização. Poderá assim
aumentar a flexibilidade da empresa e reforçá-la, combinando enfoques
profissionais aparentemente díspares.
Dominando o Medo
Em situação de perigo, não viva nunca antecipadamente
uma situação. Nunca suponha coisa nenhuma. Permaneça sempre alerta.
O medo causado pela suposição cria dúvida e debilita a capacidade de
julgamento. Às vezes, o medo surge quando a pessoa tem que fazer
alguma coisa e não sabe o quê. Tal como o medo de consequências
negativas talvez o leve a repensar o assunto ou a adiar uma decisão
precipitada. Em ambos os casos, o efeito é positivo, não paralisante.
O Poder do autocontrole
Você se controla ou renuncia ao controle. Mas ninguém
pode dominá-lo sem que você o permita. No mundo dos negócios,
quanto mais perto emocionalmente estiver você da pessoa ou grupo
“alvo’, maior sua influência. Proximidade é poder”.
240
A omissão em reconhecer os stress é o maior problema

do gerente que se encontra nesse estado. Admita seus medos. E
reconheça sempre o que é óbvio para os outros . As pessoas sabem
quando você não está seguro de si mesmo. Não negue o que está na
cara. Mais importante que tudo, o autocontrole protege-o de atos e
palavras impulsivas que, uma vez pronunciadas, nunca mais podem ser
retiradas. Talvez você pense que tudo foi esquecido, mas os que
sofreram o impacto de suas palavras irritadas têm ideias muito
diferentes. Gerentes tornam-se hesitantes e menos efetivos quando
permitem que preocupações os dominem. Em vez de deixar que as
preocupações o encurralem, transforme-as em estímulos para a ação.
Controle de atitude para mente corajosa

A atitude certa é o alicerce da mente corajosa. O
realmente fundamental, disse , é atitude vencedora. Atitude é a maneira
como você aborda alguma coisa. E isto é crucial. “Se acha que pode ou
que não pode provavelmente tem razão”. Atitude não faz tudo por si
mesma. Apenas mostra para onde e como você deve canalizar seu
esforço. Estudos demonstram que as atitudes são importantes em tudo,
da saúde ao desempenho, da capacidade de aprender adaptar-se à
mudança. A Sorte é que as atitudes positivas são tão contagiosas como
as negativas.
Técnicas para desenvolver o poder da atitude

Em administração, concentre-se inteiramente na
atividade que o ocupa no momento. Não se deixe distrair por
pensamentos. Não desperdice esforço negando–os ou bloqueando-os.
Assumir a atitude certa reforçará o que você quer comunicar.
A coragem de ser invisível

Isto significa não sucumbir à ânsia de reconhecimento. A
maioria das pessoas sentem este desejo, que só pode atrapalhar.
Dominando o desejo de reconhecimento, preserva a comunicabilidade
com os colegas e garante eficiência para o futuro. Ironicamente,
evitando obter reconhecimento você muitas vezes conquista o prestígio
maior de ser considerado como a pessoa que conseguiu o resultado.
241
A coragem de criar
Taisen Deshimaru: “Os problemas da vida são diferentes
nos casos de todos nós e precisamos todos de uma maneira diferente de
solucioná-los. Por conseguinte, cada um tem que criar seu próprio
método. Se imitar, você erra. Você mesmo tem que criar.”
Criar significa descobrir maneira diferente de fazer
alguma coisa. Você tem que recusar acomodar-se depressa demais, ficar
confortável demais, ou concordar sempre com o status quo.
Criatividade, claro, não é desculpa por rebeldia cega, da
mesma forma que honestidade não constitui fundamento lógico de
insensibilidade. Coragem de criar implica estar disposto a arriscar-se ao
ostracismo ou à rejeição, não aceitar nenhum problema como insolúvel
e nunca se satisfazer com resultados medíocres. Criar significa estar
pronto para fracassar.
Desenvolvendo Coragem: Técnicas de Ação

 Pratique alguma coisa fora de sua faixa de conforto. Note o
desconforto, mas não desista. A nova atividade pode ser simples -
comer ou praticar um esporte com a outra mão ou mudar a ordem em
que se veste - ou mais complexa - aprender a programar um
computador ou falar de uma grande plateia.
 Assumam riscos razoáveis. Defenda suas opiniões, mas reconheça
também quando se desviou do curso. Desenvolva a coragem de
parecer embaraçado em público. Tente coisas novas e sorria de si
mesmo, se achar que está parecendo um pouco bobo.
Voluntariamente, diga: “Não compreendi”.
 Observe-se com atenção quando está assustado, ameaçado ou
zangado. Domine-se antes de perder o controle do que diz ou faz.
 Mentalmente, estude a possibilidade de renunciar à segurança do
emprego. O medo de perdê-lo pode ter-lhe arruinado a capacidade de
assumir riscos razoáveis.
 Todos os dias, pratique controle de atitude, mesmo quando as coisas
correm bem.
 Espalhe o reconhecimento. Em silêncio, congratule-se consigo
mesmo pelo trabalho que faz, mesmo que outros recebam o crédito.
242
Observe que esse método gera comprometimento e esforços mais

vigorosos de seus subordinados.
 Pense diferente, tente alguma coisa nova. Aplique o
desconhecimento ao que já sabe. Pense criticamente, atue
criativamente.
Postura de Poder
Pense nas posturas dos gerentes mais impressionantes
que conheceu. Quantos deles se mostram encurvados ou visivelmente
tensos? A maioria dos que conheci transmitem um senso de forte
presença. Parecem relaxados, fortes e no controle da situação. O quanto
de sua conduta podemos deduzir da postura? O controle da postura
realça sua presença e você parece realmente mais alto e mais poderoso.
A motivação através da brandura da dureza
Descobrir o que não funciona, como não criar resistência

Comece por observar-se. Note como resiste à força
excessiva dirigida contra você. Observe as demais pessoas. Pessoas
reagem quando são empurradas com força demais. Para cada ação há
uma reação igual e oposta. Em palavras simples, força cria resistência,
que é uma reação inconsciente.
Equilibrar brandura com dureza e gerar poder motivacional

A brandura é flexível e não encerra ameaça. Pense em
aço envolvido em veludo. É suave e acessível por fora, firme e
inquebrável por dentro. Você pode mudar sua conduta não verbal
visualizando-se como “aço revestido”.
O Poder suave do convite

Em vez de procurar maneiras tortuosas para fazer com
que pessoas se movam, convide-as. Isto , às vezes, converte o
adversário mais violento em aliado.
Ajustando o clima do trabalho
243
O artista marcial modifica seus movimentos e estratégias

de acordo com os diferentes adversários e condições. Os ajustamentos
são minúsculos e podem parecer banais, mas são absolutamente
essenciais. Fazendo ajustamentos sutis, você pode aumentar a
produtividade e elevar o moral, adequando o ambiente de trabalho ao
empregado.
Técnica de reunião de trabalho –“jad”

O JAD foi desenvolvido originalmente pela IBM em
1977, é visto como um meio de se obter consenso entre um grande
grupo de usuários. O JAD possibilita o direcionamento de seu foco à
qualidade e produtividade do processo criativo, em um determinado
projeto. Foi criado, a princípio, para se posicionar junto os usuários e
profissionais das áreas de sistemas para que projetassem, em sessões de
grupos, um sistema específico em conjunto.
Benefícios:
 Maior produtividade;
 Maior qualidade;
 Trabalho em equipe;
 Custos mais baixos de desenvolvimento e manutenção.
Os quatro princípios do JAD

1) Dinâmica de Grupo
A metodologia em questão desencadeia a força e a
criatividade da dinâmica de grupo que determinam os objetivos e os
requisitos do projeto, indo além do formato tradicional de entrevistas
individuais e em grupo, pelas quais os analistas coletam dados dos
usuários.
2) Recursos Visuais
Uma das barreiras à participação eficaz dos usuários, no
processo de especificação e no projeto em si, tem sido sempre como
tornar mais palpáveis os requisitos e conceitos de projeto ao usuário. O
JAD dispõe, de numerosos recursos visuais para tornar esses conceitos
mais palpáveis.
244
3) Processo Organizado e Racional

O JAD concorda com as metodologias mais tradicionais
e não participativas em muitos aspectos, mas incorporando um processo
organizado e racional. Emprega a análise top-down e atividades
extremamente bem definidas, a fim de atingir a definição de objetivos,
especificações e projetos externos.
4) Abordagem Wysiwyg para Documentação

A documentação do JAD garante que o conteúdo e o
formato dos documentos sejam completamente familiares aos usuários e
analistas. A familiaridade dos documentos reforça o sentimento de
domínio do participante e conduz a um processo de revisão mais
efetivo.
Os Participantes do JAD
Os participantes ocupam o papel central no JAD. Se as
pessoas selecionadas para projetar o sistema são inexperientes em seu
trabalho, sem imaginação e resistentes a mudanças, o projeto resultante
não servirá, na sua totalidade, às necessidades da organização.
O JAD possibilita que uma organização coloque em
destaque as habilidades e criatividade de seus melhores elementos.
Quantos participantes?
Os melhores líderes de reunião não podem,
possivelmente, gerenciar mais do que 15 participantes de forma
eficiente. O ideal é um número em torno de cinco participantes.
 O Gestor responsável pela Operação

 Representante dos operadores (Operador/especialista da
operação)
 Especialista em tecnologia
 O Líder de Reunião (Arquiteto empresarial)
É responsável pelas estimativas, planejamento e
acompanhamento de todas as atividades específicas.
245
Com o objetivo de orientar a dinâmica em grupo o líder

necessita ter capacidade de controlar as discussões e superar as questões
pessoais, que inevitavelmente surgem. Ele (ou ela) pode ajudar a
completar as saídas formais do JAD (isto é, a documentação e o
protótipo).
Para serem treinados como líderes de reunião, a principal
prioridade é a seleção de pessoas com maiores habilidades
interpessoais. Esses atributos são mais difíceis de ensinar do que outras
características desejáveis, como apresentação, escritas e capacidade de
orientação. Os líderes devem ser pessoas enérgicas, que possam
permanecer entusiasmadas.
Devem ser indivíduos responsáveis e bem-organizados,
que possam planejar e acompanhar as atividades necessárias para
executar o trabalho de desenvolvimento.
Fase de Reuniões
Apresentação das tarefas
Um dos mais importantes fatores, na geração de
discussões significativas, é apresentar claramente a tarefa atual. O líder
de reuniões começa cada atividade explicando aos participantes o que
eles estão por realizar, transmite a explicação detalhada apenas para a
primeira ocorrência.
Geração de ideias
O líder de reunião define a atividade atual, os
participantes oferecem suas ideias sobre o tópico. Este é um momento
para a criatividade e inovação, pois os participantes discutem várias
soluções alternativas.
Avaliação
Os participantes decidem se encontram uma boa solução,
coerente com as decisões tomadas previamente. O líder de reunião
ajuda os participantes a chegar a um consenso para essa solução.
Compromisso
246
Quando os participantes da reunião chegam a um acordo,

o líder resume a solução e, ele ou o analista, faz o registro.
Papéis Importantes do Arquiteto empresarial

O Papel de Comunicador
Comunicar-se constitui habilidade requerida de todos os
profissionais que exercem funções gerenciais, principalmente dos
profissionais de recursos humanos, pois, na maioria das atividades que
exercem, necessitam exprimir-se oralmente ou comunicar-se com uma
ou mais pessoas.
Como saber comunicar significa fazer-se entender, o
comunicador precisa estar capacitado não apenas para falar, mas
também para ouvir.
O profissional de Recursos Humanos, antes de qualquer
outra habilidade, requer o desempenho eficiente da função de
comunicador, o que irá exigir o conhecimento do processo de
comunicação, o reconhecimento dos fatores que a dificultam e o
domínio das regras para torná-las mais eficientes.
O Papel de Treinador
Nos tempos atuais, o que predomina no setor de
treinamento, pelo menos nas grandes organizações, é o modelo
sistêmico. O treinamento é visto como um meio para suprir as carências
dos indivíduos em termos de conhecimentos, habilidades e atitudes,
para que estes desempenhem as tarefas necessárias para alcançar os
objetivos da organização. O treinamento passa a ser entendido como um
dos sistemas da Administração de Recursos Humanos, que se
desenvolve a partir dos subsistemas: diagnóstico, prescrição, execução e
avaliação.
O Papel de Avaliador
É importante para uma organização manter um sistema
de avaliação de desempenho tecnicamente elaborado. É uma maneira de
evitar que a avaliação seja feita de forma superficial e unilateral, do
chefe em relação ao subordinado. Desta forma, a avaliação alcança
maior nível de profundidade, ajuda a identificar causas do desempenho
247
deficiente e possibilita estabelecer perspectivas com a participação do

avaliado. Sem contar que a avaliação de desempenho elaborada a partir
de princípios científicos possibilita uma abordagem mais racional do ser
humano, livre das distorções próprias da avaliação feita com base
apenas no senso comum.
A avaliação de desempenho constitui um meio para
desenvolver os recursos humanos da organização. Torna-se possível:
 Definir o grau de contribuição de cada empregado para a

organização;
 Identificar os empregados que possuem qualificação superior à
requerida pelo cargo;
 Identificar em que medida os programas de treinamento têm
contribuído para a melhoria do desempenho dos empregados;
 Promover o autoconhecimento e o autodesenvolvimento dos
empregados;
 Obter subsídios para redefinir o perfil requerido dos ocupantes dos
cargos;
 Obter subsídios para remuneração e promoção;
 Obter subsídios para elaboração de planos de ação para desempenhos
insatisfatórios.
248
Alguns Princípios Fundamentais
O princípio da casualidade
“A essência de uma coisa é igual a essência de mil”
A estratégia de abraçar a morte
“A arte de segurar o beija-flor”
A estratégia da atitude sem atitude
O princípio da relação pessoa - ambiente
Os dez fatores da vida
Os dez estados de vida
O princípio da união das forças
O princípio de contornar o ataque
A estratégia do suave e do rígido
O princípio do espírito alto e do espírito elevado
“Espírito – espada – pincel”
“Uma andorinha, sozinha, é capaz de fazer verão!”
249
Bibliografia
1. APPLETON, Daniel S.; PROB - Principle of Business Engineering, Talon Press,
1994.
2. ADIZES, Ichak; Gerenciando as Mudanças, Livraria Pioneira Editora, 1991.
3. ADIZES, Ichak; Os Ciclos de Vida das Organizações, Livraria Pioneira
Editora, 1988.
4. HAMMER Michael; Reengenharia Revolucionando a Empresa, Editora
Campus, 1994.
5. DEVENPORT, Thomas H.; Reengenharia de Processos, Editora Campus,
1994.
6. JACOBSON, Ivar; Object Oriented Software Engineering, ACM Press, 1992.
7. DREYFUSS, Cassio; Reengenharia das Empresas - Passando a Limpo, Atlas
AS, 1995.
8. TRISCHLER, Willian E.; Understanding and Applyng Value - Added
Assessment, ASQC Quality Press, 1995.
9. CSILLAG, João Mário; Análise do Valor, Editora Atlas, 1986.
10. FOREST, Edward; HILL, Macgraw; Activity Based Management, 1995.
11. JACOBSON, Ivar; The Object Advantage Businees Process Reengineering
Whit Object Technology, ACM Press, 1995.
12. FURLAN, José Davi; Modelagem de Negócio, Makron Books, 1996.
13. YOURDON, Ed; Mainstream Objects An Analysis and Design Approach for
Business, 1993.
14. RAMBAUGH, J., Object Oriented Modeling and Design (OMT), Prentice
Hall, 1991.
15. CHEN, Peter, BOOKS, Makron, Modelagem de Dados, 1990.
250
16. Information Modeling an Object Oriented Approach, Hain Kilov, PTR

Prentice Hall, 1993.
17. AUGUST, Jud H., JAD - Joint Aplication Design, Makron Books, 1991.
18. OHNO, Taiichi, O Sistema Toyota de Produção, Bookman, 1997.
19. ARIOLI, Edir Edemir, Análise e Solução de Problemas, Qualitymark, 1998.
20. Nigel S., Stuart C., Chrietie H., Aln H., Robert J., Administração de
Produção, Atlas 1997.
21. RENAUD, Paul E., Introdução aos Sistemas Cliente Servidor ERE, IBPI
Press - Livraria e Editora Infobook AS, 1994.
22. MUSASHI, Miyamoto, Um Livro de Cinco Anéis, tradução Fernando B.
Ximenes, Ediouro, 1984.
23. TSU, Sun, A Arte da Guerra, Editora Record, 1983.
24. Fundamentos do Budismo, Editora Brasil Seikio Ltda., 1977.
ABC Crédito
1 - A equipe de vendas da ABC Mundial ao telefonar com um pedido

de financiamento é atendida por uma das 14 pessoas sentadas em torno
de uma mesa de conferências. O receptor do pedido registra a
proposta em sistema de registro de protocolo e imprime a solicitação em
uma folha de papel. A folha de papel é remetida para o Departamento
de Crédito.
2 - No Departamento de Crédito, um especialista recebe a Selic, de

financiamento, consulta a situação de credito do tomador do
financiamento junto ao SERASA e SPC, levanta o histórico de
pagamento, do tomador do financiamento, junto à ABC Credito, ao
final registra as informações obtidas na Solicitação de Financiamento e
envia para seu colega especialista em limite de credito.
3 - No Departamento de Crédito, onde um especialista digita a

informação em um sistema de computador e consulta o limite de crédito
do Cliente. O Limite de crédito depende de um conjunto de variáveis,
incluindo informações da solicitação de financiamento, situação de
credito do financiado (SERASA), e informações pessoais do financiado,
251
histórico de pagamento junto à ABC Credito. A tabela consultada junto

ao sistema é mantida pelo gerente do processo e financiamento. O
especialista anota o resultado da verificação de crédito na folha de
papel. Se o limite de credito consultado é insuficiente perante o pedido
recebido, o especialista comunica a recusa do financiamento aos
escreventes. Se o limite for suficiente, ele remete a folha de papel para o
Departamento de Práticas Comerciais.
4 - Os Escreventes, por sua vez, informam o resultado da análise de

limite de credito, verbalmente, para o vendedor da ABC mundial. A
solicitação de financiamento é arquivada por 24 (vinte e quatro) meses.
5 - O Departamento de Práticas Comerciais está incumbido de adaptar

as cláusulas padrão dos acordos de empréstimo à solicitação específica
do cliente. O departamento possui seu próprio sistema de computador.
Isso feito, o funcionário anexa os termos de contrato de financiamento
ao documento de solicitação. O processo documental é enviado para o
depto. Jurídico. As cláusulas padrão são mantidas pelo Gerente do
Depto. Jurídico.
6 - O Depto. Jurídico as analisa e pode devolver para o depto. De

práticas comerciais editá-las. Se as cláusulas especiais estiverem
adequadas, a solicitação passa para um Analista de Preços,
7 - O Analista de Preços digita os dados em uma planilha eletrônica

pessoal para determinar a taxa de juros apropriada a ser cobrada do
cliente. O analista de preços anota a taxa de juros na folha de papel, que
com os demais papeis é encaminhada a um grupo de escreventes.
8 - No grupo de escreventes, um administrador transforma todas essas

informações em uma carta de cotação.
9 - A cada dois duas úteis, o Administrador remete a Carta de cotação,

pelo correio, aos vendedores da ABC Mundial.
252
10 - O mesmo Administrador arquiva as Solicitações de Financiamento,

por 24 (vinte e quatro) meses.
253

EA&amp;BPM

Enviado por

Dados do documento

Descrição 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

EA&amp;BPM

Enviado por

Direitos autorais:

Formatos disponíveis

“AQUELE QUE BUSCA O

Marcio da Costa Coelho

1. A VISÃO ORGÂNICA E ESTRUTURADA DA EMPRESA

Cada um dos domínios de gestão é passível de ser

inalteráveis, e do outro lado, escolas ortodoxas que defendem que o

A gestão de mercado & produto

mercado e produtos/serviços serão dadas todas as variações da operação

Este domínio de gestão será abordado ao longo desta

consideraremos parte dos domínios de gestão de mercado & produto e

Uma grande parcela dos problemas que comprometem a

sem no entanto, em muitos casos, conseguir o alinhamento de seus

arquitetônica e chegaremos à especificação de engenharia para a

arquitetura, que pode ser aplicável a qualquer categoria de empresa ou

Uma breve visão da História da EA

estabeleceu que cada Agência e Departamento Federal teria a

TOGAFtm - The Open Group Architecture Framework

crescente, para a compreensão, definição e melhoria contínua da

BPM - Business Process Modeling

process improvement, BPO – Business process optimization, BPE -

Cenário atual do BPM

 Ferramenta com BSC (balanced score card) e outros métodos de

Uma breve visão da História do BPM

aumento da produtividade por 24.000%, ou seja, o mesmo número de

O mundo está estudando o assunto melhoria de processos

reduzindo atritos, desgastes, investimentos e prazos elevados quando

“Uma empresa é um conjunto de ações e respostas

Os ativos ou componentes são as dimensões, como as

sete dimensões. Essa comparação torna clara a inseparabilidade das

A Missão do BPM – Multidimensional é suportar

● Suporte à definição da arquitetura de negócio de alto nível;

Através do alinhamento do BPM Multidimensional com

As Duas Faces de Observação

A Sinergia de Esforços Apoiada pelo BPM – Multidimensional

As empresas investem em esforços para a busca de

A relação volume vs. variedade

Quanto maior a variedade e menor o volume, mais a

A relação serviço vs. matéria

4 - OS DOMINIOS ARQUITETONICOS NO BPM-M

4.1. ARQUITETURA DE NEGÓCIO

Processo de Negócio (Modelo de Operação do Negócio)

A Dimensão “Relações com Mercado”

planejada e ordenada a fim de produzir os outputs demandados pelo

A Dimensão Regras de Negócio

A Dimensão Recurso Humano

repetitiva e regrada, para com isso ter a primeira componente de um

A Dimensão Meio Ambiente

4.1. ARQUITETURA DE INFORMAÇÃO

A dimensão objetos de negócio

A dimensão grupos de dados

A dimensão Elemento de dado

Que são os atributos ou características de cada Objeto de

A Dimensão Sistema Aplicativos

o sistema produzindo a informação necessária àquele "step" da

Pacotes de Sistemas Aplicativos

A Dimensão Tecnologia de Informação - Orquestração de

4.4. ARQUITETURA DE INFRAESTRUTURA

Mudanças na arquitetura da operação do negócio podem

 Requerimentos de arquitetura de processadores;

5. A Certificação com base na Excelência Operacional

 Definição de documentação operacional;

7. A Análise de Problema como Instrumento de Melhoria

A aplicação prática da BPM-M se dá através da execução

 As etapas de um projeto de Transformação.

EA&BPM

EA&BPM