Representação Multi-Dimensional de Arquitecturas Empresariais. Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores

Transcrição

1 Representação Multi-Dimensional de Arquitecturas Empresariais Mário Alexandre da Cruz Maçarico Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Orientador: Co-Orientador: Vogal: Prof. Alberto Manuel Rodrigues da Silva Prof. José Manuel Nunes Salvador Tribolet Prof. Pedro Manuel Moreira Vaz Antunes de Sousa Prof. Diogo Manuel Ribeiro Ferreira Agosto 2007

2 2

3 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

4 4

5 Resumo Este 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

6 Abstract This 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, Representation 6 Dimensions, Inter-connection, Rules,

7 Índice AGRADECIMENTOS... 3 RESUMO... 5 ABSTRACT...6 ÍNDICE IMAGENS... 9 ÍNDICE TABELAS INTRODUÇÃO CONTEXTO OBJECTIVOS ESTADO DA ARTE ARQUITECTURAS EMPRESARIAIS FRAMEWORK DE ZACHMAN PROCESSO DE NEGÓCIO PROCESSOS DE NEGÓCIO E DIMENSÕES REPRESENTAÇÃO MULTIDIMENSIONAL DE ARQUITECTURAS EMPRESARIAIS META-MODELO Níveis de Granularidade REPRESENTAÇÃO DOS PROCESSOS E DAS DIMENSÕES Representação dos Processos Representação dos Actores, Entidades Informacionais, Objectivos, Tempos e Localizações Tipos de representações REGRAS Regras Tipo Regras Tipo VALIDAÇÃO DO TRABALHO ANÁLISE DOS DIAGRAMAS EXISTENTES NO SYSTEM ARCHITECT DIAGRAMAS UTILIZADOS Diagrama de processo de negócio (Diagrama BPMN) Diagrama Business Process Hierarchy Diagrama Organization Chart Diagrama Enterprise Direction DIAGRAMAS CRIADOS Diagrama Informação Diagrama Actores Diagrama Tempo DEFINIÇÕES UTILIZADAS NO SYSTEM ARCHITECT IMPLEMENTAÇÃO Meta-modelo do System Architect Construção dos modelos Implementação da macro CASO DE ESTUDO INATEL INTRODUÇÃO CONTEXTO EXTENSÕES AO TRABALHO Dimensão Sistema

8 5.3.2.Representação da transição do As Is para o To Be REGRAS Substituição de dimensões usadas nos processos por dimensões de mais alto nível Balanceamento de Processos Processos de negócio folha com dimensões não folha Processos equivalentes detectados Processos sem inputs, processos sem outputs, processos sem actores, processos sem localizações, processos sem tempos Processos sem Objectivos Processos folha com duas ou mais dimensões do mesmo tipo (excluindo a dimensão What) CONCLUSÕES OBJECTIVOS ATINGIDOS TRABALHO FUTURO...81 REFERÊNCIAS ANEXO A MANUAL DO UTILIZADOR PREPARAR ENCICLOPÉDIA PARA A MACRO DEFINIÇÃO DOS PROCESSOS DE NEGÓCIO DEFINIÇÃO DOS ACTORES, ENTIDADES INFORMACIONAIS, LOCALIZAÇÕES, OBJECTIVOS, TEMPOS E SISTEMAS REPRESENTAÇÃO VISUAL DAS DIMENSÕES E DOS PROCESSOS Processo Actor Localização Objectivo Tempo Entidade Informacional Sistema INTERFACE REPRESENTAÇÃO MULTI-DIMENSIONAL Representação das dimensões Visualização do As-Is e do To-Be Regras Pesquisa AUXILIO VISUAL À TRANSIÇÃO DO AS-IS E TO-BE NOS PROCESSOS Visualização das relações dos processos no diagrama actual Explorador As-Is To-Be Visualização das dimensões ANALYTICS Dimensão não utilizada em processos Actor não associado a localizações Localização sem actores associados EXPORTAR MATRIZES...98 ANEXO B USERPROPS INTRODUÇÃO CONFIGURAÇÃO UTILIZADA

