Representação Multi-Dimensional de Arquitecturas Empresariais

Representação Multi-Dimensional de Arquitecturas Empresariais

Mário Alexandre da Cruz Maçarico

Dissertação para obtenção do Grau de Mestre emEngenharia Informática e de Computadores

JúriPresidente: Prof. Alberto Manuel Rodrigues da SilvaOrientador: Prof. José Manuel Nunes Salvador TriboletCo-Orientador: Prof. Pedro Manuel Moreira Vaz Antunes de SousaVogal: Prof. Diogo Manuel Ribeiro Ferreira

Agosto 2007

Agradecimentos

Quero utilizar este espaço para dirigir algumas palavras de gratidão às pessoas cuja ajuda foi

essencial durante, não só o decorrer deste trabalho, mas também ao longo de todo o curso.

Para a minha mãe toda a minha gratidão, apesar de não existir gratidão suficiente que possa

recompensar todos os sacrifícios que realizou por mim e todos os maus momentos que eu passei que

foram sem dúvida tão dolorosos para ela como para mim.

Quero agradecer aos meus orientadores, o professor Tribolet e o professor Pedro Sousa, pelas

suas opiniões e conselhos que muito contribuíram para o enriquecer deste trabalho.

À Carla Pereira um muito obrigado pela sua completa disponibilidade, pela ajuda muito

necessária e pela sua orientação ao longo desta dissertação.

Quero também agradecer ao meu irmão e aos meus amigos pelos bons momentos de distracção

tão preciosos para recarregar baterias. Ao Valter pela sua continua boa disposição e pelo vício que temos

no karting (da próxima vez ganho eu). À Estela e Leonora, as amigas e colegas com quem mais vezes fiz

trabalhos de grupo. Ao Nuno, cujo sentido de humor é único no mundo (só um no mundo é o suficiente) e

os meus desejos de melhoras ao joelho recentemente operado. À Heike um obrigado por aturar todas as

minhas palermices (não deve ter sido fácil) e à telepatia que temos que por vezes assusta-me. Ao João

Mendes pela sua atitude sempre positiva. Ao Luís pelo apoio que deu nos maus momentos. E a todos

estes e mais alguns por serem bons amigos.

3

ResumoEste trabalho tem como objectivo introduzir um conjunto de regras aplicáveis a conceitos

empresariais. Estas regras têm como função garantir a rastreabilidade entre modelos empresariais. A

rastreabilidade entre modelos permite visualizar a arquitectura empresarial através das várias dimensões

que a constituem, podendo também funcionar como um filtro de forma a visualizar somente os elementos

relevantes numa determinada situação. Também é pretendido com este trabalho a preservação da

sintaxe utilizada na arquitectura empresarial. Isto significa a elaboração de um outro conjunto de regras

aplicáveis aos conceitos empresariais que possibilitem a detecção de potenciais problemas na

modelação.

Para atingir estes objectivos foi utilizada a framework de Zachman devido à divisão dos modelos

que constituem uma arquitectura empresarial em dimensões. Neste trabalho as dimensões What, How,

When, Where, Why e Who são associadas a conceitos empresariais. O conceito de processo de negócio

é aqui definido como o elemento agregador dos restantes conceitos empresariais. Isto possibilita a

rastreabilidade entre modelos e a visualização da arquitectura através das suas dimensões.

A introdução de níveis hierárquicos nos conceitos associados às dimensões permite a criação de

níveis de granularidade, utilizáveis na visualização da arquitectura. Esses níveis de granularidade

possibilitam a visualização da arquitectura conforme o grau de abstracção desejado. Adicionalmente,

podem ser aplicadas regras aplicáveis aos conceitos de níveis de granularidade diferentes, essas regras

permitem auxiliar a modelação e detectar erros de modelação.

As regras foram implementadas no programa System Architect, o qual funcionará como um

repositório de processos. De forma a validar o trabalho, o meta-modelo do programa foi estendido. Foi

também criada uma extensão ao programa que implementa as regras definidas e utilizado um caso de

estudo real para validar a implementação.

Palavras-Chave: Arquitectura, Processo de negócio, Zachman, Dimensões, Consistência, Interligação,

Representação

5

AbstractThis work aims to introduce a set of rules to be used with organizational concepts. These rules

are meant to maintain rastreability between enterprise models. The rastreability between models allows

representing the enterprise architecture by its several dimensions, and can be used as a filter to only

visualize the relevant elements in a concrete situation. Another goal of this work is to preserve the syntax

used in the enterprise architecture. This means the elaboration of another set of rules with the objective of

detecting potential modelling problems.

The Zachman Framework was used in this work to achieve these goals. This was due to its

division of the modelling models by several dimensions. In this work the dimensions What, How, When,

Where, Why and Who are related to modelling concepts. The business process modelling concept is

defined where as the glue between other modelling concepts. This aggregation allows the rastreability

between models and the visualization of the architecture through its dimensions.

The addition of hierarchical leveling in modelling concepts allows the creation of abstraction

levels. These levels can also be used to visualize the architecture, depending on the detail level desired.

Also, rules can be applied between abstraction levels with the aim to help the modelling effort and detect

modelling errors.

These rules where implemented in the program System Architect. To validate this work the

System Architect was used as a process repository. Its meta-model was extended and a macro that

implemented the rules was written. Afterwards the work was validated with a real case study.

Key-words: Architecture, Business Process, Zachman, Dimensions, Inter-connection, Rules,

Representation

6

ÍndiceAGRADECIMENTOS.................................................................................................................................................. 3

RESUMO........................................................................................................................................................................ 5

ABSTRACT....................................................................................................................................................................6

ÍNDICE IMAGENS....................................................................................................................................................... 9

ÍNDICE TABELAS..................................................................................................................................................... 10

1.INTRODUÇÃO.........................................................................................................................................................12

1.1.CONTEXTO..............................................................................................................................................................121.2.OBJECTIVOS............................................................................................................................................................ 13

2.ESTADO DA ARTE................................................................................................................................................. 14

1.1 ARQUITECTURAS EMPRESARIAIS................................................................................................................................142.1.FRAMEWORK DE ZACHMAN....................................................................................................................................... 152.2.PROCESSO DE NEGÓCIO............................................................................................................................................ 172.3.PROCESSOS DE NEGÓCIO E DIMENSÕES......................................................................................................................... 19

3.REPRESENTAÇÃO MULTIDIMENSIONAL DE ARQUITECTURAS EMPRESARIAIS...........................22

3.1.META-MODELO....................................................................................................................................................... 223.1.2.Níveis de Granularidade.............................................................................................................................25

3.2.REPRESENTAÇÃO DOS PROCESSOS E DAS DIMENSÕES...................................................................................................... 263.2.1.Representação dos Processos..................................................................................................................... 263.2.2.Representação dos Actores, Entidades Informacionais, Objectivos, Tempos e Localizações................... 283.2.3.Tipos de representações..............................................................................................................................28

3.3.REGRAS................................................................................................................................................................. 303.3.1.Regras Tipo 1.............................................................................................................................................. 303.3.2.Regras Tipo 2.............................................................................................................................................. 33

4.VALIDAÇÃO DO TRABALHO............................................................................................................................. 37

4.1.ANÁLISE DOS DIAGRAMAS EXISTENTES NO “SYSTEM ARCHITECT”................................................................................... 384.2.DIAGRAMAS UTILIZADOS.......................................................................................................................................... 42

4.2.1.Diagrama de processo de negócio (Diagrama BPMN)..............................................................................424.2.2.Diagrama Business Process Hierarchy...................................................................................................... 434.2.3.Diagrama Organization Chart................................................................................................................... 434.2.4.Diagrama Enterprise Direction.................................................................................................................. 44

4.3.DIAGRAMAS CRIADOS............................................................................................................................................... 454.3.1.Diagrama Informação................................................................................................................................ 454.3.2.Diagrama Actores....................................................................................................................................... 464.3.3.Diagrama Tempo........................................................................................................................................ 46

4.4.DEFINIÇÕES UTILIZADAS NO SYSTEM ARCHITECT..........................................................................................................474.5.IMPLEMENTAÇÃO..................................................................................................................................................... 48

4.5.1.Meta-modelo do System Architect...............................................................................................................484.5.2.Construção dos modelos............................................................................................................................. 484.5.3.Implementação da macro............................................................................................................................49

5.CASO DE ESTUDO INATEL................................................................................................................................. 61

5.1.INTRODUÇÃO...........................................................................................................................................................615.2.CONTEXTO..............................................................................................................................................................625.3.EXTENSÕES AO TRABALHO.........................................................................................................................................64

5.3.1.Dimensão Sistema....................................................................................................................................... 64

7

5.3.2.Representação da transição do “As Is” para o “To Be”........................................................................... 655.4.REGRAS................................................................................................................................................................. 69

5.4.1.Substituição de dimensões usadas nos processos por dimensões de mais alto nível................................. 695.4.2.Balanceamento de Processos......................................................................................................................695.4.3.Processos de negócio folha com dimensões não folha............................................................................... 705.4.4.Processos equivalentes detectados............................................................................................................. 715.4.5.Processos sem inputs, processos sem outputs, processos sem actores, processos sem localizações, processos sem tempos.......................................................................................................................................... 755.4.6.Processos sem Objectivos........................................................................................................................... 755.4.7.Processos folha com duas ou mais dimensões do mesmo tipo (excluindo a dimensão What)................... 75

6.CONCLUSÕES......................................................................................................................................................... 79

7.OBJECTIVOS ATINGIDOS...................................................................................................................................80

8.TRABALHO FUTURO............................................................................................................................................81

REFERÊNCIAS...........................................................................................................................................................82

ANEXO A – MANUAL DO UTILIZADOR............................................................................................................. 84

1.1.PREPARAR ENCICLOPÉDIA PARA A MACRO.....................................................................................................................841.2.DEFINIÇÃO DOS PROCESSOS DE NEGÓCIO...................................................................................................................... 841.3.DEFINIÇÃO DOS ACTORES, ENTIDADES INFORMACIONAIS, LOCALIZAÇÕES, OBJECTIVOS, TEMPOS E SISTEMAS............................. 851.4.REPRESENTAÇÃO VISUAL DAS DIMENSÕES E DOS PROCESSOS............................................................................................85

1.4.1.Processo...................................................................................................................................................... 851.4.2.Actor............................................................................................................................................................851.4.3.Localização................................................................................................................................................. 861.4.4.Objectivo..................................................................................................................................................... 861.4.5.Tempo..........................................................................................................................................................861.4.6.Entidade Informacional.............................................................................................................................. 861.4.7.Sistema........................................................................................................................................................ 87

1.5.INTERFACE REPRESENTAÇÃO MULTI-DIMENSIONAL...................................................................................................... 871.5.1.Representação das dimensões.....................................................................................................................891.5.2.Visualização do “As-Is” e do “To-Be”...................................................................................................... 901.5.3.Regras......................................................................................................................................................... 901.5.4.Pesquisa...................................................................................................................................................... 91

1.6.AUXILIO VISUAL À TRANSIÇÃO DO “AS-IS” E “TO-BE” NOS PROCESSOS.......................................................................... 931.6.1.Visualização das relações dos processos no diagrama actual................................................................... 931.6.2.Explorador “As-Is” “To-Be”..................................................................................................................... 941.6.3.Visualização das dimensões........................................................................................................................95

1.7.ANALYTICS.............................................................................................................................................................961.7.1.Dimensão não utilizada em processos........................................................................................................ 971.7.2.Actor não associado a localizações............................................................................................................ 971.7.3.Localização sem actores associados.......................................................................................................... 98

1.8.EXPORTAR MATRIZES................................................................................................................................................98

ANEXO B – USERPROPS..........................................................................................................................................99

2.1.INTRODUÇÃO...........................................................................................................................................................992.2.CONFIGURAÇÃO UTILIZADA........................................................................................................................................99

8

Índice Imagens– REPRESENTAÇÃO DE UM PROCESSO ATRAVÉS DAS DIMENSÕES......................................................20

META-MODELO........................................................................................................................................................ 22

– REPRESENTAÇÃO DOS PROCESSOS...............................................................................................................27

– REPRESENTAÇÃO DE UM PROCESSO COM DIMENSÕES........................................................................ 27

– REPRESENTAÇÃO DE UM ACTOR................................................................................................................... 28

– INCONSISTÊNCIA ENTRE PROCESSOS, ACTORES E LOCALIZAÇÕES................................................31

– PROCESSO PAI COM DIMENSÃO MENOS GENÉRICA............................................................................... 33

– BALANCEAMENTO DAS DIMENSÕES USADAS............................................................................................ 34

– BALANCEAMENTO NOS NÍVEIS HIERÁRQUICOS...................................................................................... 34

– DECOMPOSIÇÃO DE UM PROCESSO.............................................................................................................. 35

– DIAGRAMA BPMN COM A NOTAÇÃO DE INPUTS E OUTPUTS............................................................... 42

– BUSINESS PROCESS HIERARCHY....................................................................................................................43

– ORGANIZATION CHART.....................................................................................................................................44

– ENTERPRISE DIRECTION...................................................................................................................................45

– DIAGRAMA DE INFORMAÇÃO..........................................................................................................................46

– VISUALIZAÇÃO DOS PROCESSOS E SUBPROCESSOS DE NEGÓCIO ATRAVÉS DA MACRO.........50

– VISUALIZAÇÃO DOS PROCESSOS DE NEGÓCIOS TENDO EM CONTA TODAS AS DIMENSÕES.. 51

– VISUALIZAÇÃO DE UM ACTOR ATRAVÉS DA DIMENSÃO WHEN, WHAT, WHERE, E WHO........ 52

– PROCESSOS FOLHA COM 2 OU MAIS DIMENSÕES DO MESMO TIPO.................................................. 53

– LOCALIZAÇÕES FOLHA SEM ACTORES....................................................................................................... 54

– PROCESSOS EQUIVALENTES............................................................................................................................ 55

– PESQUISA DE PROCESSOS SEM DIMENSÕES TIPO....................................................................................56

– PESQUISA DE PROCESSOS POR ELEMENTOS ESPECÍFICOS..................................................................57

– TRANSIÇÃO DO MODELO AS-IS PARA O MODELO TO-BE DE UM ACTOR.........................................59

– REPRESENTAÇÃO VISUAL DA TRANSIÇÃO DO MODELO AS-IS PARA O MODELO TO-BE DOS PROCESSOS................................................................................................................................................................60

– VISIO CRIADO POR FUNCIONÁRIOS DO INATEL.......................................................................................63

– META-MODELO COM SISTEMA....................................................................................................................... 65

– DIAGRAMA DE SISTEMAS..................................................................................................................................65

– TRANSIÇÃO DE UM ACTOR "AS IS" PARA O "TO BE" E A RELAÇÃO COM OS PROCESSOS....... 67

– PROCESSOS "AS IS" RELACIONADOS COM O PROCESSO "TO BE".....................................................67

- EXPLORADOR "AS-IS" "TO-BE"....................................................................................................................... 68

– REPRESENTAÇÃO DOS PROCESSOS...............................................................................................................85

– REPRESENTAÇÃO DOS ACTORES................................................................................................................... 86

9

– REPRESENTAÇÃO DAS LOCALIZAÇÕES.......................................................................................................86

– REPRESENTAÇÃO DOS OBJECTIVOS.............................................................................................................86

– REPRESENTAÇÃO DOS TEMPOS......................................................................................................................86

– REPRESENTAÇÃO DAS ENTIDADES INFORMACIONAIS..........................................................................87

– REPRESENTAÇÃO DE INPUTS...........................................................................................................................87

– REPRESENTAÇÃO DE OUTPUTS...................................................................................................................... 87

– REPRESENTAÇÃO DE SISTEMAS..................................................................................................................... 87

– MENU PRINCIPAL................................................................................................................................................. 88

– VISUALIZAÇÃO DA ARQUITECTURA ATRAVÉS DOS PROCESSOS DE NEGÓCIO............................89

– VISUALIZAÇÃO DA ARQUITECTURA ATRAVÉS DOS ACTORES........................................................... 90

– PESQUISA DE PROCESSOS DE NEGÓCIO ATRAVÉS DE DIMENSÕES TIPO........................................92

– PESQUISA DE PROCESSOS DE NEGÓCIO ATRAVÉS DE ELEMENTOS CONCRETOS....................... 93

– PROCESSO DE NEGÓCIO NÃO UTILIZADO NO "TO-BE"......................................................................... 94

– PROCESSO NOVO NO "TO-BE"......................................................................................................................... 94

– PROCESSO REUTILIZADO..................................................................................................................................94

- EXPLORADOR "AS-IS" "TO-BE"....................................................................................................................... 95

– TRANSIÇÃO DO ACTOR "PESSOA_1-AS-IS"..................................................................................................96

– ACTOR NÃO USADO NOS PROCESSOS E NÃO ASSOCIADO A NENHUMA LOCALIZAÇÃO............97

– DIMENSÃO NÃO UTILIZADA............................................................................................................................. 97

– ACTOR NÃO ASSOCIADO A LOCALIZAÇÕES.............................................................................................. 98

– LOCALIZAÇÃO SEM ACTORES ASSOCIADOS............................................................................................. 98

Índice Tabelas

TABELA 1 DIMENSÕES DA FRAMEWORK DE ZACHMAN (SOUSA 2006).................................................16

TABELA 2 RELAÇÕES ENTRE PRIMITIVAS E DIMENSÕES........................................................................ 24

TABELA 3 MAPEAMENTO DOS DIAGRAMAS E DEFINIÇÕES DO “SYSTEM ARCHITECT” ÀS CÉLULAS DA FRAMEWORK DE ZACHMAN (PERSPECTIVA CONCEPTUAL)........................................38

TABELA 4 – ANÁLISE DOS DIAGRAMAS EM RELAÇÃO ÀS DIMENSÕES............................................... 40

TABELA 5 – SUBIR O NÍVEL GRANULARIDADE DAS PRIMITIVAS UTILIZADAS.................................69

TABELA 6 – BALANCEAMENTO ENTRE PROCESSOS E DIMENSÕES...................................................... 70

TABELA 7 – PROCESSOS COM DIMENSÕES NÃO FOLHA........................................................................... 71

TABELA 8 – PROCESSOS EQUIVALENTES.......................................................................................................72

TABELA 9 – PROCESSOS SEM CONCLUSÃO NA EQUIVALÊNCIA.............................................................74

TABELA 10 – PROCESSOS DE NEGÓCIO FOLHA COM DUAS OU MAIS DIMENSÕES DO MESMO TIPO..............................................................................................................................................................................78

TABELA 11 – OBJECTOS E RESPECTIVOS DIAGRAMAS..............................................................................85

10

1.Introdução

1.1.Contexto

Devido à complexidade das organizações é necessário utilizar métodos que permitam lidar com

essa complexidade. Normalmente para se lidar com a complexidade das empresas, utilizam-se métodos

que decompõem essa complexidade em partes ou domínios menos complexos.

Uma arquitectura empresarial específica como a organização, como um todo, pode ser

decomposta em componentes individuais. A decomposição desses componentes, a sua definição e o

modo como interagem uns com os outros constitui a arquitectura empresarial (Iyer B. 2004). A