9 Índice Imagens REPRESENTAÇÃO DE UM PROCESSO ATRAVÉS DAS DIMENSÕES META-MODELO REPRESENTAÇÃO DOS PROCESSOS...27 REPRESENTAÇÃO DE UM PROCESSO COM DIMENSÕES REPRESENTAÇÃO DE UM ACTOR INCONSISTÊNCIA ENTRE PROCESSOS, ACTORES E LOCALIZAÇÕES...31 PROCESSO PAI COM DIMENSÃO MENOS GENÉRICA BALANCEAMENTO DAS DIMENSÕES USADAS BALANCEAMENTO NOS NÍVEIS HIERÁRQUICOS DECOMPOSIÇÃO DE UM PROCESSO DIAGRAMA BPMN COM A NOTAÇÃO DE INPUTS E OUTPUTS BUSINESS PROCESS HIERARCHY ORGANIZATION CHART ENTERPRISE DIRECTION 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 PROCESSOS FOLHA COM 2 OU MAIS DIMENSÕES DO MESMO TIPO LOCALIZAÇÕES FOLHA SEM ACTORES PROCESSOS EQUIVALENTES 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 META-MODELO COM SISTEMA DIAGRAMA DE SISTEMAS TRANSIÇÃO DE UM ACTOR "AS IS" PARA O "TO BE" E A RELAÇÃO COM OS PROCESSOS PROCESSOS "AS IS" RELACIONADOS COM O PROCESSO "TO BE" EXPLORADOR "AS-IS" "TO-BE" REPRESENTAÇÃO DOS PROCESSOS...85 REPRESENTAÇÃO DOS ACTORES

10 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 REPRESENTAÇÃO DE SISTEMAS MENU PRINCIPAL VISUALIZAÇÃO DA ARQUITECTURA ATRAVÉS DOS PROCESSOS DE NEGÓCIO...89 VISUALIZAÇÃO DA ARQUITECTURA ATRAVÉS DOS ACTORES PESQUISA DE PROCESSOS DE NEGÓCIO ATRAVÉS DE DIMENSÕES TIPO PESQUISA DE PROCESSOS DE NEGÓCIO ATRAVÉS DE ELEMENTOS CONCRETOS PROCESSO DE NEGÓCIO NÃO UTILIZADO NO "TO-BE" PROCESSO NOVO NO "TO-BE" PROCESSO REUTILIZADO EXPLORADOR "AS-IS" "TO-BE" 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 ACTOR NÃO ASSOCIADO A LOCALIZAÇÕES LOCALIZAÇÃO SEM ACTORES ASSOCIADOS Índice Tabelas TABELA 1 DIMENSÕES DA FRAMEWORK DE ZACHMAN (SOUSA 2006) TABELA 2 RELAÇÕES ENTRE PRIMITIVAS E DIMENSÕES 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 TABELA 5 SUBIR O NÍVEL GRANULARIDADE DAS PRIMITIVAS UTILIZADAS...69 TABELA 6 BALANCEAMENTO ENTRE PROCESSOS E DIMENSÕES TABELA 7 PROCESSOS COM DIMENSÕES NÃO FOLHA 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

11 11

12 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

13 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

14 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

15 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

16 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 Why How Who Where When A tabela 1 explica as várias dimensões da framework de Zachman e como se relacionam com o negócio. Dimensão What How Focos Dados Função Who Pessoas When Tempo Why Where Motivação Network Propósito Os dados da organização e como são utilizados. O processo de traduzir a missão da organização para negócios. 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. A forma como os artefactos da organização se relacionam e evoluem ao longo do tempo. A tradução dos goals para acções e objectivos 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

17 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

18 (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

19 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

20 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

21 21

22 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 * * * Objectivo 1 Tempo 1 * * 1 * * ** * Actor * 1 Processo Entidade Informacional 1 * * * * * * Localização 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

23 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 Primitivas 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 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) 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 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

24 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 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 subobjectivos 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 Relações entre as primitivas e dimensões Cada 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 Entidade Informacional Localização Processo de negócio Actor Objectivo Tempo Dimensão What Where How Who Why When Tabela 2 Relações entre primitivas e dimensões 24

25 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

26 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) Representação dos Processos 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

27 Processo 1 Processo 1-1 Processo 1-2 Processo 1-3 Processo Processo Imagem 3 Representação dos processos 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 Processo 1-1 Actor 1 Unidade Organizacional X Processo 1-2 Actor 2 Entidade Informacional 1 Unidade Organizacional Y Imagem 4 Representação de um processo com dimensões 27 Entidade Informacional 2

28 3.2.2.Representação dos Actores, Entidades Informacionais, Objectivos, Tempos e Localizações Representação hierárquica das dimensões O 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 Representação das dimensões As 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. Actor 1 Unidade Organizacional X Entidade Informacional 1 Entidade Informacional 3 Processo 1-1 Processo 2 Imagem 5 Representação de um actor 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

29 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

30 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 Regras Tipo 1 São emitidos avisos para os seguintes casos: 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

31 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 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 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 Processos sem outputs Por 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

32 Processos sem inputs Na 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 Processos sem objectivos Processos 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 Processos sem tempos Processos 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 Processos sem actores O 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 Processos sem localizações Um 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 Processos de negócio equivalentes Processos 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

33 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 Regras Tipo 2 São considerados erros os seguintes casos: 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 Processo1 Processo1-1 Entidade 1-1 Processo1-2 Entidade 1-2 Imagem 7 Processo pai com dimensão menos genérica 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

34 Processo1 Entidade 1 Entidade 1-2 Entidade 1-1 Imagem 8 Balanceamento das dimensões usadas 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. Processo1 Entidade 1 Processo1-1 Processo1-2 Entidade 1-1 Entidade 1-2 Imagem 9 Balanceamento nos níveis hierárquicos 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

35 Processo1 Entidade 1 Processo1-1 Processo1-2 Entidade 1-2 Entidade 1-1 Imagem 10 Decomposição de um processo 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 subprocessos, 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 Processo1-1 Processo1-2 Actor X 35 Actor Y

36 36

37 4.Validação do trabalho A 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

38 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). Enterprise Model Conceptual Role: Owner What -Conceptual Data Model -Process Hierarchy How -Functional Hierarchy or -IDEF0 Diagrams -BPMN Diagram or -Process Chart or -IEDF3 Process Flow or -UML Activity Diagram -Process Decomposition -Relationship Map Where -Business Concept Diagram -Organization Chart and Who -Decision Chart and -BPMN Diagram (swinlanes) or -Process Chart (swinlanes) or -IDEF3 Process Flow (swinlanes) or -UML Activity Diagram (swinlanes) When -Process Events (Definition) -Process Results (Definition) -IDEF3 Object State Transition Why -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 Activity Action State Org Unit Auto-Decomposition AV-01 High Level Operational Concept Functions Org Unit Org. Unit AV-02 Integraded Dictionary Business Architecture Locatio ns Business Concept 38 When Why Goals

39 Business Process (BPMN) Data Object / Messag e flow Business Process Hierarchy Data Flow Gane & Sarson Data Flow Ward & Mellor Pool Lane X Data Store Data Store Data transfor m X Objects Process External Decision Chart Decomposition Entity Org Unit Inputs EBP Org. Function Function Activity IDEF3 Object State transition Estados IDEF3 Process Flow UOB Estado s Transiç ões Lane Organization Chart Locatio ns Assets OV-02 Op. Node Connectivity OV-03 Information exchange Matrix Activities Informati on Flow Activities Org Unit OV-05 Activity Model OV-06a Op Rules Model Activities Unit of Behaviour OV-06b Op State Transition State Event OV-06c Operation Event/Trace (Interacções / mensagens entre operational nodes) Op Node Entities Process Chart Process Process Decomposition Process Hierarchy Org Unit Organizati on Op. Node Op. Elements OV-04 Org. Chart OV-07 Logical Data Model (IDEF1x) Object ive Org. Unit Functional Hierarchy OV-01 Highlevel Op. Concept Event Unit Function Org. Function Enterprise Direction (Relacionado com a perspectiva planner) IDEF0 Pool Lane Process Collaboration Conceptual Data Model Process Process Object Process Map Event Result Org Unit Event Result EBP DLP Process Function Process Thread Relationship Map Org Unit / Lane Org. Unit Stakeholder Relationships State State State Transition State State Transition Ward & Mellor State Stakehold er BSC Objecti ve Org Unit Strategy Map (For organization Unit) UML Activity Diagram Activity 39 Lane