arquitectura empresarial é um método que tenta fornecer uma abstracção sobre como um negócio

funciona. Esta simplificação da organização possibilita uma melhor compreensão da organização, e

através dela, a identificação de oportunidades para melhorar o negócio (Eriksson 2001, página 3).

Para representar arquitecturas empresariais são utilizados modelos empresariais. Um modelo

empresarial permite representar uma parte da organização, e desta forma reduzir a complexidade

referida anteriormente. Com modelos suficientes é possível representar todas as partes existentes da

organização. O problema reside em saber como os vários elementos, existentes nos múltiplos modelos

organizacionais, funcionam entre si. Para se conseguir obter uma representação completa da

organização não basta possuir todas as peças do puzzle que constituem a organização. É também

necessário saber como essas peças encaixam entre si, de forma a se obter uma imagem completa da

organização.

Para tal é necessário introduzir um modelo que permita interligar os elementos básicos da

arquitectura empresarial. É necessário referir que os modelos empresariais não possuem essa

informação incutida. Como consequência, as interacções entre elementos têm de ser obtidas na própria

organização.

A interligação dos elementos básicos permite visualizar a arquitectura empresarial através de

vistas lógicas. Estas vistas representam a forma como os elementos interagem entre si. Tomemos como

exemplo a vista com foco na segurança (que pessoas têm acesso a que objectos?). A informação

necessária para responder a esta questão está na forma como os elementos dos modelos interagem

entre si. Neste caso, trata-se do modelo que contem a informação dos objectos existentes na

organização, e do modelo que contem as pessoas existentes na organização. Ao relacionar os elementos

destes dois modelos obtém-se a resposta à questão atrás referida.

Outra vantagem em fazer a interligação entre modelos é a possibilidade de introduzir regras à

forma como os modelos interagem entre si. Estas regras visam em auxiliar a modelação da organização

12

e têm como objectivo detectar erros na modelação da organização. Caso a modelação esteja correcta, as

regras permitem detectar pontos de ineficiências na própria organização.

A framework de Zachman é uma framework que permite construir arquitecturas empresariais.

Possui um esquema em matriz que fornece uma divisão lógica dos modelos empresariais necessários

para representar uma organização. Utiliza um conjunto de dimensões (Who, What, How, Where, Why e

When) e perspectivas para realizar a divisão da arquitectura empresarial.

1.2.Objectivos

Este trabalho foi elaborado com os seguintes objectivos principais:

• Elaborar um modelo que permita visualizar arquitecturas empresariais através de uma

das dimensões que a constitui, ou através da combinação de várias dimensões de forma

a criar uma representação da arquitectura empresarial com foco numa preocupação

específica de um stakeholder.

• Garantir rastreabilidade entre os modelos empresariais empregues numa arquitectura

empresarial. O modelo deve também permitir representar a organização em várias

camadas de abstracção, e desta forma controlar o nível de detalhe pelo qual se deseja

visualizar a organização.

• Definição de um conjunto de regras que garantem a preservação da sintaxe numa

arquitectura empresarial. Estas regras devem portanto, garantir que a arquitectura

empresarial construída é consistente e detectar problemas de modelação e problemas

existentes na própria organização.

Foi definido o seguinte objectivo secundário:

• Definir uma representação para a transição do modelo “As-Is” para o modelo “To-Be” de

forma a auxiliar esta etapa.

13

2.Estado da arte

1.1 Arquitecturas Empresariais

Devido à crescente complexidade das organizações é necessário utilizar métodos que permitam

reduzir a essa complexidade para se melhor compreender e melhorar o funcionamento da organização.

As arquitecturas empresariais são utilizadas com esse objectivo. As arquitecturas permitem uma

representação simplificada da organização, um rápido redesenho de processos e conceitos empresariais,

garantir rastreabilidade desde o nível estratégico até ao nível tecnológico e identificar potenciais

problemas e pontos para aumento de desempenho e produtividade.

De acordo com (Towers S 2005) uma arquitectura empresarial é utilizada para:

• Suportar a implementação da estratégia, de acordo com vários níveis.

• Clarificar as responsabilidades de todos dentro da organização, e permitir a definição de

objectivos colaborativos em vez de partilhados.

• Definir uma framework da qual se pode analisar a situação “AS IS” de cada processo.

Para representar a vasta complexidade existente nas típicas organizações, é necessário

apresentar as arquitecturas, não no seu todo, mas nas suas partes. As arquitecturas consistem num

conjunto de modelos que representam várias partes da organização. Perspectivas (ou vistas) sobre a

arquitectura empresarial permitem representar parte da organização na qual estão ocultos elementos não

relevantes sob um determinado aspecto. Várias frameworks definem ou recomendam a utilização de

determinadas perspectivas. Porém estas perspectivas estão muitas vezes associadas aos vários

stakeholders (por exemplo, administração/perspectiva visão de negócio), ou então a elementos

individuais do negócio (como exemplo, perspectiva de recursos). Têm como objectivo detalhar todas as

estruturas relevantes da organização, tais como negócio, aplicações, tecnologia e informação, entre

outras.

Rittgen propõe modelar a multidimensionalidade de uma arquitectura empresarial em cinco vistas

(Rittgen página 76):

Arquitectura organizacional. Lida com aspectos da organização que não estão directamente

relacionados com o negócio nem com os mecanismos utilizados para criar valor. Inclui conceitos de

missão, visão de negócio e estratégia e a definição de unidades organizacionais.

14

Arquitectura de negócio. Resulta da implementação das estratégias de negócio e da definição

de processos. Nesta vista o conceito fundamental é o de processo de negócio, o qual adiciona valor à

organização e opera através de inputs e outputs.

Arquitectura informacional. Descreve os objectos que a organização necessita para executar

os processos descritos na arquitectura de negócio. É estruturada numa colecção de entidades

informacionais.

Arquitectura de aplicações. Define as aplicações necessárias à gestão da informação e ao

suporte ao negócio.

Arquitectura tecnológica. Representa a tecnologia utilizada na implementação das aplicações.

Define também a infraestrutura necessária à execução dos sistemas de suporte aos processos de

negócio.

Dado que as arquitecturas são compostas por vistas/perspectivas de modelos cujas interacções

com outros modelos não estão definidas, não é possível garantir rastreabilidade entre estas. Conforme já

foi referido, para se conseguir uma completa representação da organização também é necessário saber

as relações entre os elementos que constituem a organização. É neste aspecto que este trabalho se foca.

2.1.Framework de Zachman

Desenvolvida por Zachman em 1987, a framework de Zachman fornece um esquema para a

classificação dos modelos das arquitecturas empresariais (Zachman, 2003).

A framework é composta por seis (6) perspectivas e seis (6) dimensões. Uma perspectiva pode

ser definida como a observação da arquitectura empresarial na óptica de vários stakeholders (Rittgen

2006, página 74).

As perspectivas são:

• Scope (Contextual). Relacionada com aspectos estratégicos da organização e contexto

ambiental.

• Business model (Conceptual). Relacionada com a perspectiva de negócio da

organização, como produz valor e como é utilizada.

• System Model (Lógico). Relacionada com os sistemas da organização.

• Technology model (Físico). Relacionada com a tecnologia utilizada para suportar os

sistemas e negócio da organização.

• Detailed representation (subcontractor’s perspective). Relacionado com as

especificações dos componentes do sistema que será sub-contratado internamente ou

por terceiros.

• Functioning enterprise

Neste trabalho trabalhou-se essencialmente com a perspectiva Business model (Conceptual).

15

A framework é representada por uma matriz cujas colunas correspondem às dimensões, e as

linhas às perspectivas. Esta combinação entre perspectivas e dimensões permitem a divisão lógica de

toda a arquitectura empresarial. Uma célula da tabela representa portanto uma preocupação de um

determinado stakeholder. De notar que a framework não impõe qualquer restrição quanto à construção

dos modelos, apenas define a estrutura necessária para a classificação dos elementos que constituem a

arquitectura empresarial.

As dimensões da framework de Zachman são interrogativas básicas pelas quais os utilizadores

podem interrogar a arquitectura.

Neste trabalho as dimensões escolhidas para a representação multi-dimensional de arquitecturas

foram as dimensões as dimensões da framework de Zachman. (Zachman, 2003) . Estas são

• What

• How

• Where

• Why

• Who

• When

A tabela 1 explica as várias dimensões da framework de Zachman e como se relacionam com o

negócio.

Dimensão Focos PropósitoWhat Dados Os dados da organização e como são utilizados.How Função O processo de traduzir a missão da organização para

negócios.Who Pessoas Quem está relacionado com os “major artifacts” da

organização: processos de negócio, informação e IT. Células de alto nível referem-se a unidades organizacionais. As de baixo nível aos utilizadores dos sistemas.

When Tempo A forma como os artefactos da organização se relacionam e evoluem ao longo do tempo.

Why Motivação A tradução dos “goals” para acções e objectivosWhere Network A distribuição geográfica das actividades e artefactos

da organização.Tabela 1 Dimensões da framework de Zachman (Sousa 2006)

Apesar de a framework contemplar qualquer aspecto de uma arquitectura empresarial através

das suas dimensões e perspectivas, verifica-se que a framework não define um meta-modelo para a

integração da informação de cada célula1 (Rittgen 2006, página 75).

1 Intercepção entre uma dimensão e uma perspectiva da framework de Zachman

16

Neste trabalho o termo “primitiva” é definido como um conceito empresarial fundamental à

construção de um modelo empresarial. Para cada célula da framework de Zachman existe uma primitiva

concreta (Locke).

A framework assume possuir todas as primitivas necessárias à classificação da organização.

Elementos primitivos não explícitos são elementos implícitos (Zachman, 2007).

O capítulo 2 apresenta mais detalhes sobre a interligação destas primitivas.

2.2.Processo de Negócio

O conceito de processo de negócio é fundamental na elaboração deste trabalho. Este conceito permite

representar as várias acções que uma organização desempenha para realizar o seu negócio. Todas as

organizações executam processos, sendo o número de processos dependente da dimensão e da

complexidade da própria organização.

Existem várias definições para o termo “processo de negócio”. Algumas destas definições são:

• (Smith 2006) afirma que “A business process is the complete and dynamically coordinated set of

collaborative and transactional activities that deliver value to customers”.

• “An approach to doing something that consists of a number of activities, each of which will

produce and/or consume some sort of artifact. Each of these activities is the responsibility of a

single stakeholder” (Holt 2005)

• (Rittgen 2006) apresenta um conjunto de definições encontradas para processo de negócio:

o “The set of internal activities performed to serve a customer. The purpose of each business

process is to offer each customer the right product or service, with a high degree of

performance measures against cost, longevity, service, and quality.”

o “A set of coherent activities that creates a result with some value for an internal or external

customer; it is a meaningful whole of value-adding activities.”

o “The manner in which work is organized, coordinated, and focused to produce a valuable

product or service.”

o “A collection of activities that takes one or more kinds of inputs and creates an output that is of

value to the customer.”

Destas definições o factor comum é “a business process is a coordinated set of activities that is able to

add value to the customer and achieve business goals”.

17

• (Marshall, 1999) classifica processo de negócio como: “A series of coherent activities that creates

a result with some value for an external or internal customer; It is a meaningful whole of value

adding activities. A kind of process that supports and/or is relevant to business organizational

structure and policy for the purpose of achieving business objectives. This includes both manual

processes and/or workflow processes.”

(Eriksson, 2001, página 68) define processo de negócio como:

• Tem um objectivo.

• Tem um input específico.

• Tem um output específico.

• Usa recursos.

• Tem um numero de actividade que são executadas numa ordem, dependendo das condições e

eventos que podem ocorrer durante a execução do processo. As actividades dentro do processo

podem ser vistas como sub-processos.

• Afecta mais que uma unidade organizacional. É horizontal à organização.

• Cria valor para um determinado tipo de cliente. O cliente pode ser interno ou externo ao negócio.

(Sousa, 2006) possui a definição de processo de negócio que mais interessa a este trabalho.

Esta é:

• “A business process can be inferred as a set of connected activities with inputs and outputs,

which interact with people, contribute to achieving business goals, take place in a specific location

and occur during a period of time”.

Destas definições pode-se afirmar que um processo possui as seguintes características:

• É transversal à organização.

• Cria valor à organização.

• É constituído por actividades ou sub-processos

Outras características dos processos de negócio de especial interesse neste trabalho são

aqueles definidas por (Sousa, 2006) :

• Possuem inputs e outputs.

• Interagem com pessoas (actores no contexto deste trabalho).

• Contribuem para atingir objectivos de negócio.

• Ocorrem num local específico.

• Ocorrem durante um período de tempo.

18

Devido a estas características, o processo de negócio é a escolha lógica para ser o conceito

fundamental na modelação e representação de arquitecturas empresariais. O processo de negócio é o

principal conceito de “business process modelling”, devido à sua produção de valor para a organização e

à sua horizontalidade em relação ao negócio, o que permite modelar vários aspectos da organização

através da sua observação.

Também o é no contexto deste trabalho pois as suas características permitirem uma boa

interligação entre primitivas organizacionais. São estas primitivas que irão ter uma correspondência com

as dimensões utilizadas neste trabalho. O processo de negócio é, no contexto deste trabalho, o elemento

principal e unificador entre as dimensões, e é através dele que as interligações entre as várias dimensões

serão realizadas.

2.3.Processos de negócio e dimensões

Conforme referido, a framework de Zachman não define as relações entre as primitivas de cada

célula da framework. Para tal ser possível, pode-se utilizar elemento que possua relações com essas

primitivas.

Das definições de processo de negócio referidas na secção Processo de Negócio, página 17,

verifica-se através das características dos processos de negócio que estes são facilmente mapeáveis às

primitivas das células na perspectiva conceptual da framework de Zachman. Isto levou à utilização do

processo de negócio como o conceito que agrega as primitivas da perspectiva conceptual.

Portanto, na perspectiva conceptual da framework de Zachman, é possível estabelecer uma

relação entre o conceito de processo de negócio e as dimensões.

Para se concretizar essa integração entre primitivas e processos de negócio, é necessário

recolher essa informação da organização quando se efectua o levantamento dos processos da

organização.

A Imagem 1 mostra a representação de um processo (Processo X) através de dimensões, e

como estas podem facilitar a visualização dos vários elementos que constituem a organização, bem como

a forma como estão relacionados entre si. De acordo com (Sousa, 2006), as dimensões permitem aplicar

o conceito de “camada” a cada objecto existente no repositório de processos de negócio. (Sousa, 2006)

propõe seis camadas, com cada camada associada a uma dimensão, de forma a aumentar a capacidade

de extracção de informação do repositório de processos de negócio.

19

Imagem 1 – Representação de um processo através das dimensões

A associação entre dimensões permite a representar a arquitectura através das ligações de

interesse para um stakeholder. Por exemplo, um stakeholder interessado com a segurança de

determinada entidade informacional pode visualizar onde essa entidade informacional é utilizada e por

quais actores, (dimensão What, Where e Who). A própria actividade de modelação da organização é

auxiliada através da inclusão de regras definidas na associação de processos de negócio e primitivas, ver

secçãoRegras página 30. Adicionalmente, esta integração entre elementos de vários modelos

organizacionais introduz uma grande componente de rastreabilidade em toda a arquitectura.

20

3.Representação Multidimensional de Arquitecturas Empresariais

A representação multidimensional de arquitecturas empresariais tenta estabelecer relações entre

as dimensões de uma organização (Who, What, Where, Why, How, When). Normalmente um modelo

empresarial representa apenas uma das dimensões, porém possuir modelos de todas as dimensões não

é o suficiente para possuir a representação completa da organização. É necessário também obter

informação da organização sobre como cada dimensão se relaciona com as restantes.

Para se obter uma interligação entre as dimensões foi utilizado um conceito empresarial com

características que possibilitam a sua relação com cada uma das dimensões, e como consequência a

interligação entre uma dimensão e as restantes deste elemento agregador. Esse conceito empresarial foi

o de “processo de negócio”.

3.1.Meta-modelo

Processo Entidade InformacionalActor

Objectivo Tempo

Localização

* **

*

*

1

**

*

*

1

*

1*

1*

**

1*1

*

**

Input

Output*

*

Imagem 2 Meta-modelo

O meta-modelo criado para a representação multidimensional de arquitecturas empresariais é um

modelo que necessita relacionar primitivas. Para tal foi criado o meta-modelo representado na Imagem 2.

Ao processo de negócio está associado um conjunto de primitivas, cada primitiva por sua vez

está relacionada com uma dimensão de Zachman. Desta forma um processo de negócio está associado

a entidades informacionais, localizações, objectivos, actores e tempos. Estas primitivas (entidades

informacionais, localizações, objectivos, actores, processos e tempos) estão directamente associadas às

22

várias dimensões descritas pela framework de Zachman. Estas relações permitem representar o negócio

através das várias dimensões da framework de Zachman.

Conforme pode-se observar no modelo, todas estas primitivas são definidas de forma

hierárquica. Deste modo são modelados vários níveis de granularidade na arquitectura empresarial.

3.1.1.1.Primitivas

3.1.1.1.1.Processo de Negócio

A dimensão How representa como se executa uma determinada tarefa ou processo. Esta

dimensão está associada ao próprio conceito processo de negócio. Uma vez que os processos de

negócio são decompostos em sub-processos, esta dimensão permite visualizar em vários níveis de

granularidade o “como” se executa o negócio, desde os macro-processos até às actividades ou

processos folha.

3.1.1.1.2.Tempo

A dimensão When está associada à primitiva Tempo. Esta primitiva indica uma frequência de

execução. Um tempo associado a um processo revela a frequência de realização do processo (por

exemplo, uma vez por dia, ou 3 vezes por ano, uma vez por programa).

3.1.1.1.3.Entidade Informacional

A dimensão What está associada com Entidades Informacionais. Entidades informacionais

representam os objectos utilizados, consumidos ou criados num processo (por exemplo, uma factura),

(Macedo 2005). A sua associação com um processo pode ser de duas formas:

• Input: São entidades informacionais que processos de negócio necessitam para serem

executados.

• Output: São entidades informacionais resultantes da execução de um processo de

negócio.

3.1.1.1.4.Localização

A dimensão Where está associada a Localizações (podem ser por exemplo, departamentos de

uma organização ou localizações geográficas). Estas indicam a localização onde o processo é realizado.

As localizações também são locais onde actores executam as suas tarefas. Por consequência o

meta-modelo utilizado reflecte essa associação. Esta associação permite introduzir mais algumas regras

de consistência às dimensões.

23

3.1.1.1.5.Actor

Actores são capazes de desempenhar um conjunto de serviços que definem um papel. Estes

serviços estão relacionados com as competências, capacidades e outros atributos ligados à pessoa que

são relevantes no contexto de uma actividade (Rittgen 2006, página 88).

A dimensão Who está associada a actores. Os actores representam funções específicas numa

organização (por exemplo, chefe de departamento) e indicam quem é responsável e quem realiza o

processo de negócio. No meta-modelo está definida uma relação entre os actores e as localizações, dado

que a estes devem estar alocados a sítios de trabalho.

3.1.1.1.6.Objectivo

Objectivos são metas estabelecidas com o intuito de expressar como se deve atingir uma