40 Use Case Use Case Sequence Actor X X Service Reference Model SV-05 System Function to Op. Activities (Relevante?) Material s 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 Zachman Enterprise 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

41 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

42 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 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

43 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 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

44 Imagem 13 Organization Chart 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

45 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 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

46 Imagem 15 Diagrama de Informação 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) 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

47 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

48 4.5.Implementação 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 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

49 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 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

50 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 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

51 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

52 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) Regras Esta 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

53 Imagem 19 Processos folha com 2 ou mais dimensões do mesmo tipo 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 subprocessos 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

54 Imagem 20 Localizações folha sem actores 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 Processos equivalentes A categoria Processos equivalentes implementa a regra Processo de negócio equivalentes. 54

55 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 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

56 Pesquisa Foi 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

57 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) 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

58 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

59 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

60 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

61 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 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 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

62 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 Contexto Inatel Digital Na 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

63 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. ( com base no Mapa Detalhado de Viagens existente,é efectuada a actualização das datas do Programa em causa ) EXCEL EXCEL Mapa Detalhado das Viagens antigo (no referido mapa são actualizadas as várias Unidades Hoteleiras que vão trabalhar no Programa em causa e respectivas datas dos Grupos) Mapa Detalhado das Viagens actualizado 1 V ez p/p rogra m a ( 1 por Fas e no TS ) Actualizar as Datas dos Grupos no Mapa Detalhado das Viagens Actualizar as Unidades Hoteleiras no Mapa Detalhado das Viagens EXCEL Quadro Grupos Delegações EXCEL (com base no Grupos Delegações,é efectuada a distribuição dos Grupos. Tentando que os Grupos por Delegação não tenham muitas datas coincidentes ) Mapa Detalhado das Viagens actualizado Actualizar as Unidades Hoteleiras no Mapa Detalhado das Viagens DTS Equipa de PROGRAMAÇÃO Mapa Detalhado de Viagens EXCEL Mapa Detalhado das Viagens actualizado EXCEL Mapa Detalhado das Viagens Coordenação da Programação EXCEL Mapa Detalhado das Viagens actualizado (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) Submeter a Autorização Superior o Mapa Detalhado de Viagens Não Efectuar Alterações Indicadas Superiormente Mapa Detalhado aprovado? Sim Coordenação da Programação Coordenação da Programação Mapa Detalhado de Viagens Final e Base de Trabalho para o Quadro de Viagens Chefia de Divisão EXCEL Quadro de Viagens Imagem 26 Visio criado por funcionários do Inatel 63 EXCEL Mapa Detalhado das Viagens para aprovação superior Coordenação da Programação Enviar para Aprovação

64 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 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

65 * * * 1 Tempo Objectivo 1 * ** 1 1 Sistema * * * * * * * 1 * Actor Processo Entidade Informacional 1 * * * * * * Localização 1 Input * * Output * 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 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

66 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

67 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

68 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

69 5.4.Regras 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: Recepção da Aprovação Seleccionar tipo de Contrato (To Be) Dimensões a substituir: Subir Nível para: Relatório Animadores Aprovado Contrato em Quantidade (To Be) Contrato em Valor (To Be) Relatórios Animadores Contrato (To Be) Tabela 5 Subir o nível granularidade das primitivas utilizadas 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 Contratação de Guias Elaborar Conteúdos da Brochura Aderir Programa Sénior Dimensões Analisar e Avaliar desempenho dos Animadores Analisar Necessidade de Contratar Animadores 69 Viagem Brochura Célia Tapadas Equipa de Programação Equipa de Operações Coordenação de Animadores