estratégia.

Um objectivo pode ser decomposto em sub-objectivos. Atingir o objectivo superior é dependente

de atingir os sub-objectivos. Também alguns sub-objectivos podem substituir ou compensar sub-

objectivos falhados (Eriksson 2001, página 79).

A dimensão Why está associada a objectivos, os quais estão associados aos processos de

negócio que os atingem.

3.1.1.2.Relações entre as primitivas e dimensõesCada dimensão está directamente relacionada com uma primitiva organizacional. As relações

entre as dimensões e as primitivas estão representadas no meta-modelo e na Tabela 2.

Objecto DimensãoEntidade Informacional What

Localização WhereProcesso de negócio How

Actor WhoObjectivo Why

Tempo WhenTabela 2 Relações entre primitivas e dimensões

24

3.1.2.Níveis de Granularidade

A estrutura definida pelo meta-modelo permite a decomposição dos elementos em sub-elementos

do mesmo tipo.

Esta decomposição dos processos de negócio, objectivos, actores, localizações, tempos e

entidades informacionais permite definir modelos numa estrutura hierárquica.

Os processos de negócio, conforme já referido na sua definição, podem ser decompostos em

sub-processos que mostram como este é realizado.

Os objectivos, também pela sua definição, podem ser decompostos em sub-objectivos que

devem ser atingidos de forma a atingir o objectivo pai.

Um actor pode ser também visto como um papel que alguém desempenha na organização, a

esse actor podem estar relacionados sub-papéis. Por este motivo os actores podem ser definidos

hierarquicamente.

As localizações que representam as localizações ou departamentos existentes na organização. A

definição das localizações é feita de forma hierárquica.

Também os tempos são elementos que podem ser definidos em hierarquias. Desde uma

hierarquia cuja frequência de execução está dependente do tempo (por exemplo, uma vez por semana,

duas vezes por semana…) ou de qualquer evento (exemplo, uma vez por programa).

Estas estruturas hierárquicas dos elementos permitem a construção de arquitecturas empresarias

com várias camadas de granularidade. Isto significa que a arquitectura pode ser visualizada consoante a

nível de detalhe desejado por parte do stakeholder. Níveis de granularidade grandes permitem visualizar

a arquitectura com um elevado grau de abstracção, nos quais se encontram omitidos detalhes

irrelevantes. Níveis de granularidade baixos mostram o máximo de detalhes da arquitectura.

Os níveis de granularidade e a interligação das primitivas entre si permitem construir regras com

o objectivo de garantir que a informação é correctamente modelada e possui a granularidade apropriada.

(Ver regras página 30).

25

3.2.Representação dos processos e das dimensões

A interligação das dimensões aos processos, e a definição hierárquica das primitivas permite a

representação da arquitectura através de composições e combinações de dimensões. Isto significa,

conforme já foi referido, que além de se poder representar a arquitectura conforme cada dimensão,

podem-se também criar vistas muito específicas (Sousa, 2006). Exemplo disso é obter uma vista da

arquitectura cuja preocupação é visualizar as permissões existentes na organização. Para tal poder-se-ia

utilizar a dimensão Who e a dimensão What para representar a interacção entre actores e entidades

informacionais, e portanto visualizar que pessoas que lidam com que objectos da organização. Pode-se

restringir ainda mais a representação de forma a ver as interacções existentes para um determinado

elemento. Se imaginarmos que a função de uma pessoa específica é alterada (dimensão Who) podemos

representar a arquitectura empresarial na vista dessa pessoa e observar quais os outros elementos da

arquitectura que irão ser afectados (processos de negócio, entidades informacionais, localizações,

objectivos e tempos).

3.2.1.Representação dos Processos

3.2.1.1.Representação hierárquica dos processos de negócio

Pode-se visualizar os processos existentes na arquitectura empresarial pela dimensão “How”, ou

seja, pelos seus próprios sub-processos. Esta representação revela as várias camadas hierárquicas dos

processos de negócio. Esta representação indica o “como” se realiza um processo de negócio (através

dos seus sub-processos).

26

Processo 1

Processo 1-1

Processo 1-2

Processo 1-3 Processo 1-3-1

Processo 1-3-2

Imagem 3 – Representação dos processos

3.2.1.2.Representação dos processos com outras dimensões

Uma vez que aos processos estão associadas todas as outras dimensões, os processos podem

ser visualizados não só pelos seus sub-processos, mas também pelos seus inputs, outputs, actores,

localizações e objectivos e tempos associados. Esta representação devolve o máximo de informação

sobre um processo específico.

Processo 1-1

Actor 1 Unidade Organizacional X Entidade

Informacional 1

Processo 1-2

Processo 1

Actor 2 Unidade Organizacional Y Entidade

Informacional 2

Imagem 4 – Representação de um processo com dimensões

27

3.2.2.Representação dos Actores, Entidades Informacionais, Objectivos, Tempos e Localizações

3.2.2.1.Representação hierárquica das dimensõesO meta-modelo permite a representação de qualquer dimensão através da sua estrutura

hierárquica conforme realizado para nos processos de negócio.

3.2.2.2.Representação das dimensõesAs dimensões Who, Where, When, Why e What podem ser visualizadas através dos processos

de negócio que suportam ou através das suas relações com as outras dimensões. Por exemplo, os

processos de negócio que uma primitiva actor executa, as entidades informacionais que manipula, os

objectivos de que é responsável ou as localizações onde trabalha.

Através dos processos de negócio podemos relacionar uma dimensão com qualquer outra

dimensão. Tomemos o seguinte exemplo: um actor que é responsável por vários processos. Podemos

visualizar quais as entidades informacionais que ele manipula, ver os tempos que o actor dispende, as

localizações onde ele trabalha, quais os actores com quem interage ou os objectivos que estão

indirectamente dependentes dele.

Processo 1-1

Actor 1

Unidade Organizacional X Entidade

Informacional 1

Processo 2Entidade Informacional 3

Imagem 5 – Representação de um actor

3.2.3.Tipos de representações

De forma resumida, a aplicação das dimensões aos processos permite as seguintes

visualizações dos conceitos empresariais.

• Actores de um processo. Os responsáveis pela execução do processo.

• Entidades informacionais de um processo. Os dados necessários para a

execução do processo ou resultantes da execução do processo.

• Tempos de um processo. A frequência com que o processo é executado.

• Objectivos de um processo. Os objectivos que o processo de negócio deve

satisfazer.

28

• Localizações de um processo. As localizações físicas onde ocorre o processo.

• Sub-Processos de um processo. Os sub-processos necessários para a

realização do processo.

• Processos de um actor. Os processos de que um actor é responsável pela sua

execução.

• Processos de uma entidade informacional. Os processos onde a informação é

utilizada.

• Processos de um tempo. Os processos que ocorrem com um determinada

frequência temporal.

• Processos de um Objectivo. Os processos que contribuem para atingir um

determinado objectivo.

• Processos de uma localização. Os processos que ocorrem num local

específico.

• Dimensão versus dimensão. Quais são os objectos de qualquer dimensão que

se relacionam com um determinado objecto de qualquer dimensão,

• Processos com um conjunto de actores, entidades informacionais, tempos, objectivos e / ou localizações. Os processos que utilizam um conjunto

específico de dimensões.

• Processos com um ou mais tipos de dimensões. Os processos que estão

relacionados com uma ou mais dimensões.

• Processos sem um ou mais tipos de dimensões. Os processos que não estão

relacionados com uma ou mais dimensões.

• Processos sem inputs. Os processos que não recebem inputs na sua

execução.

• Processos sem outputs. Os processos que não produzem outputs resultantes

da sua execução.

29

3.3.Regras

A integração das várias dimensões com os processos permite aplicar regras para a detecção

automática de algumas inconsistências na arquitectura.

As regras descritas neste capítulo podem ser classificadas em dois tipos:

• Tipo 1: Regras baseadas num conjunto de restrições na interligação entre os processos

de negócio e as primitivas de cada dimensão.

• Tipo 2: Regras baseadas nas interligações entre processos e primitivas, e nos níveis de

granularidade de cada dimensão.

Estas regras procuram auxiliar a construção da arquitectura empresarial em tempo real, ao

fornecer um conjunto de avisos relacionados com os modelos.

Não faz parte deste trabalho a elaboração de regras com base no significado da própria primitiva.

Isto significa, por exemplo, que não detecta a utilização de uma entidade informacional num processo de

negócio que nada está relacionado na realizada. Como tal, as regras resultantes deste trabalho não

utilizam a semântica/significado dos objectos empresariais.

As regras criadas estão fortemente baseadas na definição de processo de negócio (Processo de

Negócio, página 17).

Nota: Imagens com linhas contínuas indicam interligações realizadas

Imagens com linhas tracejadas indicam avisos / sugestões de interligações.

3.3.1.Regras Tipo 1

São emitidos avisos para os seguintes casos:

3.3.1.1.Dimensão não associada aos processos• Uma dimensão (actor, localização, objectivo, ocorrência, entidade informacional ou

tempo) não está associada a qualquer processo (Sousa, 2003). Isto pode por um de dois

motivos:

1. Um erro na modelação organizacional, na qual a arquitectura não representa

fielmente a realidade organizacional e onde a dimensão em causa é na realidade

utilizada.

2. O modelo organizacional está correctamente modelado e a organização não

utiliza ou não possui processos de negócio definidos para a dimensão em causa.

Neste caso a dimensão não possui qualquer finalidade na organização e pode

ser considerada a hipótese da sua eliminação.

30

3.3.1.2.Actor não associado a localizações• Um actor ao qual não está nenhuma localização associada não está correctamente

modelado ou a posição do actor na organização não está definida. É gerado um aviso

para alertar o modelador desta situação.

3.3.1.3.Localização folha sem actores associados• Uma localização folha sem nenhum actor associado não está correctamente modelada

ou é uma localização cuja existência e função na organização é uma incógnita. Por este

motivo é gerado um aviso a alertar o modelador da situação.

3.3.1.4.Inconsistência entre actores e localizações de um processo

• Quando a associação entre os actores de uma localização não coincide com os actores

desse processo existe uma inconsistência na modelação ou na própria execução do

processo de negócio. Ou o processo em causa é executado também nas localizações

associadas ao actor, ou as localizações associadas ao actor devem incluir pelo menos

um das localizações do processo.

Imagem 6 – Inconsistência entre processos, actores e localizações

3.3.1.5.Processos sem outputsPor definição, processos produzem outputs, isto significa que quando um processo não possui

qualquer tipo de output associado, ou levantamento desse processo está incompleto ou o processo não

possui utilidade para a organização. Esta regra encontra-se implementada na zona de pesquisa da

ferramenta desenvolvida.

31

3.3.1.6.Processos sem inputsNa definição de processo de negócio utilizada neste trabalho um processo de negócio necessita

de inputs para a sua execução. Como tal, para a correcta modelação de processos é necessário pelo

menos um input no processo de negócio para este ser correctamente representado e executado, caso

contrário é gerado um aviso. Esta regra encontra-se implementada na zona de pesquisa da ferramenta

desenvolvida.

3.3.1.7.Processos sem objectivosProcessos sem objectivos associados não possuem uma clara indicação da sua funcionalidade e

do seu contributo para a organização. É gerado um aviso para os processos de negócio que não

possuem objectivos atribuídos. Esta regra encontra-se implementada na zona de pesquisa da ferramenta

desenvolvida.

3.3.1.8.Processos sem temposProcessos sem tempos associados não fornecem informação sobre a sua frequência de

execução. Processos de negócio são caracterizados por ocorrerem num período de tempo. Esta regra

encontra-se implementada na zona de pesquisa da ferramenta desenvolvida.

3.3.1.9.Processos sem actoresO actor é um conceito necessário para uma correcta definição de um processo de negócio.

Actores associados a processos de negócio definem “quem” executa os processos. Mesmo em

processos automáticos / mecanizados é necessário definir actores de forma a atribuir responsabilidades.

Esta regra encontra-se implementada na zona de pesquisa da ferramenta desenvolvida.

3.3.1.10.Processos sem localizaçõesUm processo de negócio é necessariamente realizado num determinado local da organização.

Quando tal informação não existe nos modelos, está-se numa situação em o processo descrito está

incompleto. Esta regra encontra-se implementada na zona de pesquisa da ferramenta desenvolvida.

3.3.1.11.Processos de negócio equivalentesProcessos de negócio com as mesmas dimensões associadas podem ser considerados

processos equivalentes. Esta situação pode ocorrer por dois motivos: uma incorrecta modelação da

organização; ou a organização executar vários processos com o mesmo fim. Compete ao modelador

verificar em que situação se encontra estes processos e agir de forma apropriada.

Pode-se visualizar os processos equivalentes através de todas as dimensões, ou através de um

conjunto restrito de dimensões. Por exemplo, se não se considerar a dimensão Where na identificação

32

dos processos equivalentes, visualizamos os processos idênticos que ocorrem em locais distintos.

Quando se realiza uma procura de processos de negócio equivalentes e os processos não possuem

dimensões pelas quais a procura está a ser realizada, então não é possível concluir a sua equivalência.

Esta regra não só detecta possíveis problemas na modelação da organização, mas fornece

também um método pelo qual se pode extrair informação da organização que pode ser utilizada na

identificação de pontos críticos e de optimização na empresa.

3.3.2.Regras Tipo 2

São considerados erros os seguintes casos:

3.3.2.1.Dimensões dos processos filhos mais genéricas

• Os casos de sub-processos com dimensões mais genéricas que o processo pai são

considerados erros (ver Imagem 7). Um sub-processo não pode estar associado a uma

dimensão mais genérica que a do seu processo pai, o que significa que a modelação da

dimensão ou do processo está incorrecta.

Entidade 1

Entidade 1-1

Entidade 1-2

Processo1

Processo1-1 Processo1-2

Imagem 7 – Processo pai com dimensão menos genérica.

3.3.2.2.Processo com todas sub-dimensões• Um processo que possua todas as sub-dimensões de um tipo de dimensão pode

substituir estas pela dimensão pai (ver Imagem 8). Isto é realizado para manter um

balanceamento no nível entre processos e as dimensões. Caso o processo necessite de

especificar concretamente as sub-dimensões deve-se considerar a hipótese em

decompor o processo em sub-processos que utilizem essas sub-dimensões.

33

Entidade 1

Entidade 1-1

Entidade 1-2

Processo1

Imagem 8 – Balanceamento das dimensões usadas.

3.3.2.3.Balanceamento das dimensões entre níveis• Um processo cujos sub-processos utilizam todas as sub-dimensões de uma dimensão

(ver Imagem 9). Neste processo pai pode estar associado essa dimensão pai.

Entidade 1

Entidade 1-1

Entidade 1-2

Processo1


Imagem 9 – Balanceamento nos níveis hierárquicos.

3.3.2.4.Processo folha com dimensão genérica• Um processo folha (isto é, um processo sem sub-processos), utiliza dimensões que não

são folha (dimensões possuem sub-dimensões) (ver Imagem 10). Se um processo folha

possui dimensões não folha, então é possível uma melhor decomposição do processo de

forma a usar dimensões folha e melhorar a compreensão e representação do processo.

34

Entidade 1

Entidade 1-1

Entidade 1-2

Processo1


Imagem 10 – Decomposição de um processo.

3.3.2.5.Processo folha com múltiplas dimensões do mesmo tipo

Quando um processo folha possui n dimensões do mesmo tipo (actores, objectivos, localizações

ou tempos), em que n é igual ou superior a 2, esse processo poderia ser decomposto em n sub-

processos, cada um associado com uma dessas dimensões (Sousa, 2006). Um processo que usa várias

dimensões do mesmo tipo é um processo cuja informação representada é inferior nas representações

com vários processos de negócios com essas mesmas dimensões.

Se considerarmos o processo “Arranjar Porta” que utiliza dois actores (“Pintor” e “Serralheiro”).

Neste processo de negócio não é possível obter informação sobre o tempo que demora o “Pintor” e o

tempo que demora o “Serralheiro”. Porém se decompormos o processo “Arranjar Porta” em “Pintar Porta”,

atribuído ao actor “Pintor”, e em “Montar Porta”, atribuído ao actor “Serralheiro”, podemos então obter os

tempos que cada um utiliza no processo pai “Arranjar Porta”.

Processo1


Actor X Actor Y

35

4.Validação do trabalhoA ferramenta escolhida para realizar a validação deste trabalho foi o “System Architect” da

Telelogic.

O “System Architect” é uma ferramenta utilizada para a modelação e construção de arquitecturas

empresariais. Possui um vasto conjunto de diagramas que permitem a modelação dos vários domínios

arquitecturais: negócio; informação; sistemas; tecnológico.

Um dos aspectos importantes da ferramenta é esta possuir poderosos mecanismos de extensão.

Permite a extensão do seu meta-modelo onde se pode adicionar e alterar diagramas, símbolos e

definições, bem como as suas propriedades. A ferramenta também possui suporte para Visual Basic for

Applications que permite a construção de macros para a ferramenta.

A validação do trabalho passou pelas seguintes etapas:

• Análise dos diagramas do “System Architect”.

• Adaptação dos diagramas, símbolos e definições do “System Architect”.

• Desenvolvimento de uma macro que implementa as regras definidas no trabalho.

• Validação das regras definidas com dados de um caso de estudo real.

37

4.1.Análise dos diagramas existentes no “System Architect”

Antes de se iniciar a implementação da macro para validar o trabalho realizado, efectuou-se um

estudo aos diagramas fornecidos pela ferramenta “System Architect” para se determinar como estes

poderiam ser utilizados e relacionados com as dimensões.

O “System Architect” classifica os seguintes diagramas como pertencendo à perspectiva

conceptual da framework de Zachman (Tabela 3).

What How Where Who When WhyEnterprise ModelConceptualRole: Owner

-Conceptual Data Model-Process Hierarchy

-Functional Hierarchy or-IDEF0 Diagrams-BPMN Diagram or-Process Chart or-IEDF3 Process Flow or-UML Activity Diagram-Process Decomposition-Relationship Map

-Business Concept Diagram-Organization Chart and

-Decision Chart and-BPMN Diagram (swinlanes) or-Process Chart (swinlanes) or-IDEF3 Process Flow (swinlanes) or-UML Activity Diagram (swinlanes)

-Process Events (Definition)-Process Results (Definition)-IDEF3 Object State Transition

-Requirements (Enterprise) (Definition)

Tabela 3 Mapeamento dos diagramas e definições do “System Architect” às células da framework de Zachman (perspectiva Conceptual)

A Tabela 4, apresentada em baixo, mostra uma análise dos diagramas que existem na

ferramenta “System Architect” e como os elementos que os constituem podem ser relacionados com as

dimensões da framework de Zachman. Os diagramas marcados a azul claro são diagramas que estão

directamente relacionados com o segundo nível da framework de Zachman (nível conceptual) no qual

este trabalho está a ser realizado. Diagramas marcados a cinzento são diagramas utilizados na

modelação de outros níveis (por exemplo, nível tecnológico) e como consequência não são relevantes no

contexto deste trabalho. Os restantes diagramas, apesar de não serem directamente relacionados com o

nível conceptual, podem ser úteis na modelação e representação das várias dimensões.

Diagramas \ Dimensões What How Where Who When WhyActivity Action State Org Unit Auto-Decomposition Functions Org UnitAV-01 High Level Operational Concept Org. Unit GoalsAV-02 Integraded DictionaryBusiness Architecture

Business Concept Locations

38

Business Process (BPMN)

Data Object / Message flow Process

Pool Lane

Pool Lane Event

Business Process Hierarchy ProcessCollaboration X ObjectsConceptual Data Model X

Data Flow Gane & SarsonData Store Process External

Data Flow Ward & Mellor

Data StoreData transform

Decision Chart Unit

Decomposition Entity

Function Org. Function Org Unit

Enterprise Direction(Relacionado com a perspectiva planner) Org. Unit

Objective

Functional Hierarchy

EBPOrg. Function

IDEF0 InputsFunctionActivity

IDEF3 Object State transition Estados

EstadosTransições

IDEF3 Process Flow UOB Lane Organization Chart Org Unit

OV-01 Highlevel Op. Concept AssetsLocations

Organization

OV-02 Op. Node Connectivity Activities Op. Node

OV-03 Information exchange MatrixInformation Flow Activities

Op. Elements

OV-04 Org. Chart Org UnitOV-05 Activity Model Activities

OV-06a Op Rules ModelUnit of Behaviour

OV-06b Op State Transition State Event

OV-06c Operation Event/Trace(Interacções / mensagens entre operational nodes) Op NodeOV-07 Logical Data Model (IDEF1x) Entities

Process Chart Process Org Unit / Lane

Event Result

Process Decomposition Process EBP Process Hierarchy Object DLP

Process Map Process Org UnitEventResult

Relationship Map

Function Process Thread

Stakeholder RelationshipsOrg. Unit

Stakeholder

State StateState Transition StateState Transition Ward & Mellor State

Strategy Map (For organization Unit)Org Unit

BSC Objective

UML Activity Diagram Activity Lane

39

Use Case Use Case ActorSequence X XService Reference Model

SV-05 System Function to Op. Activities (Relevante?)Materials

Automatic Activities

Business Process Reference Model Character Screen Component Deployment Entity Relation Flow Flow Chart Graphic Screen Menu Meta model Network Concept Performance Reference Model Physical Data Model PRM Line of Sight Structure Chart SV-01 Systems Interface SV-02 Systems Communication SV-04 Data Flow SV-04 Functional Decomposition SV-10B State Transition SV-10C System Event/Trace SV-11 Physical Data Model System Architecture System Area Map System Context System/Subsystem Structure Technical Architecture Technical Reference model Legenda:Diagramas pertencentes ao nível 2 da framework de ZachmanEnterprise Model/Conceptual/Role:Owner.

Diagramas não relevantes para a modelação empresarial no contexto deste trabalho.

Tabela 4 – Análise dos diagramas em relação às dimensões

Desta tabela pode-se verificar que existem poucos diagramas para apresentar a dimensão “Why”.

Dos diagramas existentes, optou-se por utilizar o diagrama “Enterprise Direction” para realizar a

hierarquia dos objectivos.

Em relação à dimensão What, verifica-se que alguns destes diagramas permitem a

representação desta dimensão com os processos, estes são:

• BPMN Diagram, na qual permite associar “Data Objects” aos processos.

• Decomposition, na qual objectos do tipo “Entitiy” podem representar recursos.

• IDEF0, através dos inputs.

40

• O V-03 Information exchange Matrix, com “information flows”.

• Process Hierarchy, na qual os recursos podem ser representados por “Objects”.

Porém destes diagramas, nenhum permite a decomposição hierárquica desejada para as

entidades informacionais. Como consequência decidiu-se criar um diagrama novo na

ferramenta para este fim, designado “Diag. Informacao”.

O conceito de Unidade Organizacional é definido neste trabalho como pertencente à dimensão

Where e o conceito Actor será utilizado na representação da dimensão Who nos processos. Actor é

definido como o papel da pessoa que desempenha a actividade em causa. Para cada o objecto Actor,

criou-se um novo diagrama hierárquico para a definição hierárquica deste. O objecto Unidade

Organizacional e o diagrama “Organization Chart” permitem modelar a dimensão localização da forma

pretendida visto o diagrama ser do tipo hierárquico.

Em relação à dimensão tempo, decidiu-se criar um novo objecto chamado Tempo, e um novo

diagrama hierárquico designado “Diag. Tempo”, pois a ferramenta não possui as definições, símbolos e

diagramas necessários a esta dimensão.

Para representar o processo utilizou-se os diagramas BPMN da ferramenta e os objectos

“Process” a eles associados.

41

4.2.Diagramas Utilizados

Os diagramas utilizados neste trabalho não possuem qualquer influência na componente téorica

do trabalho. Isto significa que poderiam ser utilizados outros diagramas sem que fosse necessário realizar

alterações profundas à implementação deste trabalho.

4.2.1.Diagrama de processo de negócio (Diagrama BPMN)

O diagrama de processo de negócio é um tipo de diagrama específico para a modelação de

processos. Possui o elemento “Process” (dimensão “How”), o elemento “ Event” (dimensão tempo),

“swinlanes” representam “Participant”. Utiliza vários tipos de conectores para modelar o fluxo entre

processos (messagem, associação, sequencia). Informação (dimensão What) pode ser representada por

“Data Objects”.

Decidiu-se utilizar este tipo de diagrama para modelar os processos. Utilizou-se também o

diagrama BPMN hierárquico para definir a hierarquia dos processos, bem como a criação de “filhos” nos

processos dos diagramas BPMN.

Definiu-se uma notação para a representação das entidades informacionais nestes diagramas

(Imagem 11).

• Entidades informacionais do tipo input são representadas no topo respectivo símbolo tipo

processo de negócio, com uma ligação do tipo associação no sentido da entidade

informacional para o processo de negócio.

• Entidades informacionais do tipo output são representadas na zona inferior do respectivo

símbolo tipo processo de negócio, com uma ligação do tipo associação no sentido do

processo para a entidade informacional.

Imagem 11 – Diagrama BPMN com a notação de inputs e outputs

42

4.2.2.Diagrama Business Process Hierarchy

O diagrama Business Process Hierarchy é um diagrama hierárquico. É utilizado para representar

os vários níveis da dimensão How, e regra geral é utilizado para os macro-processos. A transição entre

estes diagramas para os diagramas BPMN é feita pela criação de um filho no respectivo processo para

um diagrama BPMN.

Imagem 12 – Business Process Hierarchy

4.2.3.Diagrama Organization Chart

Este diagrama é utilizado para modelar as localizações (dimensão Where) da organização. É

estruturalmente idêntico ao diagrama Business Process Hierarchy. Com estes diagramas são construídos

os organogramas das organizações.

43

Imagem 13 – Organization Chart

4.2.4.Diagrama Enterprise Direction

Este diagrama é utilizado para modelar os objectivos (dimensão Why) da organização. É um

diagrama que permite a associação da visão de negócio, os “business Goals” e os objectivos de negócio

de forma hierárquica.

44

Imagem 14 – Enterprise Direction

4.3.Diagramas criados

Após a análise dos diagramas existentes na ferramenta System Architect, decidiu-se utilizar o

mecanismo de extensão da ferramenta para criar novos diagramas quando as soluções fornecidas pela

ferramenta não iam ao encontro do que era pretendido. Desta forma foram criados três novos tipos de

diagramas: o diagrama de informação; o diagrama de actores; e o diagrama de tempo.

4.3.1.Diagrama Informação

Este diagrama foi criado para modelar as entidades informacionais (dimensão What) utilizadas na

organização. É um diagrama hierárquico no qual é criada uma estrutura com níveis entre as várias

entidades informacionais utilizadas na organização.

45

Imagem 15 – Diagrama de Informação

4.3.2.Diagrama Actores

O diagrama actores foi criado para modelar os actores (dimensão Who) existentes na

organização. Também este diagrama é hierárquico e utilizado para definir uma estrutura com níveis entre

os actores da organização. A estrutura do diagrama de actores é conceptualmente idêntica ao diagrama

de informação (Imagem 15).

4.3.3.Diagrama Tempo

O diagrama tempo foi criado para modelar a componente temporal (dimensão When) dos

processos da organização. É um diagrama hierárquico que permite a definição de níveis entre as

frequências da organização. A estrutura do diagrama tempo é conceptualmente idêntica ao diagrama de

informação (Imagem 15).

46

4.4.Definições utilizadas no System Architect

O System Architect utiliza “definições” para definir os símbolos utilizados como blocos de

construção dos diagramas. Para utilizar a multi-dimensionalidade foi necessário seleccionar os blocos de

construção a utilizar nos modelos. Isto para, posteriormente, possibilitar a definição das relações entre si.

Na implementação deste trabalho as definições utilizadas correspondem às primitivas definidas

na página 23.

Das definições já existentes no System Architect foram utilizadas as definições:

• BPMN Process. Representa a primitiva “Processo de Negócio”. Esta definição é utilizada

nos diagramas Business Process Hierarchy e nos diagramas de processos de negócio

(Diagrama BPMN)

• Data Object. Representa a primitiva “Entidade Informacional”. Esta definição é utilizada

nos diagramas de Informação. Também é utilizada nos diagramas BPMN para

representar a forma de utilização das entidades informacionais pelos processos de

negócio.

• Organizational Unit. Representa a primitiva “Localização”. Esta definição é utilizada nos

diagramas Organization Chart.

• Role. Representa a primitiva “Actor”. Esta definição é utilizada nos diagramas de Actores.

• Business Objective. Representa a primitiva “Objectivo”. Esta definição é utilizada nos

diagramas Enterprise Direction.

Verificou-se a necessidade de criar uma definição com correspondência à primitiva Tempo. O

meta-modelo do programa System Architect foi portanto estendido com uma nova definição “frequência”.

Esta nova definição é utilizada nos diagramas de Tempo.

47

4.5.Implementação

4.5.1.Meta-modelo do System Architect

Conforme já referido, a ferramenta System Architect possui poderosos mecanismos de extensão.

Para adicionar os diagramas, símbolos e definições inexistentes na ferramenta foi utilizado o

ficheiro USRPROPS.TXT, encontrado no anexo C. Este mecanismo de adaptação do meta-modelo do

System Architect permite também definir as “propriedades” das definições. Através destas propriedades é

possível especificar relações entre objectos do System Architect. Este mecanismo permitiu implementar o

meta-modelo definido na página 22.

Desta forma foram adicionadas propriedades à definição “BPMN process” que permitem a ligação

dos processos a outras definições. Estas propriedades foram:

Actores, nos quais permite a associação dos actores do processo de negócio;

Objectivos, nos quais se encontram os objectivos que o processo de negócio deve atingirem;

Localizações, indicando os sítios onde o processo de negócio ocorre;

Input Entidade Informacional, com as entidades informacionais necessárias à execução do

processo de negócio;

Output Entidade Informacional, com as entidades informacionais resultantes da execução do

processo de negócio;

Tempo, o que indica com que frequência é realizado o processo de negócio.

O processo de negócio é o elemento unificador entre os objectos com correspondência às

dimensões. As relações existentes entre os objectos das várias dimensões são sempre derivadas a partir

das relações definidas nos processos de negócio.

Também foram adicionados duas outras propriedades. À definição “Role” foi adicionada a

propriedade “Related Locations”, e à definição “Organizational Unit” foi adicionada a propriedade “Related

Actor”. Estas propriedades permitem a associação directa entre actores e localizações.

4.5.2.Construção dos modelos

A construção dos modelos arquitecturais é realizada através dos diagramas definidos na página

42. Cada diagrama permite modelar uma das dimensões e definir a estrutura dos elementos que os

constituem.

No momento do levantamento dos processos de negócio é necessário recolher os actores que

realizam os processos, as localizações onde os processos são executados, os objectivos que os

processos de negócio devem atingir, os tempos de execução dos processos, os inputs que os processos

48

de negócio necessitam para a sua execução, e os outputs resultantes da execução dos processos de

negócio. É necessário também recolher informação acerca das estruturas hierárquicas de cada elemento.

A definição hierárquica dos actores, localizações, objectivos, tempo, e informação é realizada em

diagramas hierárquicos. No caso dos processos de negócio, estes podem ser definidos num diagrama

hieráquico do tipo Business Process Hierarchy. Em alternativa pode-se definir a hierarquia através de

diagramas BPMN, com o uso da funcionalidade do System Architect “add children”. Os elementos são

modelados da seguinte forma:

Os actores são modelados nos diagramas de Actores.

Os objectivos são modelados nos diagramas Enterprise Direction.

Os tempos são modelados nos diagramas de Tempo.

As entidades informacionais são modeladas nos diagramas de Informação.

As localizações são modeladas nos diagramas Organization Chart.

Os processos de negócio são modelados nos diagramas BPMN e nos diagramas Business

Process Hierarchy.

Com esta informação, é possível construir os modelos com correspondência às dimensões. Uma

vez que o processo de negócio é o elemento agregador entre elementos, é este que irá permitir realizar

as interligações entre as dimensões. A interligação das dimensões é realizada através do processo de

negócio. Para tal é necessário adicionar às propriedades de cada definição de processo de negócio, a

respectiva dimensão.

Nos diagramas BPMN, utilizou-se a seguinte convenção para representar a ligação entre

entidades informacionais e processos de negócio:

• Os inputs são associados aos processos de negócio através de uma ligação de

associação no sentido input – processos de negócio.

• Os ouputs são associados aos processos de negócio através de uma ligação de

associação no sentido processo de negócio – output.

Durante a modelação e construção dos modelos deve-se também obter a forma as localizações

dos actores na empresa. Esta informação deve ser adicionada através de uma matriz que interligue as

propriedades “Related Actors” e “Related Locations” das localizações e actores respectivamente. Isto

permite posteriormente cruzar esta informação com as relações entre actores e localizações existentes

através do processo de negócio.

4.5.3.Implementação da macro

Para realizar a representação multi-dimensional da arquitectura na ferramenta, foi utilizado outro

mecanismo de extensão do System Architect. Este mecanismo foi o de macros, o qual permite utilizar e

49

adicionar novas funcionalidades ao System Architect. A macro foi escrita em Visual Basic For

Applications.

A macro realizada permite o acesso à base de dados dos elementos que constituem a

arquitectura empresarial. Esta funcionalidade permite implementar os objectivos principais deste trabalho,

a representação da arquitectura através de dimensões, e introduzir regras na associação entre elementos

de diferentes dimensões.

4.5.3.1.Representação da arquitectura através da macro

Foi decidido implementar a visualização dos elementos que constituem a arquitectura num

esquema em árvore. O motivo desta escolha está baseado no facto de que os modelos utilizados são

modelos hierárquicos, e portanto, com múltiplas camadas de granularidade. O esquema em árvore

permite representar de forma simples esses vários níveis de abstracção.

Imagem 16 – Visualização dos processos e subprocessos de negócio através da macro

Através da macro pode-se visualizar a arquitectura por qualquer das dimensões definidas neste

relatório. As dimensões são How (Processos), What (Entidades Informacionais), Who (Actores), When

(Tempo), Why (Objectivos) e Where (Localizações). Na Imagem 16 está apresentada a representação

somente na dimensão relacionada com os processos de negócio. Conforme se pode observar, o

50

esquema em árvore mostra os processos de maior nível e os seus sub-processos até às actividades.

Pode-se especificar o processo de negócio para ser visualizado com maior detalhe. Para tal utiliza-se a

lista, observável no canto superior direito na imagem, ou selecciona-se o processo desejado na

representação em árvore em clica-se em “Ver Dimensão Seleccionada”.

Imagem 17 – Visualização dos processos de negócios tendo em conta todas as dimensões

No canto inferior direito da interface, encontra-se a área na qual se pode seleccionar as

dimensões pelas quais se deseja visualizar a arquitectura. No caso da Imagem 17, todas as dimensões

estão seleccionadas. Conforme se pode observar, são devolvidos os sub-processos e os actores,

objectivos, localizações, tempos, entidades informacionais que o processo utiliza.

51

Imagem 18 – Visualização de um actor através da dimensão When, What, Where, e Who.

Na Imagem 18 a actora “Albertina Martins” (dimensão Who) está representada com as relações

que possui com os restantes actores (com quem interage), com as localizações (onde realiza as suas

tarefas), com os tempos (quando realizada as tarefas) e entidades informacionais (a informação com que

lida).

4.5.3.2.RegrasEsta funcionalidade da macro procura implementar a maioria das regras pormenorizadas na

página 30.

Conforme se pode observar na Imagem 19, as regras encontram-se divididas em três categorias.

Regras nos níveis de granularidade. Nas quais as se encontram regras que se aplicam aos

objectos com vários níveis de granularidade, de forma a verificar se a modelação destes se encontra

normalizada e consistente.

Regras nas interligações. Nesta categoria estão regras que verificam somente as associações

existentes entre objectos de dimensões distintas.

Processos equivalentes. Nesta categoria encontra-se a funcionalidade que devolve os

processos equivalentes, isto é, com as mesmas dimensões.

52

Imagem 19 – Processos folha com 2 ou mais dimensões do mesmo tipo

4.5.3.2.1.Regras nos níveis de granularidade

Na categoria “regras nos níveis de granularidade” encontram-se quatro regras. Estas são:

Dimensões dos processos balanceados? Esta funcionalidade implementa a regra “Processo

com todas as sub-dimensões”.

As funcionalidades “Processos Balanceados?” e “Verificar subida das dimensões nos processos pai” implementam a regra “Balanceamento das dimensões entre níveis”. O que distingue a

funcionalidade “Verificar subida das dimensões nos processos pai” é esta verificar as dimensões dos sub-

processos e caso todos os sub-processos estejam associados à mesma dimensão, sugere passar essa

associação para o processo pai.

Verificar dimensões nos processos folha. Esta funcionalidade implementa a regras “Processo

folha com dimensão genérica”.

Processos folha com duas ou mais dimensões do mesmo tipo. Esta funcionalidade

implementa a regras “Processo folha com múltiplas dimensões do mesmo tipo”.

53

Imagem 20 – Localizações folha sem actores.

4.5.3.2.2.Regras nas Interligações

Na categoria “Regras nas interligações” existem quatro funcionalidades. Estas são:

Ver actores não associados a localizações. Implementa a regra “Actor não associado a

localizações”.

Ver localizações folha sem actores. Implementa a regra “Localização folha sem actores

associados”.

Verificar localizações dos actores com localizações dos processos. Implementa a regra

“Inconsistência entre actores e localizações de um processo”.

Colocar Analytics nas dimensões não utilizadas. Esta funcionalidade abre os diagramas que

possuem dimensões não associadas a processos. Aos símbolos que correspondem a dimensões não

utilizadas nos processos de negócio são então colocadas representações gráficas a indicar esta situação.

Identifica as dimensões que se encontram nas situações detectada pela regra “Dimensão não associada

aos processos”.

4.5.3.2.3.Processos equivalentes

A categoria “Processos equivalentes” implementa a regra “Processo de negócio equivalentes”.

54

Imagem 21 – Processos Equivalentes

A Imagem 21 ilustra a interface utilizada para implementar esta regra. A secção “Filtro