70 Equipa de Operações Apresentar aos Animadores as Unidades Hoteleiras e Prestadores de Serviços Calendarizar Programas Directores Clínicos Distribuir Brochuras nos Pontos de Venda Elaborar e Enviar Contratos Elaborar Horários de Viagens Elaborar Quadro de Viagens Enviar Material Gráfico Gestão das Agências de Viagens já Existentes nos Programas Seniores Proposta Governamental Receber Propostas dos Fornecedores Receber Textos e Fotos para Concurso e Apurar Premiados Verificar a necessidade de Material para as Unidades Hoteleiras Coordenação de Animadores Equipa de Programação Coordenação da Programação C. Moura Equipa de Programação Divisão Turismo Sénior Ana Trindade Equipa de Operações Equipa de Programação Equipa de Programação Equipa de Programação Célia Tapadas Equipa de Programação Chefia DTS Coordenação da Programação Equipa de Programação Directora do Departamento Equipa de Programação Propostas Fornecedores Propostas Fornecedores Equipa de Programação Divisão Turismo Sénior Quadro com distribuição das Viagens para Unidades Hoteleiras Tabela 6 Balanceamento entre Processos e Dimensões 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

71 Processos Dimensões Não Folha Acompanhar os Trabalhos de Embalamento/Etiquetagem Divisão Turismo Sénior Acompanhar os Trabalhos de Entrega dos CTT nos Pontos de Venda Divisão Turismo Sénior SAP (To Be) Associar Hotéis e Tipos de Quartos (To Be) Associar Partidas (To Be) SAP (To Be) Informação das Operações referente à realização dos Grupos Conferir os Serviços e Valores Prestados Criação da solicitação de cotação (To Be) SAP (To Be) Contrato (To Be) Relatórios Animadores Divisão Turismo Sénior Relatórios Animadores Criar registo específico Elaborar Quadro dos Passeios Envio de Material Leitura do Relatório Final Necessidade de Material para as Unidades Hoteleiras Divisão Turismo Sénior Relatórios Animadores SAP (To Be) SAP (To Be) Relatórios Animadores Contrato (To Be) Recepção de Questionários e Relatórios Registar factura (To Be) Registo de Pedido de Compra (To Be) Relatório Semanal Seleccionar tipo de 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 Processos equivalentes detectados Processos Equivalentes Com Passagem Aérea Conferir Horários Dimensões Célia Tapadas C. Maximino C. Moura Equipa de Programação Histórico Brochuras Horários Transportadora Aérea Michelin Quadro Viagens Quadro de Viagens com Horários Indicados Analisar Necessidades de Contratação de Guias Profissionais Contactar os Guias Profissionais Equipa de Operações Albertina Martins Ana Ditza CVs Processo 71

72 Informar Agência Viagem Actualizar Quadro de Agências Célia Tapadas Equipa de Programação Quadro de Agências Ordenar Informação do Quadro de Viagens Por Origem, Unidade Hoteleira e Data Ordenar Informação do Quadro de Viagens por Áreas de Destino Equipa de Programação Mapa Viagens Conferido Mapa Viagens Ordenado Informar Coordenação de Animadores Reajustar Programa Coordenação de Animadores Equipa de Programação Equipa de Programação Quadro Passeios Turísticos Final Contactar os Directores Clínicos Receber Confirmações dos Directores Clínicos Enviar Confirmações para a Contabilidade C. Moura Equipa de Programação Quadro Datas Palestras Enviar Contrato Receber Contrato Reenviar Contrato Ana Trindade Equipa de Operações Contrato Relatório Semanal Leitura do Relatório Final Coordenação de Animadores 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

73 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 Actualizar Quadro de Agências Célia Tapadas 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 Acompanhar os Trabalhos de Embalamento/Etiquetagem 73 Dimensões Divisão Turismo Sénior