Dimensões” é utilizada para obter os processos equivalentes na óptica dessas dimensões. No exemplo

na imagem, os processos são equivalentes somente quando possuem actores e tempos iguais.

Quando um processo possui todas as dimensões iguais mas que não possui elementos

associados numa das dimensões em pesquisa, então não é possível concluir se é equivalente. Um

exemplo de processos cuja equivalência não pode ser concluída pode ser encontrada na Imagem 21.

Os processos de negócio: BP-Process02-01, BP-Process02-02 e BP-Process02-03 poderão ser

equivalentes pois todos partilham o actor “Pessoa_1_1” através da dimensão “Who”. Porém a procura de

processos equivalentes está também a ser realizada pela dimensão “When” e dado que nenhum destes

processos possui elementos nessa dimensão, não é possível concluir se de facto são equivalentes. Os

processos nesta situação são devolvidos numa outra lista.

4.5.3.2.4.Regras executadas automaticamente

A regra “Dimensões dos processos filhos mais genéricas” é executada automaticamente no

arranque da macro. Caso seja detectada alguma destas situações, a execução da macro é interrompida e

é devolvido um erro que identifica o problema de forma ser corrigido pelo utilizador.

É gerado um aviso quando a representação dos processos de negócio com os inputs e outputs

não coincidem com a associação definida nas propriedades do processo de negócio. Compete ao

utilizador corrigir a situação pois não é possível determinar automaticamente a correcta associação.

55

4.5.3.3.PesquisaFoi criada na macro uma funcionalidade com o intuito de facilitar a procura de processos de

negócio que se encontram em determinadas situações. As situações podem ser:

• Associados a um conjunto de dimensões (por exemplo, com actores, inputs, e

localizações).

• Não associados a um conjunto de dimensões (por exemplo, sem objectivos e sem

localizações).

Imagem 22 – Pesquisa de processos sem dimensões tipo

A Imagem 22 demostra uma pesquisa de processos de negócio sem objectivos e sem actores.

Com esta funcionalidade obtém-se os processos que não se encontram com pelo menos uma

dimensão associada, e como tal, satisfaz as seguintes regras:

• Processos sem objectivos.

• Processos sem actores.

• Processos sem localizações.

• Processos sem tempos.

• Processos sem inputs.

• Processos sem outputs.

56

Outra funcionalidade fornecida pela pesquisa na macro, é a de devolver os processos que

utilizam elementos específicos.

Imagem 23 – Pesquisa de processos por elementos específicos

A Imagem 23 ilustra este tipo de pesquisa. Neste caso são procurados os processos que utilizam

como actores a “Albertina Martins” e as entidades informacionais “CVs”. Este tipo de pesquisa é útil

quando o modelador necessita de informação detalhada sobre como um conjunto de elementos estão

relacionados na organização. Alterações nas organizações implicam alterações nos diferentes tipos de

entidades da organização (Mendes, 2003).

4.5.3.4.Representação dos modelos As-Is e dos modelos To-Be

Verificou-se que o meta-modelo utilizado na representação multi-dimensional de arquitecturas

pode ser utilizado para um segundo propósito. Os elementos utilizados podem ser associados a um tipo

de modelo, As-Is ou To-Be. O modelo As-Is representa o estado actual da organização. O modelo To-Be

representa a organização que se deseja alcançar no futuro. Pretende-se com esta parte do trabalho,

representar a transição do modelo As-Is para o modelo To-Be.

Para realizar esta representação foi necessário:

• Associar os objectos da organização ao modelo As-Is, ou ao modelo To-Be.

57

• Obter a correspondência de um objecto de um modelo, com os objectos do mesmo tipo

do modelo oposto.

Para tal foi utilizado uma vez mais o mecanismo de extensão do System Architect. Foram

adicionadas as seguintes propriedades às definições:

• Propriedade “As Is or To Be”, que identifica a que modelo pertence um objecto da

arquitectura.

• Para a definição “Role” foi criada a propriedade “Actores Associados”, utilizada para

estabelecer as relações entre actores do modelo As-Is e do modelo To-Be.

• Para a definição “Organizational Unit” foi criada a propriedade “Localizações

Associadas”, utilizada para estabelecer as relações entre localizações do modelo As-Is e

do modelo To-Be.

• Para a definição “Frequência” foi adicionada a propriedade “Tempos Associados. Esta

propriedade é utilizada para estabelecer as relações entre tempos do modelo As-Is e do

modelo To-Be.

• Para a definição “Business Objective” foi adicionada a propriedade “Objectivos

Associados”. Esta propriedade é utilizada para estabelecer as relações entre objectivos

do modelo As-Is e do modelo To-Be.

• Na definição “BPMN Process” foi adicionada a propriedade “Processos Associados”. Esta

propriedade permite estabelecer as relações entre processos do modelo As-Is e do

Modelo To-Be.

Aos diagramas utilizados também foram adicionadas propriedades para a sua atribuição ao

modelo As-Is ou To-Be. Foi estabelecido que os objectos possuem o mesmo tipo de modelo que o

modelo dos seus diagramas.

Quando se deseja visualizar a transição de, por exemplo, um determinado actor do modelo As-Is,

a macro realiza a seguinte operação:

Obtém os processos de negócio que o actor do modelo As-Is é responsável.

Obtém os actores do modelo To-Be com correspondência ao actor do modelo As-Is.

Obtém os processos de negócio dos actores do modelo To-Be.

Compara as correspondências dos processos do actor do modelo As-Is com os processos dos

actores do modelo To-Be.

Os resultados podem ser os seguintes:

• Os processos de negócio do modelo As-Is que não possuem correspondência com os

processos de negócio do modelo To-Be são considerados processos de negócio

58

obsoletos. Isto significa que são processos que deixam de ser realizados por aquele

actor no futuro da organização.

• Os processos de negócio do modelo As-Is possuem correspondência com os processos

de negócio do modelo To-Be. É devolvida informação sobre como os processos de

negócio do modelo As-Is são realizados no futuro da organização.

• Os processos de negócio do modelo To-Be não possuem correspondência com os

processos de negócio do modelo As-Is. Quer isto dizer que os processos de negócio

nesta situação são processos completamente novos na organização.

Imagem 24 – Transição do modelo As-Is para o modelo To-Be de um actor.

A Imagem 24 ilustra o exemplo anterior. Neste caso o papel do actor Pessoa_1_As-Is passa a

ser desempenhado por dois actores (Pessoa_1-To-Be e Pessoa_2-To-Be). O processo de negócio

“Process_Novo-ToBe” é um processo novo. O processo de negócio “Process_2-AS-IS” deixa de ser

executado no modelo To-Be. A funcionalidade do processo de negócio “Process_1-AS-IS” é distribuída

pelo “Process_1_To-Be” e pelo “Process_3-To-Be”. A funcionalidade dos processos “Process1_AS-IS” e

“Process_3-AS-IS” passa a ser desempenhada pelo “Process_3-To-Be”.

59

Imagem 25 – Representação visual da transição do modelo As-Is para o modelo To-Be dos processos.

A Imagem 25 mostra a transição de um processo de negócio do modelo As-Is (processo azul)

para o modelo To-Be. Neste caso a funcionalidade do processo de negócio no modelo As-Is é repartida

em dois processos processo de negócio (os processos a verde). Esta funcionalidade pretende melhorar a

compreensão desta transição na vida da organização.

60

5.Caso de Estudo INATEL

5.1.Introdução

Fundado em 1935 como Fundação Nacional para Alegria no Trabalho (FNAT), o INATEL hoje

tutelado pelo Ministério do Trabalho e da Solidariedade Social, afirma-se como um grande prestador de

serviços sociais, nas áreas do turismo social e sénior, do termalismo social e sénior, da organização dos

tempos livres, da cultura e do desporto populares, com profundas preocupações de humanismo e de

qualidade, estando presente em todo o Continente e Regiões Autónomas com uma rede de 21

delegações e subdelegações.

É seu actual Presidente, José Alarcão Troni e Vices-Presidentes, Vitor Hugo da Rocha Ventura e

Luis Ressano Garcia Lamas.

A obra do INATEL abrange uma massa associativa que ronda os 250 mil associados individuais e

os 3 500 associados colectivos; uma rede de hotelaria social com 14 Centros de Férias, três Parques de

Campismo, três Casas de Turismo Rural e dois balneários termais - representando uma oferta global de 4

200 camas - e uma estrutura permanente de turismo social e sénior e de organização das férias dos

associados e suas famílias; um Teatro – o Teatro da Trindade; dois Parques desportivos - o Estádio 1º de

Maio, em Lisboa, e o Parque de Ramalde, no Porto, além de estruturas de apoio à cultura popular e ao

desporto amador que, designadamente, promovem a assistência técnica e financeira do movimento

associativo, cultural, desportivo, etnográfico, folclórico ou recreativo, de base empresarial ou local, no

Continente e nas Regiões Autónomas.

No âmbito da Cultura, através da rede de delegações e subdelegações por todo o país, o INATEL

oferece uma vasta actividade cultural aos seus associados como é exemplo a formação cultural dada a

dirigentes associativos, executantes artísticos e para todos através das Escolas do Lazer.

São levados a efeito diferentes concursos de criatividade artística; apoiados os CCD’s

dinamizando e divulgando as suas iniciativas culturais; organizados Planos de Apoio Nacionais para as

vertentes de Etnografia, Música e Teatro amadores e editada dramaturgia portuguesa contemporânea.

São ainda produzidos e apoiados espectáculos quer de raiz rural ou urbana, um pouco por todo o

país.

61

No âmbito do Desporto, apoiando-se numa ampla rede de instalações e em colaborações

estratégicas com diversas entidades, o INATEL oferece um leque variado de actividades de lazer,

integradas em quatro programas específicos, que abrangem diversas modalidades, a nível nacional:

actividades regulares, individuais e colectivas, com calendário competitivo (Provas Regulamentares);

actividades regulares, de manutenção física, orientadas por profissionais qualificados, em classes

semanais (Actividades Básicas); actividades pontuais, abertas à generalidade da população, organizadas

em estreita colaboração com as associações locais (Desporto para Todos); e actividades pontuais,

igualmente abertas a todos, organizadas em contextos naturais, associadas ao conceitos de Natureza e