74 Acompanhar Preparação dos Trabalhos de Entrega dos CTT Lista Agências Contactar RH Contratação de Guias Confirmação das Actividades Com Prestadores de Serviços Equipa de Operações Gestor de Viagens (To Be) Criação 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) Criar um Artigo Viagem de raíz (To Be) Artigo Viagem (To Be) Efectuar Alterações Indicadas Superiormente Equipa de Programação Documento com Indicações Efectuar Alterações Indicadas Superiormente Q. Proposta CFérias Planificar Viagens Directores Clinicos Divisão Turismo Sénior Alterar Reserva Receber Pedido de autorização Superior para Gozar Prémio noutro Período Pedido das novas Datas ao Centro de Férias Equipa de Programação Processo de Reserva Enviar Proposta de Reservas para os Administradores dos Respectivos C. Férias Informação das Delegações Recepção da Informação das Delegações Desactivar Agência de Viagens Equipa de Programação Célia Tapadas Registo de Contrato (To Be) Criar registo específico Contrato (To Be) Determinar Horários de Viagens Analisar Quantidade de Viagens por Delegação Reservar Grupos nos Centros de Férias Elaborar Mapa Detalhado das Viagens Reenviar à Delegação em Falta Equipa de Programação Retirar Agência de Viagens da Brochura Devolução de Correio Equipa de Programação C. Moura Célia Tapadas Visita e Apresentação dos Animadores à Administração das Unidades Hoteleiras Conhecimento dos Vários Prestadores de Serviços Coordenação de Animadores 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

75 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 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 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 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 DTS Com Passagem Aérea Célia Tapadas C. Maximino C. Moura Conferir Horários Célia Tapadas C. Maximino C. Moura Contactar os Guias Profissionais Albertina Martins Ana Ditza Decisão de Anulação de Viagens Chefia DTS Equipa de Operações Definir Programa Diário dos Grupos Coordenação de Animadores Equipa de Programação Determinar Quantidades dos Vários Material Gráficos Equipa de Programação Equipa de Promoção Vendas Devolução de Correio C. Moura 75

76 Célia Tapadas Elaborar Inf. para Autorização Superior da Contratação dos Serviços de D. C. Chefia DTS C. Moura Directora do Departamento Elaborar Informação Minuta de Oficio para remeter Proposta para o Ministério Chefia DTS Coordenação da Programação Directora do Departamento Elaborar Informação para enviar Proposta à Exma. Direcção Chefia DTS Coordenação da Programação Directora do Departamento Elaborar Minuta de Oficio para remeter Proposta para o Ministério Chefia DTS Coordenação da Programação Directora do Departamento Elaborar Orçamento Chefia DTS Coordenação da Programação Directora do Departamento Elaborar Proposta Chefia DTS Coordenação da Programação Directora do Departamento Elaborar Proposta da Distribuição dos Grupos por Delegação Chefia DTS Coordenação da Programação Elaborar Proposta para Reserva de Grupos nos Centros de Férias Chefia DTS Coordenação da Programação Enviar Ficheiros Informáticos da Minuta e Restantes Peça para o Ministério Chefia DTS Coordenação da Programação Directora do Departamento Enviar Proposta de Passeios Turísticos Para Análise e Parecer Coordenação de Animadores Equipa de Programação Enviar Requisição à Consideração Superior Chefia DTS Coordenação da Programação Envio de Informação para Boletim Informativo Chefia DTS Isabel Saboia Colaboradores da DTS Formalizar Contratação dos Guias Profissionais Albertina Martins Ana Ditza Informar Coordenação de Animadores Coordenação de Animadores Equipa de Programação Informar Premiados do Respectivo Prémio Chefia DTS Equipa de Programação Inserir Horários no Sistema Célia Tapadas Isabel Saboia Numerar Requisição Equipa de Programação Apoio Serviços Jurídicos Planear Formação Coordenação de Animadores Divisão de Pessoal Chefia DTS Preparar Contrato Coordenação de Animadores Chefia DTS Ana Trindade Reajustar Programa Coordenação de Animadores Equipa de Programação 76