Aventura. (Informação acerca do Inatel retirada de - http://www.inatel.pt/fazemos.htm)

5.2.Contexto

“Inatel DigitalNa sequência da audição de prestigiados consultores externos, com especial destaque para o

INA – Instituto Nacional de Administração, a Direcção, a quem tenho a honra de presidir, deliberou, na

sessão de 29 de Dezembro de 2005, o upgrading do software informático do INATEL, com a progressiva

substituição do actual sistema Bann pelo SAP, generalizadamente adoptado pelo sector público e

empresarial do Estado.

Sistema SAP. Espero que o novo sistema venha introduzir expressiva melhoria qualitativa nos

procedimentos administrativos e na capacidade de resposta do INATEL – independentemente do seu

figurino estatutário definitivo – melhorando o desempenho e competividade institucionais, com o objectivo

final da progressiva substituição da actual “paper admistration” – a gestão com base em suporte físico –

pela futura e desejável “no paper administration”, a gestão digital.

É óbvio que a introdução do sistema SAP será acompanhada pela generalizada formação dos

utilizadores.

A subsequente carteira de modernização administrativa, tecnológica e procedimental do INATEL

– em especial os projectos INATEL – Melhor Serviço e INATEL – Melhor Gestão – será preparada no ano

em curso, em ordem à sua candidatura aos fundos estruturais da União Europeia, através dos actual e

próximo Quadro Comunitários de Apoio.

Entretanto, o INATEL seleccionará uma Universidade ou Instituto de Investigação de referência

como seu consultor estratégico para a Inovação e Desenvolvimento, nas áreas da Modernização

Administrativa e dos Sistemas e Tecnologias de Informação.”

62

O Inatel encontra-se numa fase de mudanças profundas. Os processos e sistemas de informação

da organização vão ser alterados no âmbito do projecto “Inatel Digital”, o qual procura melhorar a

qualidade dos procedimentos organizacionais.

O actual sistema do Inatel, o Bann, irá ser substituído por sistemas SAP.

No contexto deste trabalho, os processos recolhidos e utilizados para a validação deste trabalho

pertencem na sua maioria ao departamento do Turismo Sénior. Esses dados são introduzidos no

repositório de processos “System Architect” e a ferramenta desenvolvida é executada sobre esses dados

de forma a efectuar-se uma validação do trabalho com base nos resultados obtidos. Dos resultados

obtidos com esses dados serão realizados os ajustes vistos necessários e a própria validação dos dados

levantados do Inatel.

O resultado do levantamento é obtido na forma de documentos Visio, de forma exemplificada na

Imagem 26 – Visio. Estes documentos Visio são construídos pelos funcionários do Inatel com base em

logs (registos) das suas actividades, também por eles elaborados.

Um aspecto fundamental deste levantamento de processos é o de extrair a informação

necessária para a interligação das várias células da framework de Zachman. Conforme se pode verificar

na Imagem 26, os processos trazem consigo informação associada às primitivas de cada célula (actores,

inputs, outputs, tempos e localizações). É esta informação que permitirá a interligação entre primitivas.

É necessário referir que a recolha de informação nesta organização não contemplou os

objectivos de negócio, e como tal as primitivas do tipo objectivo e as suas relações com os processos não

estão presentes nesta validação.

DTS

Mapa Detalhado de Viagens

Actualizar as Datas dos Grupos no Mapa Detalhado das Viagens

Equ

ipa

de P

RO

GR

AM

AÇ

ÃO

( com base no Mapa Detalhado de Viagens existente, é efectuada a actualização das datas do Programa em causa)

EXCELMapa Detalhado das Viagens antigo

1 V ez p/P rogra m a(1 por Fas e no TS )

EXCELMapa Detalhado das Viagens actualizado

Coordenação da Programação

Actualizar as Unidades Hoteleiras no Mapa Detalhado das Viagens


(no referido mapa são actualizadas as vár ias Unidades Hoteleiras que vão trabalhar no Programa em causa e respectivas datas dos Grupos)



Actualizar as Unidades Hoteleiras no Mapa Detalhado das Viagens

(com base no “Grupos Delegações”, é efectuada a distr ibuição dos Grupos. Tentando que os Grupos por Delegação não tenham muitas datas coincidentes)EXCEL

Quadro Grupos Delegações


EXCELMapa Detalhado das Viagens para aprovação superior


Submeter a Autorização Superior o Mapa Detalhado de Viagens

(a proposta do Mapa Detalhado é submetida à consideração Superior. Se for aprovada este Mapa será base para a elaboração do Quadro de Viagens. Se não for, são efectuadas as alterações em causa, até aprovação)

EXCELMapa Detalhado das Viagens


Chefia de Divisão

Mapa Detalhado aprovado?

Não

Efectuar Alterações Indicadas Superiormente

SimMapa Detalhado de Viagens

Final e Base de Trabalho para o Quadro de Viagens

Enviar para Aprovação

EXCEL

Quadro de Viagens

Imagem 26 – Visio criado por funcionários do Inatel

63

5.3.Extensões ao trabalho

Neste caso de estudo utilizaram-se algumas extensões cujos objectivos não se enquadram

directamente com os objectivos principais deste trabalho. Porém, considerou possível a utilização dos

conceitos definidos neste trabalho e adapta-los. Como consequência foram definidos os seguintes

objectivos secundários:

• Levantar o modelo “As-Is”.

• Auxiliar a transição do modelo “As-Is” para o modelo “To-Be”.

De forma a auxiliar a transição do “As Is” para o “To Be” decidiu-se implementar na ferramenta

uma visualização mais simplificada dessa transição. Esta representação irá utilizar como base o trabalho

realizado no âmbito da representação multi-dimensional.

Para tal ser realizado, foi atribuído às várias dimensões e diagramas um campo adicional que

identifica os objectos da arquitectura como sendo do tipo “As Is” ou do tipo “To Be”. Adicionalmente cada

dimensão pode ser relacionada com outras dimensões do seu tipo, através da utilidade “matrix browser”

da ferramenta. Esta relação irá descrever o relacionamento da respectiva dimensão com o “As Is” e com

o “To Be”.

5.3.1.Dimensão Sistema

O meta-modelo utilizado na página 22 pode ser facilmente adaptado de forma a satisfazer outras

necessidades de modelação. Tendo em consideração o processo de negócio como o conceito agregador,

foi adicionado a dimensão “Sistema”. Esta nova dimensão tem correspondência no nível lógico da

framework de Zachman, (contrariamente às restantes dimensões, que pertencem ao nível conceptual), e

irá modelar e representar os sistemas de informação utilizados nos processos de negócio. O conceito de

“Sistema” está directamente relacionado com a dimensão “How” do nível lógico da framework de

Zachman.

O meta-modelo foi necessariamente estendido de modo a reflectir esta alteração (Imagem 27).

64

Processo Entidade InformacionalActor

ObjectivoTempo

Localização

* **

*

*

1

**

*

*

1

*

1*

1*

**

1*1

*

**

Input

Output*

*

Sistema*

* 1*

Imagem 27 – Meta-modelo com sistema

Para tal foi utilizada a definição “Application”, já existente no System Architect e criado um novo

diagrama (Diagrama de Sistemas) para modelar a estrutura dos sistemas. Este diagrama é idêntico aos

diagramas criados para restantes dimensões, sendo portanto hierárquico. Este diagrama é utilizado na

modelação dos sistemas utilizados na organização do Inatel.

Imagem 28 – Diagrama de Sistemas

5.3.2.Representação da transição do “As Is” para o “To Be”

Uma arquitectura “As-Is” de uma organização pode ser definida como uma representação da

realidade actual dos seus processos e conceitos fundamentais. Por outro lado, arquitecturas “To-Be” de

organizações são definidas como representações dos processos e conceitos fundamentais à empresa no

futuro, isto é, o estado futuro da organização. Estes dois tipos de arquitecturas são utilizados aquando de

65

uma fase de transição/remodelação da organização, tal como é no caso do Inatel. A arquitectura “As-Is” é

usada para saber como os processos são conduzidos. Quando se trata também de identificar, melhorar e

corrigir ineficiências, são utilizados os modelos “To-Be” em conjunto com os modelos “As-Is”. Estes

modelos “To-Be” reflectem o funcionamento optimizado da organização.

Uma das fases mais importantes no processo de mudança de uma organização é, precisamente,

a transição entre o funcionamento da organização “As-Is” para o “To-Be”.

Assume-se que entre os dois modelos existem elementos comuns, isto é, cuja funcionalidade na

organização é idêntica, mesmo que não sejam conceptualmente iguais. Pode-se afirmar segundo a

afirmação anterior, que estes elementos estão relacionados entre si.

Esta funcionalidade vai de encontro com o objectivo de auxiliar a transição “As-Is” para o “To-Be”.

As dimensões e processos são classificados como pertencentes ao modelo “As-Is” ou ao modelo “To-Be”.

Podem-se associar dimensões da mesma classe às classes, de forma a representar como a dimensão

está relacionada com o modelo “To-Be”, ou quais são os modelos “As-Is” da dimensão em causa. Por

exemplo, o actor “Pessoa_1-As-Is” do modelo “As-Is” está relacionado com o actor “Pessoa_1-To-Be” e

“Pessoa_2-To-Be” do modelo “To-Be”. Isto implica que o actor “Pessoa_1-As-Is” é substituído por dois

actores no modelo “To-Be” (o actor “Pessoa_1-To-Be” e o actor “Pessoa_2-To-Be”).

A transição do “As-Is” para o “To Be” é facilitada da seguinte forma:

Uma dimensão (por exemplo, actor) “As Is” é substituída pela dimensão ou dimensões “To Be”

respectivas. Os processos de negócio do actor “As Is” são substituídos por processos “To Be” ou deixam

de ser realizados. Os processos de negócio dos actores “To Be” que não tenham nenhuma relação com o

“As Is” são considerados processos novos.

66

Imagem 29 – Transição de um actor "As Is" para o "To Be" e a relação com os processos

Na Imagem 29 está representada uma transição de actores. Este exemplo pode ser estendido

para as localizações, objectivos, tempos e entidades informacionais. Neste exemplo, o papel da

“Pessoa_1-As-Is” passa a ser desempenhado por dois novos actores no To-Be, a “Pessoa_1-To-Be” e a

“Pessoa_2-To-Be”. Dos processos realizados anteriormente pela “Pessoa_1-As-Is” (“Process_1-As-Is”,

“Process_2-As-Is”, “Process_3-As-Is”), o “Process_2-As-Is” deixa de ser realizado, o “Process_1-As-Is”

passa a ser realizado por dois processos To-Be (“Process_1-To-Be” e “Process_3-To-Be”) e o

“Process_3-As-Is” está integrado no “Process_3-To-Be”.

Imagem 30 – Processos "As Is" relacionados com o processo "To Be"

67

No caso dos processos de negócio, estes estão directamente relacionados uns com os outros.

Processos de negócio do tipo “As Is” que deixam de ser realizados não possuem qualquer ligação com os

processos de negócio pertencentes ao “To Be”. De igual forma, processos de negócio do “To Be” que são

completamente novos não possuem qualquer tipo de relação com os processos de negócio do “As Is”. No

exemplo da Imagem 30, o “Process_3-To-Be” substitui os processos de negócio “Process_1-AS-IS” e o

“Process_3-AS-IS”.

De forma a melhorar a visualização do “As-Is” e do “To-Be” dos processos, foi criado um

explorador, no qual a selecção de um processo resulta na visualização do processo de negócio e dos

processos de negócio relacionados nos diagramas BPMN.

Na Imagem 31 está representado o explorador “As-Is” “To-Be”. O processo de negócio

seleccionado para visualização (neste caso é um processo “As-Is”) encontra-se com o fundo azul e os

processos de negócio relacionados (processos “To-Be”) com fundo verde.

Imagem 31 - Explorador "As-Is" "To-Be"

Infelizmente, os modelos “To-Be” do caso de estudo Inatel não se encontram suficientemente

detalhados de forma a utilizar esta funcionalidade. Como tal, esta funcionalidade foi testada

essencialmente com modelos construídos com esta funcionalidade em mente.

68

5.4.Regras

5.4.1.Substituição de dimensões usadas nos processos por dimensões de mais alto nível

Esta funcionalidade implementada na ferramenta pesquisa as dimensões dos processos (actores,

localizações, inputs, outputs, objectivos, sistemas e tempos) e caso o processo de negócio em causa

possuir todas as dimensões irmãs, sugere a substituição dessas dimensões pela respectiva dimensão

pai, isto é subir o nível de abstracção.

No caso de estudo foram detectados dois (2) processos com dimensões que podiam subir no

nível de abstracção.

Processo: Dimensões a substituir: Subir Nível para:Recepção da Aprovação • Relatório Animadores Aprovado Relatórios AnimadoresSeleccionar tipo de Contrato (To Be)

• Contrato em Quantidade (To Be)• Contrato em Valor (To Be)

Contrato (To Be)

Tabela 5 – Subir o nível granularidade das primitivas utilizadas

5.4.2.Balanceamento de Processos

O balanceamento de processos procura colocar as dimensões nos processos de negócio pai de

acordo com as dimensões associadas nos seus sub-processos.

Se todos os sub-processos de um determinado processo de negócio X estiverem associados à

mesma dimensão Y, então o processo de negócio X pode estar associado à dimensão Y.

Por outro lado se uma dimensão D se decompor nas dimensões D1 e D2, e os sub-processos do

processo de negócio P estiverem associados às dimensões D1 e D2, então o processo de negócio P

pode estar associado à dimensão D. Isto é realizado para conseguir níveis de abstracção entre as

hierarquias dos processos de negócio e as suas dimensões.

No caso de estudo da Inatel, esta operação resultou no balanceamento descrito na Tabela 6.

Processo DimensõesContratação de Guias ViagemElaborar Conteúdos da Brochura BrochuraAderir Programa Sénior Célia Tapadas

Equipa de ProgramaçãoAnalisar e Avaliar desempenho dos Animadores Equipa de OperaçõesAnalisar Necessidade de Contratar Animadores Coordenação de Animadores

69

Equipa de OperaçõesApresentar aos Animadores as Unidades Hoteleiras e Prestadores de Serviços Coordenação de Animadores

Equipa de ProgramaçãoCalendarizar Programas Coordenação da ProgramaçãoDirectores Clínicos C. Moura

Equipa de ProgramaçãoDistribuir Brochuras nos Pontos de Venda Divisão Turismo SéniorElaborar e Enviar Contratos Ana Trindade

Equipa de OperaçõesElaborar Horários de Viagens Equipa de ProgramaçãoElaborar Quadro de Viagens Equipa de ProgramaçãoEnviar Material Gráfico Equipa de ProgramaçãoGestão das Agências de Viagens já Existentes nos Programas Seniores Célia Tapadas

Equipa de ProgramaçãoProposta Governamental Chefia DTS

Coordenação da ProgramaçãoEquipa de ProgramaçãoDirectora do Departamento

Receber Propostas dos Fornecedores Equipa de ProgramaçãoPropostas FornecedoresPropostas Fornecedores

Receber Textos e Fotos para Concurso e Apurar Premiados Equipa de ProgramaçãoVerificar a necessidade de Material para as Unidades Hoteleiras Divisão Turismo Sénior

Quadro com distribuição das Viagens para Unidades Hoteleiras

Tabela 6 – Balanceamento entre Processos e Dimensões

5.4.3.Processos de negócio folha com dimensões não folha

Quando um processo de negócio folha está associado a uma dimensão não folha, existe a

possibilidade de que esse processo de negócio está demasiado genérico ou abstracto, e portanto pode

ser decomposto em sub-processos que utilizem dimensões folhas, de forma a melhor detalhar o

funcionamento da organização.

No caso de estudo, a vasta maioria dos processos de negócio e dimensões detectadas nesta

situação estão relacionadas com a localização “Divisão de Turismo Sénior”, uma vez que esta é

decomposta nas dimensões “Equipa de Programação” e “Equipa de Operações”. Isto significa que os

processos de negócio do Inatel não possuem o detalhe suficiente para se observar o modo de

funcionamento das localizações “Equipa de programação” e “Equipa de Operações”.

70

Processos Dimensões Não FolhaAcompanhar os Trabalhos de Embalamento/Etiquetagem Divisão Turismo SéniorAcompanhar os Trabalhos de Entrega dos CTT nos Pontos de Venda Divisão Turismo SéniorAssociar Hotéis e Tipos de Quartos (To Be) SAP (To Be)Associar Partidas (To Be) SAP (To Be)

Conferir os Serviços e Valores PrestadosInformação das Operações referente à realização dos Grupos

Criação da solicitação de cotação (To Be) SAP (To Be) Criar registo específico Contrato (To Be)Elaborar Quadro dos Passeios Relatórios AnimadoresEnvio de Material Divisão Turismo SéniorLeitura do Relatório Final Relatórios AnimadoresNecessidade de Material para as Unidades Hoteleiras Divisão Turismo SéniorRecepção de Questionários e Relatórios Relatórios AnimadoresRegistar factura (To Be) SAP (To Be)Registo de Pedido de Compra (To Be) SAP (To Be)Relatório Semanal Relatórios AnimadoresSeleccionar tipo de Contrato (To Be) Contrato (To Be)Acompanhar Preparação dos Trabalhos de Entrega dos CTT Divisão Turismo Sénior

Tabela 7 – Processos com dimensões não folha

5.4.4.Processos equivalentes detectados

Processos Equivalentes DimensõesCom Passagem Aérea Célia TapadasConferir Horários C. Maximino

C. MouraEquipa de ProgramaçãoHistórico BrochurasHorários Transportadora AéreaMichelinQuadro ViagensQuadro de Viagens com Horários Indicados

Analisar Necessidades de Contratação de Guias Profissionais Equipa de OperaçõesContactar os Guias Profissionais Albertina Martins

Ana DitzaCVsProcesso

71

Informar Agência Viagem Célia TapadasActualizar Quadro de Agências Equipa de Programação

Quadro de Agências

Ordenar Informação do Quadro de Viagens Por Origem, Unidade Hoteleira e Data Equipa de ProgramaçãoOrdenar Informação do Quadro de Viagens por Áreas de Destino Mapa Viagens Conferido

Mapa Viagens Ordenado

Informar Coordenação de Animadores Coordenação de AnimadoresReajustar Programa Equipa de Programação

Equipa de ProgramaçãoQuadro Passeios Turísticos Final

Contactar os Directores Clínicos C. MouraReceber Confirmações dos Directores Clínicos Equipa de ProgramaçãoEnviar Confirmações para a Contabilidade Quadro Datas Palestras

Enviar Contrato Ana TrindadeReceber Contrato Equipa de OperaçõesReenviar Contrato Contrato

Relatório Semanal Coordenação de AnimadoresLeitura do Relatório Final Equipa de Operações

Relatórios Animadores

Tabela 8 – Processos equivalentes

Esta procura foi realizada com foco nas dimensões Who, What e What.

Estes processos sem dimensões encontram numa das duas situações:

• A sua modelação encontra-se incompleta.

• Não possuem qualquer utilidade na organização.

Os processos:

• Enviar Contrato

• Receber Contrato

• Reenviar Contrato

elaborados pelos actores “Ana Trindade” e “Equipa de programação”, cuja entidade informacional

“Contrato” resulta do processo, podem ser reconsiderados e representados como apenas um processo

de negócio. A alteração foi validada e realizada.

Também os processos:

• Ordenar Informação do Quadro de Viagens por Áreas de Destino

72

• Ordenar Informação do Quadro de Viagens Por Origem, Unidade Hoteleira e Data

realizados pelo actor “Equipa de Programação” e com o “Mapa Viagens Ordenado” como

entidade informacional resultante, foram alterados para só um processo: “Ordenar Informação Quadro de

Viagens”.

Outros processos também podem ser considerados semelhante ou integrados num só processo.

É o caso dos processos:

• Enviar Contrato

• Receber Contrato

• Reenviar Contrato

dos processos:

• Ordenar Informação do Quadro de Viagens Por Origem, Unidade Hoteleira e Data

• Ordenar Informação do Quadro de Viagens por Áreas de Destino

dos processos

• Analisar Necessidades de Contratação de Guias Profissionais

• Contactar os Guias Profissionais

e dos processos:

• Com Passagem Aérea

• Conferir Horários

Aos restantes processos sugeridos como semelhantes falta informação para verificar se são de

facto idênticos. Em concreto as informações mais relevantes para uma correcta comparação entre

processos são os inputs e outputs dos processos, como se pode observar nos processos acima

descritos.

Informar Agência Viagem Célia TapadasActualizar Quadro de Agências Equipa de Programação

Quadro de Agências

Alguns destes processos de negócio são claramente distintos (se considerarmos o significado

dos nomes dos processos). É o caso dos processos “Informar Agência Viagem” e “Actualizar Quadro de

Agências”.

Os processos que não foram considerados iguais por falta de dimensões do tipo What, Who ou

Where foram os seguintes:

Processos DimensõesAcompanhar os Trabalhos de Embalamento/Etiquetagem Divisão Turismo Sénior

73

Acompanhar Preparação dos Trabalhos de Entrega dos CTT Lista Agências

Contactar RH Equipa de OperaçõesContratação de GuiasConfirmação das Actividades Com Prestadores de Serviços

Criação de Viagens (To Be)Gestor de Viagens (To Be)

Associar Hotéis e Tipos de Quartos (To Be)Associar Partidas (To Be)

Criar um Artigo Viagem por Template (To Be) Artigo Viagem (To Be)Criar um Artigo Viagem de raíz (To Be)

Efectuar Alterações Indicadas Superiormente Equipa de Programação

Efectuar Alterações Indicadas Superiormente Q. Proposta CFériasDocumento com Indicações

Planificar Viagens Divisão Turismo SéniorDirectores Clinicos

Alterar Reserva Equipa de ProgramaçãoReceber Pedido de autorização Superior para Gozar Prémio noutro Período Processo de ReservaPedido das novas Datas ao Centro de Férias

Enviar Proposta de Reservas para os Administradores dos Respectivos C. Férias Equipa de ProgramaçãoInformação das Delegações Célia TapadasRecepção da Informação das DelegaçõesDesactivar Agência de Viagens

Registo de Contrato (To Be) Contrato (To Be)Criar registo específico

Determinar Horários de Viagens Equipa de ProgramaçãoAnalisar Quantidade de Viagens por DelegaçãoReservar Grupos nos Centros de FériasElaborar Mapa Detalhado das ViagensReenviar E-Mail à Delegação em Falta

Retirar Agência de Viagens da Brochura Equipa de ProgramaçãoDevolução de Correio C. Moura

Célia Tapadas

Visita e Apresentação dos Animadores à Administração das Unidades Hoteleiras

Coordenação de Animadores

Conhecimento dos Vários Prestadores de Serviços Equipa de Programação

Tabela 9 – Processos sem conclusão na equivalência

Nestes processos de negócio pode-se verificar a ausência de informação suficiente (falta de

dimensões associadas) para se poder concluir se são de facto equivalentes. Os processos de negócio

74

que possuem somente a dimensão “Equipa de Programação” são de facto distintos. Porém a informação

necessária para diferenciar esses processos não foi obtida e portanto os processos de negócio estão

incompletos na sua modelação.

5.4.5.Processos sem inputs, processos sem outputs, processos sem actores, processos sem localizações, processos sem tempos

Existiram vários processos cuja modelação não relacionava processos com entidades

informacionais, actores e tempos

A lista destes processos é demasiada extensa para ser inserida neste relatório, mas desses

processos, muitos foram esclarecidos em reuniões com o Inatel e alterados. O resultado foi a

identificação e interligação de objectos do tipo da dimensão que se encontrava ausente aos processos de

negócio. Os processos de negócio não resolvidos encontram-se ainda sujeitos a uma análise mais

detalhada de forma a resolver estas questões e possibilitar uma modelação mais precisa da organização.

5.4.6.Processos sem Objectivos

O caso de estudo não contemplou a modelação de objectivos, como consequência a interligação

dos processos com os objectivos não foi alvo nos levantamentos dos processos de negócio. Desta forma,

não foi possível utilizar esta regra na validação do caso, dado não existir a modelação de objectivos na

arquitectura.

5.4.7.Processos folha com duas ou mais dimensões do mesmo tipo (excluindo a dimensão What)

Processo de Negócio Folha: Dimensões a utilizar nos sub-processos:Colocar Animador Coordenação de Animadores

Chefia DTSCom Passagem Aérea Célia Tapadas

C. MaximinoC. Moura

Conferir Horários Célia TapadasC. MaximinoC. Moura

Contactar os Guias Profissionais Albertina MartinsAna Ditza

Decisão de Anulação de Viagens Chefia DTSEquipa de Operações

Definir Programa Diário dos Grupos Coordenação de AnimadoresEquipa de Programação

Determinar Quantidades dos Vários Material Gráficos Equipa de ProgramaçãoEquipa de Promoção Vendas

Devolução de Correio C. Moura

75

Célia TapadasElaborar Inf. para Autorização Superior da Contratação dos Serviços de D. C. Chefia DTS

C. MouraDirectora do Departamento

Elaborar Informação Minuta de Oficio para remeter Proposta para o Ministério Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Elaborar Informação para enviar Proposta à Exma. Direcção Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Elaborar Minuta de Oficio para remeter Proposta para o Ministério Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Elaborar Orçamento Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Elaborar Proposta Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Elaborar Proposta da Distribuição dos Grupos por Delegação Chefia DTSCoordenação da Programação

Elaborar Proposta para Reserva de Grupos nos Centros de Férias Chefia DTSCoordenação da Programação

Enviar Ficheiros Informáticos da Minuta e Restantes Peça para o Ministério Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Enviar Proposta de Passeios Turísticos Para Análise e Parecer Coordenação de AnimadoresEquipa de Programação

Enviar Requisição à Consideração Superior Chefia DTSCoordenação da Programação

Envio de Informação para Boletim Informativo Chefia DTSIsabel SaboiaColaboradores da DTS

Formalizar Contratação dos Guias Profissionais Albertina MartinsAna Ditza

Informar Coordenação de Animadores Coordenação de AnimadoresEquipa de Programação

Informar Premiados do Respectivo Prémio Chefia DTSEquipa de Programação

Inserir Horários no Sistema Célia TapadasIsabel Saboia

Numerar Requisição Equipa de ProgramaçãoApoio Serviços Jurídicos

Planear Formação Coordenação de AnimadoresDivisão de PessoalChefia DTS

Preparar Contrato Coordenação de AnimadoresChefia DTSAna Trindade

Reajustar Programa Coordenação de AnimadoresEquipa de Programação

76

Receber Provas da Brochura enviadas pela Gráfica Chefia DTSEquipa de ProgramaçãoDirectora do Departamento

Receber Questionários Equipa de ProgramaçãoEquipa de Operações

Receber Relatório Do Guia Profissional Equipa de ProgramaçãoEquipa de OperaçõesColaboradores da DTSAlbertina Martins

Retirar Agência de Viagens da Brochura C. MouraCélia Tapadas

Sem Passagem Aerea Célia TapadasC. MaximinoC. Moura

Sistematizar Informação Chefia DTSEquipa de ProgramaçãoEquipa de Operações

Validar Prova Final da Brochura Chefia DTSEquipa de ProgramaçãoDirectora do Departamento

Verificar e Enviar os Processos Cartas-Convite Para os Vários Fornecedores Chefia DTSApoio Serviços Jurídicos

Verificar Provas dos Materiais Gráficos Equipa de ProgramaçãoEquipa de Promoção Vendas

Actualizar Conteúdo da Brochura Célia TapadasC. MaximinoC. Moura

Actualizar no Sistema Informático Célia TapadasIsabel Saboia

Alterar Horários e/ou Datas de Voos ou de Viagem (na 1ª semana) Célia TapadasC. MaximinoC. Moura

Analisar Calendário Chefia DTSCoordenação da ProgramaçãoDirectora do Departamento

Analisar Necessidades de Contratação de Guias Profissionais Albertina MartinsAna Ditza

Receber Aprovação D.C. Equipa de ProgramaçãoContabilidade Chiado

Vendas de Viagens (To Be) Divisão Turismo Sénior (To Be)Agências de Viagens (To Be)Delegações (To Be)

Confirmação das Actividades Com Prestadores de Serviços 1 vez por semanaPor Prestador de Serviço

Elaborar Requisição para Serviços de Hotelaria 1 Vez p/ Programa1 p/ Fase no TS

Entregar Brochura à Empresa Gráfica 2 Vezes p/ Programa1 p/ Fase no TS3 Vezes p/ Programa

Enviar Calendário para Elaboração da Brochura e Campanha Publicitária do Prog. 1 Vez p/ Programa1 p/ Fase no TS

77

Enviar Informação os Animadores Início do ProgramaMudança Animador

Actualizar Conteúdo da Brochura 1 Vez p/ Programa1 p/ Fase no TS

Alterar Reserva 1 vez p/ ano2 vezes p/ ano

Tabela 10 – Processos de negócio folha com duas ou mais dimensões do mesmo tipo

Os processos de negócio folha detectados com duas ou mais dimensões do mesmo tipo (Tabela

10) vieram reforçar a ideia prévia de que a maioria dos processos levantados no caso de estudo não se

encontram com o nível de detalhe desejado. Apesar de alguns destes avisos serem falsos (caso do

Alterar Reserva, com as dimensões 1 ver p/ ano e 2 vezes p/ ano, que significa que o processo é

realizado uma ou duas vezes por ano), muitos dos outros processos de negócios são de facto

merecedores de foco e de um esforço para os decompor em sub-processos. Isto deve ser realizado para

melhor compreender a sua forma de execução e como utilizam as dimensões relacionadas. De notar que

o tipo de dimensão mais encontrada por esta regra é a Who. Os actores que realizam os processos de

negócio folha, de facto não realizam a mesma tarefa na realidade, mas sim partes do processo. São

esses sub-processos que se desejam representados para melhor detalhar a arquitectura empresarial.

78

6.ConclusõesOs principais conceitos utilizados nas arquitecturas empresariais aqui detectados neste trabalho

correspondem às primitivas relacionadas com as dimensões da framework de Zachman. Estes são

“actor”, “entidade informacional”, “localização”, “objectivo”, “tempo” e “processo”. Estes conceitos

utilizados encontram-se situados na perspectiva conceptual da framework. Porém o meta-modelo pode

ser facilmente alterado de forma a modelar outros aspectos empresariais. Foi o caso com conceito de

“sistema”, pertencente ao nível lógico da framework de Zachman. Este conceito representa os sistemas

de informação utilizados nas organizações. O conceito de “sistema” foi utilizado no caso de estudo Inatel

e mostrou-se importante na modelação dos sistemas de informação existentes nesta.

A definição destes conceitos em níveis hierárquicos permite atribuir vários níveis de

granularidade aos modelos. Isto permite a visualização dos modelos consoante o detalhe desejado. Esta

estrutura de camadas permitiu a definição de regras, algumas com o objectivo de manter a consistência

entre os vários níveis de abstracção, outras com o objectivo de manter as camadas hierárquicas

balanceadas entre si.

O meta-modelo utilizado provou ser especialmente eficaz na representação dos modelos

arquitecturais e na interligação de conceitos. Isto deve-se, especialmente, ao facto de se ter utilizado o

processo de negócio como elemento agregador dos conceitos, e devido ao facto de este ser horizontal à

organização. Através dos processos de negócio, é possível visualizar a arquitectura empresarial sobre

qualquer ponto de vista. A representação pode ser efectuada sobre qualquer actor, entidade

informacional, localização, tempo, objectivo, processo e sub-processos ou sistema, ou qualquer

combinação entre estes conceitos. Isto significa que é possível criar representações concretas. Essas

representações podem estar relacionadas com a segurança (quem lida com o quê, através da associação

actor e entidade informacional), ou com implementação de um novo standard que exige a resolução de

alguns objectos específicos num período de tempo específico (entidades informacionais versus tempo). A

representação da arquitectura empresarial através das dimensões mostrou-se uma ferramenta importante

para o modelador obter rapidamente as interacções existentes na organização, e muito importante na

definição de regras para auxiliar o processo de modelação da organização.

A combinação entre dimensões e associação aos processos permitiram também detectar

possíveis problemas de modelação. Alguns desses problemas deparam-se com a modelação incompleta

dos processos, modelação incorrecta ou pontos ineficazes na organização. Destes problemas e com a

validação com o caso de estudo, verificou-se que as questões que exigiram maior atenção foram:

processos sem inputs, processos sem outputs e processos sem actores associados. Estas questões

tratavam-se essencialmente de falta de informação no momento da modelação. Outros problemas

encontrados deparavam-se com actores não associados a localizações, localizações sem actores

associados, associação das localizações de um processo inconsistente com os actores do processo. A

detecção destes erros através das regras implementadas permitiram auxiliar o processo de modelação.

79

A associação entre processos e as dimensões permite a interligação entre vários modelos

organizações de várias perspectivas. Esta interligação, bem como as regras e condições definidas neste

trabalho, introduzem um elevado grau de rastreabilidade entre os conceitos empresariais utilizados neste

trabalho.

Já fora do contexto inicial do trabalho, surgiu uma tentativa de representar a transição do modelo

“As-Is” para o modelo “To-Be”. Cada objecto utilizado na arquitectura pode ser definido como pertencente

ao modelo “As-Is” ou ao modelo “To-Be”. Ao associar objectos com a sua representação correspondente

no modelo oposto é então possível extrair informação sobre como é realizado o salto do modelo “As-Is”

para o modelo “To-Be”. Isto, associado com a interligação das dimensões, permite derivar como um

objecto e os seus processos de negócio são afectados (quais são os processos novos, os processos que

deixam de ser realizados e os processos substituídos pelos processos do modelo oposto). Infelizmente

não foi possível desenvolver o modelo “To-Be” do caso de estudo. Acredito que esta área precise de um

maior foco, não só devido ao impacto que pode ter nas empresas em processos de mudança, mas

porque o tema foi somente ligeiramente abordado neste trabalho.

7.Objectivos atingidosO objectivo da rastreabilidade entre modelos organizacionais é conseguido através da definição

dos processos de negócio e das suas relações com os restantes aspectos da organização. Através dos

processos de negócio pode-se então derivar as relações que cada objecto possui com os restantes

objectos relacionais.

A rastreabilidade conseguida no objectivo anterior permite a visualizar a arquitectura empresarial

através das dimensões. O utilizador pode, através da combinações de dimensão, visualizar as

interacções existentes nos elementos da organização. Desta forma fornece-se um método construir vistas

da arquitectura que procuram satisfazer uma preocupação específica dos stakeholders.

As regras definidas na página 30 atingem o objectivo de manter a sintaxe dos modelos ao impor

um conjunto de aspectos nas definições das interligações entre primitivas. Desta forma consegue-se que

os modelos construídos respeitam um conjunto de propriedades que procuram aumentar ao máximo o

nível de detalhe da arquitectura e que esta se encontre coerente.

Em relação ao objectivo secundário de representar a transição do modelo “As-Is” para o modelo

“To-Be” de uma organização, foi utilizado como base, o mesmo conceito de interligações entre primitivas

usado no objectivo da rastreabilidade. Foram definidas relações entre as primitivas de um modelo (“As-Is”

ou “To-Be”) com as primitivas do mesmo tipo mas do modelo oposto. Com isto, e com a rastreabilidade já

referida anteriormente, consegue-se extrair o “salto” que acontece quando se passa do modelo “As-Is”

para o modelo “To-Be”. Consegue-se portanto visualizar como é a primitiva afectada no modelo oposto e

como os seus processos de negócio são alterados.

80

8.Trabalho futuroDa elaboração deste trabalho surgiu alguns aspectos que julgo ser de interesse para trabalhos

futuros.

Na dimensão tempo, neste trabalho associada à frequência de execução de um processo,

poderiam ser adicionados conceitos como o da restrição de tempos de execução dos processos,

normalmente encontrado nas “object constrain languages”. Apesar de ser um aspecto relacionado com

simulação, penso que seria de interesse adicionar essa informação de forma a cruzar com outros

elementos, tais como entidades informacionais e actores, e desta forma identificar objectos e cargos de

uso intensivo e portanto críticos nas actividades da organização. Isto seria um aspecto de maior

importância nas organizações cujas actividades dependem fortemente de componentes e restrições

temporais.

Outro aspecto que julgo ser de interesse focar no futuro é na associação entre entidades

informacionais e processos de negócio. A representação dos processos de negócio através da notação

“Business Process Modelling Notation” relaciona os processos de negócio com as entidades

informacionais através de ligações de associação. Durante a validação do trabalho, e em particular

quando lidei com as entidades informacionais, comecei a questionar se faria mais sentido realizar esta

associação, não com a própria entidade informacional, mas com um dos estados da entidade

informacional. Uma vez que o processo actua, ou altera, a própria entidade informacional, julgo que a

gestão e modelação documental beneficiaria de tal associação. Tornaria também as consequências dos

processos de negócio mais transparentes ao modelador.

Porque o aspecto da transição dos modelos “As-Is” para os modelos “To-Be” foi levemente

abordado neste trabalho, acredito que esta seja uma área que mereça uma maior dedicação daquela que

dediquei neste trabalho. Apesar de estar convencido da sua importância devido ao impacto que tem a

fase de transição nas organizações, reforçar a minha afirmação que esforços que procurem representar

essa etapa na vida das organizações só podem trazer benefícios no próprio desenho do “modelo To-Be”,

bem como tornar mais compreensível a forma como essa transição deve ser realizada.

Deste trabalho resultou um conjunto de regras aplicáveis às interligações entre primitivas das

células da framework de Zachman. Porém, não foi alvo deste trabalho a elaboração de regras a aplicar às

próprias primitivas. Quero dizer com isto que associações entre primitivas com diferentes finalidades não

são detectadas. Inconsistências como a seguinte não são detectadas:

O processo de negócio “Construir carro” com uma relação com a entidade informacional

“Factura”, a qual indica que o processo “Construir carro” utiliza o objecto “Factura”.

81

Seria muito mais lógico o processo de negócio “Construir carro” utilizar entidades informacionais

relacionadas com carro (rodas, motor, chassi...). Para detectar esta inconsistência entre elementos

deveria ser criada meta-informação comum entre os elementos processo de negócio “Construir carro” e

as entidades informacionais “rodas”, “motor”, “chassi” e “factura”. Creio que a meta-informação

necessária esteja relacionada com o propósito dos objectos. Apesar de ser um problema complicado,

julgo que seja possível, com um esforço adicional na modelação da organização, criar regras aplicáveis à

própria semântica dos modelos.

Referências• (Towers S 2005) Towers S, Burlton R. In Search Of BPM Excellence: Straight From

The Thought Leaders, Meghan Kiffer Pr, 2005, (Capítulo 10).

• (Smith 2006) Smith, Howard & Fingar, Peter. Business Process Management, The

Third Wave, Meghan-Kiffer Press, 2006, (página 47).

• (Holt 2005) Holt, John. A pragmatic guide to Business Process Modelling, BCS, 2005.

(página 4).

• (Rittgen 2006) Rittgen, Peter. Enterprise Modeling and Computing with UML, IDEA

GROUP Publishing, 2006.

• (Marshall, 1999) Marshall, Chris. Enterprise Modeling with UML, Addison Wesley,

1999, (página 271).

• (Sousa, 2006) Sousa, Pedro, et all. Applying the Zachman Framework Dimensions to

Support Business Process Modeling, 3rd International CIRP Conference on Digital

Enterprise Technology, 2006.

• (Eriksson, 2001) Eriksson, Hans-Erik & Penker, Magnus. Business Modeling with

UML. Business Patterns at Work, OMG PRESS, 2001, (página 87 a 89).

• (Zachman, 2003) Zachman, The Framework for Enterprise Architecture, Cell

Definitions, The Zachman Institute for framework Advancement, 2003.

• (Macedo 2005) Macedo, Patricia & Tribolet, José. Análise de Conformidade de

Modelos Organizacional com a Norma ISO 14258 - Concepts and Rules for

Organizational Models, 6ª Conferência da Associação Portuguesa de Sistemas de

Informação, Oct. 2005.

82

• (Iyer B 2004)Iyer B. & Gottlieb R. The Four-Domain Architecture: An approach to

support enterprise architecture design, IBM systems journal, vol 43, no 3, 2004.

• (Locke) Locke, Stan. Zachman Classification, Implementation & Methodology.

Zachman Frameowork Associates, 2005.

• (Zachman, 2007) Zachman, J., Zachman on the Framework, Zachman Internacional

Inc, 2003.

• (Sousa, 2003) Sousa, Pedro & Pereira, Carla. Getting into the misalignment between

Business and Information Systems, 10th European Conference On Information

Technology Evaluation, 2003.• (Mendes, 2003) Mendes, Ricardo; Mateus, João; Silva, Eduardo & Tribolet, José. Applying

Business Process Modeling To Organizational Change. American Conference on Information

Systems (AMCIS) 2003, 2003.

83

1.Anexo A – Manual do Utilizador

1.1.Preparar enciclopédia para a macro

Para utilizar a macro com as funcionalidades descritas neste trabalho é necessário realizar 3

passos.

Passo 1:

Importar o ficheiro usrprops.txt definido neste trabalho para a enciclopédia desejada. O ficheiro

pode ser importado através da ferramenta SAEM (SQL Server) ou através da própria interface do System

Architect.

Passo2:

Através da ferramenta SAEM (SQL Server) adicionar as imagens na enciclopédia a usar:

Actor.bmp

Actor.wmf

EntInf.bmp

EntInf.wmf

FaltaActor.wmf

FaltaLoc.wmf

NaoUsado.wmf

Sistema.bmp

Sistema.wmf

Tempo.bmp

Tempo.wmf

As imagens devem ficar com o path images/<nome da imagem>. Para tal as imagens deve estar

dentro da pasta “images” no momento da importação.

Passo 3:

Adicionar a macro através da interface do System Architect, menu Macros, e re-abrir a

enciclopédia.

1.2.Definição dos processos de negócioA modelação dos processos de negócio é realizada em dois tipos de diagramas. Os diagramas

Business Process Hierarchy são utilizados para definir uma estrutura hierárquica dos processos de

negócio de alto nível. Os diagramas BPMN são utilizados para modelar os processos de negócio de baixo

nível e a fluxo de execução entre eles.

A transição entre diagramas Business Process Hierarchy para os diagramas BPMN é realizada

através da funcionalidade da ferramenta System Architect “add children”. Esta funcionalidade também é

realizada para criar os níveis de granularidade nos processos BPMN.

84

Os processos de negócio que utilizem entidades informacionais (inputs e outputs) devem

representar essa informação. Os inputs devem ser adicionados ao diagrama BPMN (através do objecto

Data Object) e relacionados com os processos através de uma ligação de associação no sentido Data

Object -> Business Process. De forma semelhante, os outputs devem ser relacionados com os processos

de negócio com uma ligação de associação no sentido Business process -> Data Object.

1.3.Definição dos actores, entidades informacionais, localizações, objectivos, tempos e sistemas.

A definição de cada um destes objectos é realizada em diagramas hierárquicos específicos.

A Tabela 11 indica os diagramas utilizados para a definição de cada objecto.

Objecto DiagramaActor Diagrama de ActoresEntidade Informacional Diagrama InformaçãoObjectivo Enterprise DirectionLocalização Organization ChartTempo Diagrama TempoSistema Diagrama Sistemas

Tabela 11 – Objectos e respectivos diagramas

1.4.Representação visual das dimensões e dos processos

1.4.1.ProcessoNos diagramas “BPMN” e “Business Process Hierarchy” os símbolos utilizados na representação

dos processos de negócio são os da própria ferramenta.

Na interface RMD, os processos são representados pela Imagem 32.

Imagem 32 – Representação dos processos

1.4.2.ActorOs actores são representados pela Imagem 33, tanto nos diagramas do tipo “Actor” como na

interface RMD.

85

Imagem 33 – Representação dos actores

1.4.3.LocalizaçãoOs símbolos do tipo “Localização” nos diagramas “Organization Chart” são representados pela

imagem por omissão da ferramenta “System Architect”.

Na interface RMD é utilizada a Imagem 34 para representar localizações.

Imagem 34 – Representação das localizações

1.4.4.ObjectivoOs símbolos do tipo “Objectivo” no diagrama “Enterprise Direction” são representados pela sua

imagem por omissão da ferramenta do “System Architect”.

Na interface RMD é utilizada a Imagem 35 para representar objectivos.

Imagem 35 – Representação dos objectivos

1.4.5.TempoA dimensão tempo é representada pela Imagem 36 nos diagramas do tipo “Tempo” e na interface

RMD.

Imagem 36 – Representação dos tempos

1.4.6.Entidade InformacionalAs entidades informacionais são representadas pela Imagem 37 nos diagramas de informação

nos diagramas do tipo BPMN e na interface RMD.

86

Imagem 37 – Representação das entidades informacionais

1.4.6.1.Tipo InputQuando na interface RMD as entidades informacionais estão associadas aos processos de

negócio como inputs, estes são representados com a Imagem 38.

Imagem 38 – Representação de Inputs

1.4.6.2.Tipo OutputQuando na interface RMD as entidades informacionais estão associadas aos processos de

negócio como outputs, estes são representados com a Imagem 39Imagem 38.

Imagem 39 – Representação de Outputs

1.4.7.SistemaOs sistemas possuem a representação da Imagem 40 nos diagramas de sistemas e na

representação RMD.

Imagem 40 – Representação de Sistemas

1.5.Interface Representação Multi-Dimensional

87

Imagem 41 – Menu principal

A Imagem 41 representa a interface do menu principal da macro realizada para o System

Architect. Os seis botões no topo representam os conceitos da perspectiva conceptual da framework de

Zachman, cada um com relação a uma das dimensões da framework de Zachman.

• O botão “Ver processos” representa a arquitectura pela dimensão How.

• O botão “Ver actores” representa a arquitectura pela dimensão Who.

• O botão “Ver localizações” representa a arquitectura pela dimensão Where.

• O botão “Ver Entidades Informacionais” representa a arquitectura pela dimensão What.

• O botão “Ver Objectivos” representa a arquitectura pela dimensão Why.

• O botão “Ver Ocorrências” representa a arquitectura pela dimensão When.

• O botão “Ver Sistemas” representa a arquitectura pela dimensão How mas na

perspectiva lógica da framework de Zachman.

• O botão “Perquisar” permite pesquisar processos com algumas características (com ou

sem dimensões tipo, ou relacionados com um conjunto de dimensões específicas).

• O botão “As-Is To-Be” permite visualizar a transição dos elementos As-Is To-Be.

• O botão “Regras” permite executar regras de auxílio à modelação e regras que garantem

a consistência da arquitectura.

• O botão “Exportar Matrizes” permite criar ficheiros “xls” com matrizes das interligações

entre dimensões.

88

1.5.1.Representação das dimensões

A arquitectura empresarial pode ser visualizada através das dimensões da framework de

Zachman. A Imagem 42 mostra a interface utilizada para visualizar a arquitectura, neste caso através da

dimensão How. A Imagem 43 mostra a mesma interface mas visualizada pela dimensão Who.

A dimensão How mostra-nos os processos de negócio, os seus sub-processos e as outras

dimensões relacionadas com os processos de negócio. A dimensão Who mostra os processos de

negócios realizados pelos actores, e através desses processos, as interacções com outros actores, as

entidades informacionais utilizadas, os sistemas utilizados, as localizações onde ocorrem, os objectivos

associados e os tempos de execução.

Imagem 42 – Visualização da arquitectura através dos processos de negócio

89

Imagem 43 – Visualização da arquitectura através dos actores

1.5.2.Visualização do “As-Is” e do “To-Be”

Indica a que modelos pertencem os vários objectos definidos na arquitectura (modelo As-Is ou

modelo To-Be).

1.5.3.Regras

Nesta área pode-se executar as regras que auxiliam a modelação da organização. As regras são:

• Obter Processos equivalentes.

• Obter dimensões não associadas a processos de negócio.

• Verificar possíveis subidas na granularidade dos objectos associados aos processos de

negócio.

• Verificar balanceamento dos níveis dos processos de negócio.

• Obter processos de negócio folha associados a dimensões não folha.

• Obter actores não associados a localizações.

• Obter localizações sem actores associados.

• Verificar compatibilidade entre localizações dos processos e localizações dos actores

associados ao processo.

• Obter processos folha com duas ou mais dimensões do mesmo tipo.

• Colocar Analytics.

90

A funcionalidade “Processos equivalentes” devolve os processos com dimensões associadas

iguais. Deve-se seleccionar os tipos de dimensões pelas quais a procura será realizada. Se por exemplo,

desejar-se obter os processos equivalentes somente através dos seus actores e localizações deverá

seleccionar-se a dimensão Who e Where (Actores e Localizações) e a funcionalidade apenas considerá

estas duas dimensões na comparação de processos.

Quando se realiza uma procura de processos equivalentes com um conjunto de dimensões e um

processo não possui uma dimensão nesse conjunto de dimensões, então não é possível concluir se esse

processo é equivalente aos restantes. Estes processos de negócio são devolvidos numa lista à parte com

essa mesma informação. Por exemplo, se executar-se a função com as dimensões do tipo actor,

localização e objectivo seleccionadas, não se pode concluir a equivalência dos processos de negócio só

com o actor “João” e a localização “Lisboa”.

1.5.4.PesquisaEsta opção permite uma visualização da arquitectura empresarial mais específica. Encontra-se

dividida em duas partes.

Uma dessas partes (Imagem 44) permite pesquisar processos com ou sem determinada

dimensão relacionada. Esta funcionalidade de procura de processos de negócio permite obter:

• Processos de negócio sem actores.

• Processos de negócio sem localizações.

• Processos de negócio sem inputs.

• Processos de negócio sem outputs.

• Processos de negócio sem sistemas.

• Processos de negócio sem objectivos.

• Processos de negócio sem tempos.

De forma semelhante é possível obter os processos que possuem relações com qualquer tipo de

dimensão, isto é:

• Processos com actores.

• Processos com localizações.

• Processos com inputs.

• Processos com outputs.

• Processos com sistemas.

• Processos com objectivos.

• Processos com tempos.

91

Imagem 44 – Pesquisa de processos de negócio através de dimensões tipo

A segunda parte da funcionalidade “pesquisa” devolve os processos de negócio associados a

objectos concretos das dimensões. No exemplo da Imagem 45 é efectuada uma pesquisa pelos

processos de negócio cuja pessoa que os executa / responsável é a Célia Tapadas através do sistema

SCG. O resultado foi o processo de negócio “Introduzir Horários no Sistema”.

92

Imagem 45 – Pesquisa de processos de negócio através de elementos concretos

Qualquer destas pesquisas podem devolver informação adicional sobre os processos de

negócios encontrados através da selecção das dimensões na área “Filtro Dimensões”.

1.6.Auxilio visual à transição do “As-Is” e “To-Be” nos processos

1.6.1.Visualização das relações dos processos no diagrama actual

De forma a auxiliar a visualização dos processos novos, dos processos que deixam de ser

realizados e dos processos que possuem uma relação com outros processos da outra representação “As-

Is” ou “To-Be”, adicionou-se uma funcionalidade que altera a cor de fundo dos símbolos, de forma a

reflectir essas características.

Símbolos do tipo “processo de negócio” com a cor de fundo vermelha (Imagem 46) representam

processos de negócio da arquitectura “As-Is” obsoletos (que deixam de ser realizados na arquitectura

“To-Be”).

93

Imagem 46 – Processo de negócio não utilizado no "To-Be"

Símbolos do tipo “processo de negócio” com a cor de fundo verde (Imagem 47) representam

processos de negócio da arquitectura “To-Be” que não possuem qualquer tipo de relação com processos

da arquitectura “As-Is”, como tal, são completamente novos na organização.

Imagem 47 – Processo novo no "To-Be"

Símbolos do tipo “processo de negócio” com a cor de fundo amarelo fosco (Imagem 48)

representam processos de negócio com correspondência a outros processos de negócio do modelo

oposto.

Imagem 48 – Processo reutilizado

Esta opção é activada para o diagrama de processos de negócio aberto através do menu Multi-

Dim → Mostrar Cores.

Esta opção é desactivada para o diagrama de processos aberto através do menu Multi-Dim →

Reset Cores.

1.6.2.Explorador “As-Is” “To-Be”O explorador “As-Is” “To-Be” permite seleccionar um processo de negócio e comparar esse

processo de negócio com os processos de negócio do modelo oposto.

94

Imagem 49 - Explorador "As-Is" "To-Be"

A Imagem 49 representa o explorador. No lado direito do ecrã encontra-se o explorador com os

processos de negócio existentes na arquitectura. Após seleccionar o processo, o diagrama onde se

encontra o processo seleccionado é aberto. Também são abertos os diagramas dos processos

relacionados. No processo de negócio seleccionado para visualização é colocado o fundo do símbolo a

azul. Nos processos de negócio relacionados os símbolos são colocados com fundo verde.

Esta representação facilita a visualização entre a transição entre os modelos “As-Is” e os

modelos “To-Be”.

O comando para executar o explorador encontra-se no menu Multi-Dim → Explorador As-Is To-

Be.

1.6.3.Visualização das dimensõesPara os actores, entidades informacionais, localizações, tempos, objectivos e sistemas a

visualização do “As-Is” “To-Be” é feita de forma diferente. Dado que a principal associação destas

dimensões são com os processos de negócio, é necessário considerar os processos de negócio nestas

visualizações.

Esta visualização fornece informação das dimensões associadas, informação sobre quais os

processos onde a dimensão era executada, os processos novos que irão ser realizados pelas dimensões

associadas, e os processos relacionados com os antigos processos.

A Imagem 50 exemplifica com a dimensão actor “Pessoa_1-As-Is”. Neste exemplo, o actor

“Pessoa_1-As-Is” passa a ser desempenhado pelos actores “Pessoa_1-To-Be” e “Pessoa_2-To-Be”.

Os processos desempenhados pela “Pessoa_1-As-Is”:

• “Process_1-As-Is”

95



passam a ser desempenhados no “To-Be” da seguinte forma:

• O “Process_1-As-Is” é decomposto em dois processos, o “Process_1_To-Be” e o

“Process_3-To-Be”.

• O “Process_2-As-Is” não tem qualquer associação com os processos do “To-Be” e

portanto deixa de ser executado no “To-Be”.

• O “Process_3-As-Is” passa a estar integrado com o “Process_3-To-Be”.

Imagem 50 – Transição do actor "Pessoa_1-As-Is"

1.7.AnalyticsA funcionalidade “Analytics” do “System Architect” permite executar métricas na informação dos

diagramas e associar representações visuais aos símbolos dos diagramas.

Foram utilizadas analytics para as seguintes situações:

• Dimensão não utilizada em processos.

• Actor não associado a localizações.

• Localizações sem actores associados.

Estas funcionalidades são activadas para o diagrama aberto através do menu Multi-Dim →

Mostar Analytics Actual.

96

Estas funcionalidades também podem ser activadas para todas as dimensões através do

comando no menu Multi-Dim → Mostrar Analytics todos diagramas. Em alternativa, pode-se aceder a

esta funcionalidade através da interface RMD → Regras → Botão “Mostrar Analytics”.

Quando se deseja colocar as analytics nos simbolos do diagrama em utilização deve-se utilizar o

comando no menu Multi-Dim → Mostrar Analytics diagrama actual.

Para que as analytics dos símbolos sejam visíveis nos diagramas é necessário activar a opção

do System Architect “Show Analytics”. Para tal, basta clicar em qualquer local do diagrama com o botão

direito do rato e seleccionar essa opção.

Imagem 51 – Actor não usado nos processos e não associado a nenhuma localização

1.7.1.Dimensão não utilizada em processosQuando uma dimensão (actor, entidade informacional, localização, tempo ou objectivo) não está

presente em nenhum processo, significa que não é utilizada no modelo arquitectural ou que é somente

utilizada para uma representação lógica das suas sub-dimensões.

A Imagem 52 mostra a representação gráfica quando esta situação ocorre a alguma dimensão.

?Imagem 52 – Dimensão não utilizada

1.7.2.Actor não associado a localizaçõesOcorre quando um actor não possui qualquer associação aos objectos do tipo localizações. Isto

indica que a definição do actor na estrutura da organização não está bem definida.

A representação gráfica para esta situação está representada na Imagem 53.

97

?Imagem 53 – Actor não associado a localizações

1.7.3.Localização sem actores associadosQuando uma localização não possui qualquer actor associado, é uma indicação de que a

localização em causa não representa fielmente a realidade da organização.

A representação para os símbolos localizações nesta situação é a da Imagem 54.

?Imagem 54 – Localização sem actores associados

1.8.Exportar matrizes

A funcionalidade “Exportar matrizes” no menu principal da interface Representação Multi-

dimensional permite criar ficheiros no formato “xls” com as matrizes de interligações entre primitivas.

Permite exportar as interligações de qualquer tipo de primitivas (Actores, Entidades Informacionais,

Tempos, Sistemas, Objectivos e Localizações). O ficheiro gerado pode ser aberto por Excel, contendo

seis (6) folhas, uma para cada dimensão. Nas linhas encontram-se os objectos da dimensão exportada,

nas colunas os objectos da dimensão da folha em causa. Uma relação entre dois objectos é representada

por um “x”.

98

2.Anexo B – Userprops

2.1.Introdução

O ficheiro userprops permite adaptar o meta-modelo da ferramenta System Architect. É através

deste ficheiro que se implementou o meta-modelo definido neste trabalho, de forma a permitir relacionar o

processo de negócio com os restantes elementos e chegar à representação multi-dimensional. Foi

também neste ficheiro que se adicionou os novos diagramas, símbolos e definições, necessários à

representação multi-dimensional.

Neste ficheiro foram incluídos:

● O diagrama de Informação.

● O diagrama de Tempo.

● O diagrama de Sistemas.

Foram incluídos os símbolos:

● Pessoa.

● Informação.

● Tempo.

● Sistema.

Também foi criada a definição de Frequência, utilizada na dimensão When.

2.2.Configuração utilizada

REM "USRPROPS.TXT"REM "1986-2006 Copyright Telelogic AB"

REM "Instructions for modifying this file are in the on-line help."

RENAME Diagram "User 1" to "Actores"RENAME Diagram "User 2" to "Diag. Informacao"RENAME Diagram "User 3" to "Diag. Tempo"RENAME Diagram "User 4" to "Diag. Sistemas"

RENAME Symbol "User 1" to "Pessoa"

99

RENAME Symbol "user 2" to "Informacao"RENAME Symbol "User 3" to "Tempo"RENAME Symbol "User 4" to "Sistema"

RENAME Definition "User 1" to "Role/BPMN Process"RENAME Definition "User 2" to "Frequencia"

List "Analytic Loc" fixed 50{

Value "Sem Actor" depictions {bottom "images\FaltaActor.wmf"}Value "OK"

}

List "Analytic Act" fixed 50{

Value "Sem Loc" depictions {bottom "images\FaltaLoc.wmf"}Value "OK"

}

List "Analytic Usado" fixed 50{

Value "Nao Usado" depictions {right "images\NaoUsado.wmf"}Value "OK"

}

DIAGRAM "Actores"{

HIERARCHICALPROPERTY "Hierarchical Numbering"{ EDIT Boolean LENGTH 1 DEFAULT "F" }PROPERTY "First Node Number"{ EDIT Text Length 20 DEFAULT "1" }PROPERTY "As Is or To Be"

{ EDIT Text ListOnly LIST "AS-IS-TO-BE" HELP "Does this diagram represent how things are now or how they will be?"}

}

DIAGRAM "Diag. Informacao"{



100

}

DIAGRAM "Business Process Hierarchy"{

PROPERTY "As Is or To Be"{ EDIT Text ListOnly LIST "AS-IS-TO-BE" HELP "Does this diagram represent

how things are now or how they will be?"}}

DIAGRAM "Enterprise Direction"{



DIAGRAM "Organization Chart"{



DIAGRAM "Diag. Tempo"{



}

DIAGRAM "Diag. Sistemas"{



}

101

DEFINITION "BPMN Process"{

LAYOUT { COLS 2 TAB ALIGN OVER }CHAPTER "AS-IS ou TO-BE"

PROPERTY "As Is or To Be"{ EDIT Text ListOnly LIST "AS-IS-TO-BE" READONLY HELP "Does this diagram

represent how things are now or how they will be?"}PROPERTY "Processos Associados"{ZOOMABLE EDIT ListOf "BPMN Process" LENGTH 1200 READONLY}

CHAPTER "Dimensoes"PROPERTY "Actores"{ZOOMABLE EDIT ListOf "Role" LENGTH 1200 DISPLAY {FORMAT String LEGEND

"" }}PROPERTY "Objectivos"{ZOOMABLE EDIT ListOf "Business Objective" LENGTH 1200 DISPLAY {FORMAT

String LEGEND "" }}PROPERTY "Localizacoes"{ZOOMABLE EDIT ListOf "Organizational Unit" LENGTH 1200 DISPLAY {FORMAT

String LEGEND "" }}PROPERTY "Input Entidade Informacional"{ZOOMABLE EDIT ListOf "Data Object" LENGTH 1200}PROPERTY "Output Entidade Informacional"{ZOOMABLE EDIT ListOf "Data Object" LENGTH 1200}PROPERTY "Tempo"{ZOOMABLE EDIT ListOf "Frequencia" LENGTH 1200 DISPLAY {FORMAT String

LEGEND "" }}PROPERTY "Sistemas"{ZOOMABLE EDIT ListOf "Application" LENGTH 1200 DISPLAY {FORMAT String

LEGEND "" }}}

SYMBOL "Pessoa"{

DEFINED by "Role"ASSIGN TO "Actores"

DEPICTIONS { DIAGRAM RETAIN STYLE "images\Actor.wmf" }

DEPICTIONS { Menu "images\Actor.bmp" }

PROPERTY "Analytic Loc"{EDIT TEXT ListOnly List "Analytic Act" DEFAULT "OK" LENGTH 15}PROPERTY "Prop Analytic Usado"{EDIT TEXT ListOnly List "Analytic Usado" DEFAULT "OK" LENGTH 15}

}

102

SYMBOL "Informacao"{

DEFINED by "Data Object"ASSIGN TO "Diag. Informacao"

DEPICTIONS { DIAGRAM RETAIN STYLE "images\EntInf.wmf" }

DEPICTIONS { Menu "images\EntInf.bmp" }PROPERTY "Prop Analytic Usado"{EDIT TEXT ListOnly List "Analytic Usado" DEFAULT "OK" LENGTH 15}

}

SYMBOL "Tempo"{

DEFINED by "Frequencia"ASSIGN TO "Diag. Tempo"

DEPICTIONS { DIAGRAM RETAIN STYLE "images\Tempo.wmf" }

DEPICTIONS { Menu "images\Tempo.bmp" }PROPERTY "Prop Analytic Usado"{EDIT TEXT ListOnly List "Analytic Usado" DEFAULT "OK" LENGTH 15}

}

SYMBOL "Organizational Unit" in "Organization Chart"{

PROPERTY "Analytic Actor"{EDIT TEXT ListOnly List "Analytic Loc" DEFAULT "OK" LENGTH 15}PROPERTY "Prop Analytic Usado"{EDIT TEXT ListOnly List "Analytic Usado" DEFAULT "OK" LENGTH 15}

}

SYMBOL "Objective" in "Enterprise Direction"{

PROPERTY "Prop Analytic Usado"{EDIT TEXT ListOnly List "Analytic Usado" DEFAULT "OK" LENGTH 15}

}

SYMBOL "Sistema"{

DEFINED by "Application"ASSIGN TO "Diag. Sistemas"

103

DEPICTIONS { DIAGRAM RETAIN STYLE "images\sistema.wmf" }

DEPICTIONS { Menu "images\sistema.bmp" }PROPERTY "Prop Analytic Usado"{EDIT TEXT ListOnly List "Analytic Usado" DEFAULT "OK" LENGTH 15}

}

DEFINITION "Role"{

PROPERTY "Related BPMN Processes"{ZOOMABLE EDIT ListOf "BPMN Process" LENGTH 1200 READONLY}PROPERTY "Related Locations"{ZOOMABLE EDIT ListOf "Organizational Unit" LENGTH 1200 READONLY}CHAPTER "AS-IS ou TO-BE"PROPERTY "As Is or To Be"

{ EDIT Text ListOnly LIST "AS-IS-TO-BE" READONLY HELP "Does this diagram represent how things are now or how they will be?"}

PROPERTY "Actores Associados"{ZOOMABLE EDIT ListOf "Role" LENGTH 1200 READONLY}

}

DEFINITION "Organizational Unit"{

PROPERTY "Related Actors"{ZOOMABLE EDIT ListOf "Role" LENGTH 1200 READONLY}CHAPTER "AS-IS ou TO-BE"PROPERTY "As Is or To Be"


PROPERTY "Localizacoes Associadas"{ZOOMABLE EDIT ListOf "Organizational Unit" LENGTH 1200 READONLY}

}

DEFINITION "Frequencia"{

CHAPTER "AS-IS ou TO-BE"PROPERTY "As Is or To Be"


PROPERTY "Tempos Associados"{ZOOMABLE EDIT ListOf "Frequencia" LENGTH 1200 READONLY}

}

DEFINITION "Data Object"{

CHAPTER "AS-IS ou TO-BE"

104

PROPERTY "As Is or To Be"{ EDIT Text ListOnly LIST "AS-IS-TO-BE" READONLY HELP "Does this diagram

represent how things are now or how they will be?"}PROPERTY "Entidades Informacionais Associadas"

{ZOOMABLE EDIT ListOf "Data Object" LENGTH 1200 READONLY}}

DEFINITION "Business Objective"{



PROPERTY "Objectivos Associados"{ZOOMABLE EDIT ListOf "Business Objective" LENGTH 1200 READONLY}

}

DEFINITION "Application"{



PROPERTY "Sistemas Associados"{ZOOMABLE EDIT ListOf "Application" LENGTH 1200 READONLY}

}

105

Representação Multi-Dimensional de Arquitecturas Empresariais

Documents

Transcript of Representação Multi-Dimensional de Arquitecturas Empresariais