77 Receber Provas da Brochura enviadas pela Gráfica Chefia DTS Equipa de Programação Directora do Departamento Receber Questionários Equipa de Programação Equipa de Operações Receber Relatório Do Guia Profissional Equipa de Programação Equipa de Operações Colaboradores da DTS Albertina Martins Retirar Agência de Viagens da Brochura C. Moura Célia Tapadas Sem Passagem Aerea Célia Tapadas C. Maximino C. Moura Sistematizar Informação Chefia DTS Equipa de Programação Equipa de Operações Validar Prova Final da Brochura Chefia DTS Equipa de Programação Directora do Departamento Verificar e Enviar os Processos Cartas-Convite Para os Vários Fornecedores Chefia DTS Apoio Serviços Jurídicos Verificar Provas dos Materiais Gráficos Equipa de Programação Equipa de Promoção Vendas Actualizar Conteúdo da Brochura Célia Tapadas C. Maximino C. Moura Actualizar no Sistema Informático Célia Tapadas Isabel Saboia Alterar Horários e/ou Datas de Voos ou de Viagem (na 1ª semana) Célia Tapadas C. Maximino C. Moura Analisar Calendário Chefia DTS Coordenação da Programação Directora do Departamento Analisar Necessidades de Contratação de Guias Profissionais Albertina Martins Ana Ditza Receber Aprovação D.C. Equipa de Programação Contabilidade 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 semana Por Prestador de Serviço Elaborar Requisição para Serviços de Hotelaria 1 Vez p/ Programa 1 p/ Fase no TS Entregar Brochura à Empresa Gráfica 2 Vezes p/ Programa 1 p/ Fase no TS 3 Vezes p/ Programa Enviar Calendário para Elaboração da Brochura e Campanha Publicitária do Prog. 1 Vez p/ Programa 1 p/ Fase no TS 77

78 Enviar Informação os Animadores Início do Programa Mudança Animador Actualizar Conteúdo da Brochura 1 Vez p/ Programa 1 p/ Fase no TS Alterar Reserva 1 vez p/ ano 2 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

79 6.Conclusões Os 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

80 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 atingidos O 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

81 8.Trabalho futuro Da 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

82 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, (página 4). (Rittgen 2006) Rittgen, Peter. Enterprise Modeling and Computing with UML, IDEA GROUP Publishing, (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, (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, (Macedo 2005) Macedo, Patricia & Tribolet, José. Análise de Conformidade de Modelos Organizacional com a Norma ISO Concepts and Rules for Organizational Models, 6ª Conferência da Associação Portuguesa de Sistemas de Informação, Oct

83 (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, (Locke) Locke, Stan. Zachman Classification, Implementation & Methodology. Zachman Frameowork Associates, (Zachman, 2007) Zachman, J., Zachman on the Framework, Zachman Internacional Inc, (Sousa, 2003) Sousa, Pedro & Pereira, Carla. Getting into the misalignment between Business and Information Systems, 10th European Conference On Information Technology Evaluation, (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,

84 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 FaltaActor.wmf Sistema.wmf Actor.wmf FaltaLoc.wmf Tempo.bmp EntInf.bmp NaoUsado.wmf Tempo.wmf EntInf.wmf Sistema.bmp 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ócio A 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

85 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 Actor Entidade Informacional Objectivo Localização Tempo Sistema Diagrama Diagrama de Actores Diagrama Informação Enterprise Direction Organization Chart Diagrama Tempo Diagrama Sistemas Tabela 11 Objectos e respectivos diagramas 1.4.Representação visual das dimensões e dos processos Processo Nos 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 Actor Os actores são representados pela Imagem 33, tanto nos diagramas do tipo Actor como na interface RMD. 85

86 Imagem 33 Representação dos actores Localização Os 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 Objectivo Os 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 Tempo A dimensão tempo é representada pela Imagem 36 nos diagramas do tipo Tempo e na interface RMD. Imagem 36 Representação dos tempos Entidade Informacional As entidades informacionais são representadas pela Imagem 37 nos diagramas de informação nos diagramas do tipo BPMN e na interface RMD. 86

87 Imagem 37 Representação das entidades informacionais Tipo Input Quando 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 Tipo Output Quando 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 Sistema Os 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

88 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