Suporte à Gestão da Mudança usando Arquitecturas ...€¦ · Suporte à Gestão da Mudança...
96
unce Suporte à Gestão da Mudança usando Arquitecturas Empresariais Rodrigo de Barros Horta Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Professor Doutor José Carlos Martins Delgado Orientador: Professor Doutor José Manuel Nunes Salvador Tribolet Co-Orientador: Professor Doutor Pedro Manuel Moreira Vaz Antunes de Sousa Vogal: Professor Doutor Artur Miguel Pereira Alves Caetano Novembro de 2009
Transcript of Suporte à Gestão da Mudança usando Arquitecturas ...€¦ · Suporte à Gestão da Mudança...
unce
Suporte à Gestão da Mudança usando Arquitecturas
Empresariais
Rodrigo de Barros Horta
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Júri
Presidente: Professor Doutor José Carlos Martins Delgado
Orientador: Professor Doutor José Manuel Nunes Salvador Tribolet
Co-Orientador: Professor Doutor Pedro Manuel Moreira Vaz Antunes de Sousa
Vogal: Professor Doutor Artur Miguel Pereira Alves Caetano
Novembro de 2009
i
Índice
Índice ..................................................................................................................................................... i
Índice de Figuras ................................................................................................................................. iv
Índice de Tabelas ................................................................................................................................ vi
1. Resumo ...................................................................................................................................... 1
2. Abstract. ...................................................................................................................................... 2
3. Introdução ................................................................................................................................... 3
4. Objectivos do Trabalho ............................................................................................................... 4
5. Trabalho Relacionado ................................................................................................................ 5
5.1 Gestão da Mudança ............................................................................................................ 5
5.1.1 Vantagens ....................................................................................................................... 6
5.1.2 Modelos de Gestão de Mudança .................................................................................... 6
5.1.3 Self-Awareness............................................................................................................... 8
5.2 Modelação ........................................................................................................................... 9
5.2.1 Modelação Organizacional ........................................................................................... 10
5.2.2 Frameworks .................................................................................................................. 12
5.2.3 Mudança num ambiente modelado .............................................................................. 20
5.2.4 Blueprints ...................................................................................................................... 22
5.2.5 Problemas de Actualização .......................................................................................... 23
6. Arquitectura da solução ............................................................................................................ 26
6.1 Contexto ............................................................................................................................ 26
6.2 Assumpções ...................................................................................................................... 27
6.3 Casos de Uso .................................................................................................................... 27
6.3.1 Pedido de Validação da Mudança ................................................................................ 27
ii
6.3.2 Pedido de Actualização do Meta-Modelo ..................................................................... 28
6.3.3 Pedido de Actualização da realidade da Organização................................................. 29
6.4 Processo Geral de Suporte à Gestão da Mudança .......................................................... 30
6.5 Descrição do Processo Geral de Suporte à Gestão da Mudança .................................... 31
6.5.1 Processo Geral de Suporte à Gestão da Mudança ...................................................... 31
6.5.2 Actualização do meta-modelo ...................................................................................... 33
6.5.3 Validar Acções Propostas ............................................................................................ 35
6.5.4 Descrição dos Roles ..................................................................................................... 36
6.6 Vantagens ......................................................................................................................... 42
7. Implementação ......................................................................................................................... 42
7.1 Protótipo ............................................................................................................................ 43
7.1.1 Requisitos ..................................................................................................................... 43
7.1.2 Arquitectura Lógica do Protótipo .................................................................................. 44
7.1.3 Cenário SHOULD_BE .................................................................................................. 46
7.1.4 Interface Gráfica ........................................................................................................... 48
7.2 Vistas de Gestão da Mudança .......................................................................................... 50
7.2.1 Overall View .................................................................................................................. 51
7.2.2 Specific Element View .................................................................................................. 52
8. Validação da Solução ............................................................................................................... 54
8.1 Contextualização ............................................................................................................... 54
8.2 Método utilizado na validação ........................................................................................... 55
8.2.1 Casos de teste fictícios ................................................................................................. 55
8.2.2 Caso real ...................................................................................................................... 60
8.2.3 Conclusões ................................................................................................................... 67
9. Conclusões ............................................................................................................................... 68
iii
9.1 Trabalho Futuro ................................................................................................................. 69
10. Referências............................................................................................................................... 70
11. Anexos ...................................................................................................................................... 73
11.1 Anexo 1: Processo de validação (Ciclo Geral) .................................................................. 73
11.2 Anexo 2: Processo de validação (Excepção não é possível representar a mudança) ..... 74
11.3 Anexo 3: Validação (Excepção cenário AS_IS não representa à realidade) .................... 75
11.4 Anexo 4: Actualização do meta-modelo ............................................................................ 76
11.5 Anexo 5: Gap Analysis ...................................................................................................... 77
11.6 Anexo 6: Processo de validação da mudança .................................................................. 78
11.7 Anexo 7: Documento detalhado da regra de solução ....................................................... 79
11.8 Anexo 8: Template utilizado para importação de cenário SHOULD_BE .......................... 81
11.9 Anexo 9: Exemplo Overall View ........................................................................................ 83
11.10 Anexo 10: Exemplos Specific View ................................................................................... 84
11.11 Anexo 11: Casos de teste fictícios .................................................................................... 86
11.12 Anexo 12 : Verificar existência de solução ....................................................................... 88
iv
Índice de Figuras
Figura 1 - Passos do modelo de Kotter ............................................................................................... 7
Figura 2 - Arquitectura Empresarial ................................................................................................... 11
Figura 3 - Framework de Zachman [29]............................................................................................. 13
Figura 4 - Ciclo ADC proposto pela framework TOGAF .................................................................... 14
Figura 5 - Esfera de acção da Gestão da Mudança [5] ..................................................................... 18
Figura 6 - Processo de Gestão da Mudança [23] .............................................................................. 19
Figura 7 - Mudança num ambiente modelado [24] ............................................................................ 20
Figura 8 - Cenário AS_IS e TO_BE ................................................................................................... 21
Figura 9 - Exemplos de Blueprints ..................................................................................................... 23
Figura 10 - Actualização Dinâmica do Meta-modelo [27] .................................................................. 24
Figura 11 - Pedido de Validação de uma Mudança ........................................................................... 27
Figura 12 - Pedido de actualização do meta-modelo ........................................................................ 28
Figura 13 - Pedido de actualização da realidade da organização ..................................................... 29
Figura 14 - Caminho normal do Processo Geral ............................................................................... 31
Figura 15 - Role Avaliador “Verificar existência de solução” ............................................................. 37
Figura 16 - Role Criador “Verificar existência de solução” ................................................................ 38
Figura 17 - Role Coordenador “Verificar existência de solução” ....................................................... 39
Figura 18 - Role Avaliador “Actualização Meta-modelo” ................................................................... 40
Figura 19 - Role Criador “Actualização Meta-modelo” ...................................................................... 40
Figura 20 - Role Coordenador “Actualização Meta-modelo” ............................................................. 41
Figura 21 - Arquitectura Conceptual do Protótipo ............................................................................ 44
Figura 22 - Camada de Apresentação ............................................................................................... 44
Figura 23 - Camada de Negócio ........................................................................................................ 45
Figura 24 – Exemplo de artefacto com informação SHOULD_BE .................................................... 47
v
Figura 25 - Ecrã principal do validador de alterações ....................................................................... 48
Figura 26 - Ecrã de selecção do tipo de organização dos resultados finais ..................................... 49
Figura 27 - Change Management Blueprints ..................................................................................... 50
Figura 28 - Overall Blueprint .............................................................................................................. 51
Figura 29 - Specific Element Blueprint............................................................................................... 52
Figura 30 - Resultado final após validação ........................................................................................ 54
Figura 31 – Acções não validadas na criação de uma aplicação e alteração de outra .................... 57
Figura 32 - Specific View App X ........................................................................................................ 58
Figura 33 - Specific View App Y ........................................................................................................ 58
Figura 34 - Acção criar validada na criação de uma aplicação e alteração de outra ........................ 59
Figura 35 - Acções validadas na criação de uma aplicação e alteração de outra ............................ 59
Figura 36 Acções validadas na criação de uma aplicação ................................................................ 60
Figura 37 - Acções efectuadas sobre os artefactos ......................................................................... 61
Figura 38 - Ligações entre os diferentes artefactos .......................................................................... 61
Figura 39 - Tipo dos artefactos .......................................................................................................... 62
Figura 40 - As acções criar relativa aos componentes são validadas, o resto não é: Overall View . 63
Figura 41 - Specific View App BESnet Negócios .............................................................................. 64
Figura 42 - Acções quase validadas: Overall View ........................................................................... 65
Figura 43 - Ciclo Geral de Validação ................................................................................................. 73
Figura 44 - Excepção (caso não seja possível representar a mudança) .......................................... 74
Figura 45 - Excepção (caso o cenário AS_IS não esteja alinhado com a realidade) ....................... 75
Figura 46 - Processo de Actualização do meta-modelo .................................................................... 76
Figura 47 - Gap Analysis ................................................................................................................... 77
Figura 48 - Processo de validação da mudança ............................................................................... 78
Figura 49 - Exemplo de cenário SHOULD_BE .................................................................................. 82
vi
Figura 50 - Exemplo Overall View ..................................................................................................... 83
Figura 52 - Exemplo de uma acção não validada ............................................................................. 84
Figura 51 - Exemplo Overall View ..................................................................................................... 84
Figura 53 - Exemplo de uma acção validada .................................................................................... 85
Figura 54 - Caso de teste: Criar uma aplicação ................................................................................ 86
Figura 55 - Caso de teste: Criar uma aplicação e modificar outra .................................................... 87
Figura 56 - Processo de verificação de existência de solução .......................................................... 88
Índice de Tabelas
Tabela 1 - Vantagens e Desvantagens do processo de Gestão de Mudança do ITIL ...................... 17
Tabela 2 - Formas de Inserção .......................................................................................................... 47
Tabela 3 - Tipos de Output ................................................................................................................ 50
Tabela 4 - Acções associadas ao caso de teste relativo à criação de uma aplicação ...................... 56
Tabela 5 - Acções associadas ao caso de teste relativo à criação de duas aplicações ................... 56
Tabela 6 - Acções associadas ao caso real ...................................................................................... 62
Tabela 7 - Informação que compõe o documento detalhado ............................................................ 79
Tabela 8- Template SHOULD_BE ..................................................................................................... 81
1
1. Resumo
No mundo empresarial, os gestores têm de tomar diversas decisões que permitirão à empresa
adaptar-se à realidade actual, tornando-a mais produtiva e criando mais activos financeiros
permitindo assim atingir os seus objectivos e completando a sua missão. Estas alterações têm de ser
geridas evitando afectar negativamente a empresa durante o período de transição. Assim este
trabalho foca-se na gestão da mudança efectuada sobre uma organização modelada, sobre os
passos que esta precisa de executar para garantir que o que muda de uma forma correcta permitindo
à empresa atingir um estado adaptado às necessidades que esta tem, um estado visionado pelo
gestor.
O trabalho aqui descrito pode ser visto como uma aplicação prática de um dos problemas mais
conhecidos desta temática, a validação da mudança proposta. Para resolver esta questão é
apresentado um processo que a empresa deverá implementar de forma a permitir a sua adaptação a
novos cenários.
Começámos por avaliar diversas arquitecturas empresariais e diversas formas de representar a
organização. De seguida estudámos diversos modelos de gestão de mudança, sendo o mais
importante o processo de gestão de mudança proposto pelo ITIL.
Palavras-chave: Arquitectura Empresarial, Gestão de Mudança, Modelos, Processo
2
2. Abstract.
In the business world, managers have to make decisions which will allow their organization to
adapt to today’s reality, making it more productive, creating more financial actives, allowing it in the
end to complete their objectives and their mission. Although these changes need to be managed in
order to avoid the ill effect on the company during the transition period. This work focus in the change
management executed over the company, namely over the IT department, over the steps it need to
execute to ensure that what changes, changes in a way that is correct and healthy to the company
allowing it to achieve a state adapted to its needs, the vision of the manager. This work creates a
process which outcome provides an easy and simple way of doing the above, making it possible for
the organization to adapt to new scenarios.
Keywords: Organizational Architectures, Change Management, Scenarios, Process
3
3. Introdução
Num mundo cada vez mais competitivo, é fundamental para uma empresa manter a sua
vantagem competitiva ou, caso não a tenha, tentar obtê-la da forma mais expedita possível. Os
gestores hoje em dia, já não se podem dar ao luxo de gerir apenas o que já existe sem ter em conta a
constante alteração que ocorre na sociedade actual, correndo o risco de a empresa perder a iniciativa
e a sua quota de mercado. [1]
“A Manager is the person responsible for planning and directing the work of a group of individuals,
monitoring their work, and taking corrective action when necessary.” [2]
Estando ciente desta realidade, um gestor tem de ter um espírito visionário e corajoso, de forma a
antecipar as alterações necessárias que permitam alterar a empresa de forma a mantê-la competitiva.
Contudo estas alterações têm de ser bem pensadas, analisadas e planeadas, correndo o risco de não
terem o efeito pretendido e afectarem gravemente o normal funcionamento da empresa caso o
processo não seja conduzido de uma forma eficaz e madura. Para isso este tem de ter uma
percepção elevada do ambiente que o rodeia e especialmente da organização a que pertence. Assim,
para que este problema seja resolvido, entra em jogo a Gestão de Mudança, que define um conjunto
de passos, nomeadamente de acções e validações, para garantir que o planeamento das alterações
é correcto e permite atingir os objectivos pretendidos, garantindo posteriormente uma implementação
dessas alterações com pouco impacto para a empresa, aumentando consequentemente a percepção
do indivíduo acerca da organização a que pertence.
A pesquisa efectuada sobre este tema revelou que os gestores hoje em dia, já não podem ignorar
a importância de uma gestão de mudança cuidada devido à vantagem empresarial que este processo
pode oferecer a uma empresa.
“After experiencing lots of failures with change efforts, organizations are catching on. Change
management has gone from a non-existent or oft-ignored topic to an integral part of project planning.” [3]
4
4. Objectivos do Trabalho
O trabalho desenvolvido almeja atingir diversos objectivos. O primeiro prende-se com o
aumento do nível de compreensão sobre o processo de mudança de uma organização. Como é
executado este processo? Como são validadas as mudanças planeadas pelo gestor? Que passos
é necessário executar para garantir que um conjunto de acções permite atingir o estado
pretendido?
O segundo objectivo corresponde ao desenvolvimento de um processo de validação das
mudanças planeadas, ajudando o gestor a compreendê-las e a compreender se estas permitem
atingir o futuro almejado, sendo para isso criada uma ferramenta de suporte à Gestão da Mudança
que permita executar essa validação no mundo real. Esta ferramenta e este processo têm também
como objectivo, obrigar a uma formalização das mudanças planeadas e a uma validação
automáticas das mesmas.
Através deste processo de validação, este trabalho pretende desenvolver uma forma de
aumentar de uma forma sustentada e correcta a percepção que os gestores têm do que os rodeia,
da organização, nomeadamente da área IT.
5
5. Trabalho Relacionado
5.1 Gestão da Mudança
“It is not necessary to change. Survival is not mandatory” [4]
A sociedade muda constantemente, as suas necessidades, a sua realidade, os seus princípios.
Tal como a sociedade uma empresa também tem de mudar, acompanhando este frenético
processo. Só assim consegue crescer, evoluir. Assim concluímos que esta mudança tem de ser
alvo de uma gestão cuidadosa, racional e correcta.
O rápido desenvolvimento da tecnologia IT e do mercado coloca este tema no pensamento do
gestor. A organização tem de melhorar os seus serviços e reduzir os seus custos, conseguindo
atingir este objectivo tendo como apoio as tecnologias de informação.
“However, experience shows that IT incidents affecting the business are often related to
changes.”
Existem inúmeros problemas que podem afectar a organização, afectando a sua produtividade
e o seu normal funcionamento, tais como:
Falta de cuidado na execução dos processos;
Falta de recursos;
Preparação insuficiente;
Análise de impacto deficiente;
Formas de teste inadequadas.
Se os problemas gerados pela execução da mudança não forem controlados podem fazer com
que a organização entre numa espiral descontrolada, levando a que o negócio seja afectado de
uma forma negativa e à introdução de novos erros que causarão novos incidentes. [5]
A Gestão de Mudança torna-se desta forma num processo prioritário para um gestor.
6
5.1.1 Vantagens
“Not every change is an improvement, but every improvement is a change.” [5]
A Gestão da Mudança tem como objectivo gerir o processo de mudança e consequentemente
limitar a introdução de erros e incidentes gerados por estes. Esta traz diversas vantagens, tais
como:
Impacto reduzido das mudanças na qualidade dos serviços de IT;
Melhor estimativas de custo das mudanças propostas;
Menos quantidade de alterações revertidas;
Melhoria da produtividade por parte dos utilizadores, devido a melhores e mais
estáveis serviços de IT, e devido ao facto de não serem distraídos do seu trabalho planeado
devido a alterações urgentes;
Melhoria da capacidade de efectuar mudanças regularmente sem afectar o
funcionamento da organização;
Elimina o conflito entre recursos e possível redundância;
Reduz os riscos associados à mudança. [21]
5.1.2 Modelos de Gestão de Mudança
A Mudança é como um caminho que temos de percorrer. Primeiro temos de perceber porque
queremos ir para esse destino, depois o percurso que queremos seguir, com quem e como o
queremos percorrer. [4]
Partindo desta analogia foram desenvolvidos diversos modelos para permitir uma gestão
cuidada da mudança sendo alguns descrito em baixo.
Six Change Approaches é um modelo criado por Kotter e Schlesinger que permite prevenir,
minimizar e diminuir a resistência contra a mudança numa organização. Para atingir esses objectivos
os autores propõem a utilização das seguintes abordagens:
7
1. Comunicação e Educação: "Up-front communication and education helps employees see the
logic in the change effort."
2. Envolvimento e Participação: "When employees are involved in the change effort they are
more likely to buy into change rather than resist it."
3. Suporte e Facilidade de adaptação: "Managerial support helps employees deal with fear and
anxiety during a transition period."
4. Acordo e Negociação: "Managers can combat resistance by offering incentives to employees
to not resist change."
5. Manipulação: "Co-option involves the patronizing gesture in brining a person into a change
management group for the sake of appearances rather than their substantive contribution."
6. Coerção explícita e implícita: "Managers can explicitly or implicitly force employees into
accepting change by making clear that resisting to change can lead to losing jobs, firing,
transferring or not promoting employees." [6] [7]
Kotter’s 8-Step Change Model é um proposto por John Kotter, propõe a execução de oito
passos distintos de forma a atingirmos a mudança de uma forma persistente e correcta. Os
passos são os seguintes: [8] [9]
Figura 1 - Passos do modelo de Kotter
8
Unfreeze-Move-Refreeze é um modelo proposto por Kurt Lewin (1951) que explica a mudança
nos sistemas. O modelo propõe que antes da mudança os sistemas se encontram “congelados”.
Assim a primeira tarefa será “descongelar o sistema” criando um ambiente em que o sistema não se
encontra preso a nenhuns princípios de funcionamento permitindo a inserção da mudança, este
passo denomina-se por Unfreeze.
O segundo passo introduz a mudança e tenta obter uma aceitação inicial dos intervenientes, este
passo denomina-se por Move. O terceiro e último passo, denominado Refreeze, volta a colocar o
sistema no estado inicial com a diferença de que as mudanças estão efectuadas. Neste estado será
necessário obter um estado de aceitação elevado que permita à empresa adoptar a mudança
completamente, evitado o falhanço desta. [10]
5.1.3 Self-Awareness
“Human beings are by nature, self-awareness beings.” [11]
Os indivíduos conhecem a sua realidade num dado momento no tempo, sabem o que estão a
fazer, em que situações o fazem e como o fazem. Esta é qualidade inerente ao ser humano. Contudo,
tal não acontece com as organizações o que torna necessário que esta aprenda a conhecer-se a si
própria para que as suas acções tenham como base um auto conhecimento profundo, permitindo que
todas as suas acções sejam conscientes e fundamentadas.
Aumentar a Organizational Self-Awareness (OSA) possibilita que as organizações aumentem a
sua capacidade de reacção à constante alteração do mercado e a da realidade em que se inserem.
Isto acontece sempre que todo o indivíduo pertencente à organização esteja consciente do trabalho
que tem de realizar e como esse a influencia. Acontece sempre que o indivíduo perceba como a
organização tem de funcionar, como está estruturada. Desta forma, a organização torna-se mais
flexível e maleável facilitando a adopção da mudança. Este processo depende fundamentalmente da
componente humana, o que torna a sua implementação expendiosa e complexa. [12] [13]
Na organização, este conceito, torna-se essencial para melhorar e optimizar os processos de
tomada de decisão, processos de aprendizagem, acção efectiva e concreta. Sendo necessário
mantê-lo e aumentá-lo através da contínua interacção entre os membros da organização e da sua
contínua submissão de ideias e propostas.
9
5.1.3.1 Duas dimensões
O conceito de Organizational Self-Awareness (OSA) é caracterizado por duas dimensões:
Individual;
Organizacional.
A dimensão individual refere para a capacidade que membros individuais têm de responder a
questões como: Quem sou eu na organização? Como é que as mudanças são efectuadas? Como é
que os processos são executados? O que é que a organização está a fazer neste momento?
A dimensão organizacional refere-se à combinação entre agentes humanos e automatizados,
entre recursos e procedimentos que permitem à organização obter a inteligência para lidar com
questões como: Quem são os meus membros? Como é que eles executam as suas acções? O que
estão a fazer neste momento?
Uma organização é auto-consciente quando estas duas dimensões estão alinhadas. [11] [12]
5.2 Modelação
“A model is a useful representation of some subject” [14]
Um modelo é uma abstracção (mais ou menos formal) da realidade, expressa através de um
formalismo (ou linguagem) de forma a facilitar a compreensão do utilizador.
“A model is always expressed in terms of a language” [14]
Esta linguagem pode ser mais ou menos formal. A mais formal, que serve para criar modelos,
normalmente serve para representar conceitos matemáticos e as menos formais (as mais ricas)
correspondem a linguagens naturais. Contudo, no meio, encontram-se aquelas que servem para
representar coisas ou a realidade, como por exemplo as linguagens simbólicas, gráficas ou de
diagramas. Estas últimas tomam uma importância fundamental na Gestão da Mudança, visto que só
a partir de uma representação formal da organização é possível encontrar uma forma de validar as
acções que se pretendem efectuar.
10
Modelar algo, consiste na representação gráfica de conceitos e da ligação que existe entre estes.
Esta representação permite simplificar algo complexo de forma a ser compreendido mais facilmente.
Existem várias razões que nos levam a modelar, tais como:
Facilita a comunicação;
Facilita a compreensão;
Aumenta a compreensão sobre dado problema;
Identifica áreas problemáticas.
Concluímos assim que as técnicas de modelação têm de oferecer uma forma de conseguir
representar toda a informação relevante necessário para executar uma Gestão de Mudança madura e
correcta.
5.2.1 Modelação Organizacional
“There is no way to change Enterprises or any other complex thing quickly (or safely) without
starting with the descriptive representation of the thing you want to change.” [15]
Visto uma organização ser por natureza algo muito complexo, é lógico que esta seja modelada de
forma a tornar a sua compreensão mais simples, facilitando a sua gestão, actualização e adaptação a
novas situações. Este modelo concentra-se principalmente nos objectivos da organização, nas
actividades dos seus componentes, sobre as responsabilidades dos indivíduos envolvidos, sobre a
forma como esta se organiza e sobre os elementos que a constituem.
“Organizational Modeling is the capture of a shared mental model of an organization of any type,
be it a large corporation, a small business or a work group.” [16]
Estes modelos agregam todo o conhecimento acerca de uma organização, desde os recursos
utilizados, aos produtos disponibilizados, até às formas como esta comunica e se interliga. Quando
completo, providencia uma visão global sobre a organização.
“An enterprise model is a type of extensive representation of a system, and is aimed at providing a
detailed and complete understanding of a business or organization.” [17]
11
Este processo cria projecções usadas no planeamento das tecnologias de informação (IT). Estas
retratam a forma como a tecnologia está a ser usada na organização, as formas como melhorar a
integração da área de IT, se e como a estrutura da organização suporta o uso das IT (por exemplo,
verificar se a compra de um novo sistema informático é compatível com os objectivos e necessidade
da empresa), a melhor forma de melhorar a estratégia de negócio. Permite perceber como os seus
sistemas podem ser refinados, permite melhorar técnicas de gestão e melhorar os processos
internos. [18]
"The fundamental organization of a system, embodied in its components, their relationships to
each other and the environment, and the principles governing its design and evolution." [19]
Assim, tal como [14] afirma, o processo de modelação organizacional é definido como:
“Enterprise modeling is a process of building models of whole or part of an enterprise, from
knowledge about the enterprise, previous models, and/or reference models as well as domain
ontologies and model representation languages”
Desta forma, um modelo organizacional corresponde a uma representação de uma percepção da
organização. Pode ser constituído por diversos sub-modelos, também chamados sub-arquitecturas,
tais como:
Figura 2 - Arquitectura Empresarial
12
5.2.2 Frameworks
Como vimos anteriormente, uma arquitectura empresarial é um factor essencial no sucesso de
uma empresa. Desta forma deve ser bem desenhada de forma a ajudar a empresa a atingir os seus
objectivos e não prejudicá-la.
As frameworks providenciam um esquema organizacional pelo qual o processo de
desenvolvimento da solução da arquitectura pode ser simplificado e a sua velocidade aumentada,
não comprometendo o crescimento e a adaptação da empresa às necessidades do mercado. Existem
diversos exemplos de frameworks relevantes para o assunto discutido, entre as quais encontram-se:
Zachman;
TOGAF;
ITIL.
5.2.2.1 Zachman
“The Zachman framework is simply a framework – it is not a process, a method, a notation or a tool.”
[20]
O conceito de examinar um sistema a várias ordens de magnitude foi apresentado por Boeke
(1957). Zachman levou este conceito mais a frente e apresentou uma framework normalizada com
um esquema de classificação definido por uma matriz 6x6, com o intuito de organizar descritivamente
as representações de uma empresa. As linhas desta matriz representam os diversos stakeholders do
sistema, enquanto as colunas representam as áreas de interesse dentro da perspectiva do
stakeholder.
13
5.2.2.2 TOGAF
“TOGAF is an architecture framework - The Open Group Architecture Framework. It enables you
to design, evaluate and build the right architecture for your organization.” [19]
A framework TOGAF propõe que uma arquitectura empresarial deve ser definida pelas seguintes
subunidades:
Arquitectura de Negócio – onde são definidos a estratégia de negócio, processos de
negócio organização;
Arquitectura de Informação – que define toda a lógica e gestão de informação da
empresa;
Arquitectura de Aplicações – define vistas sobre todas as relações e interacções das
aplicações (pertencentes à empresa) com os processos de negócio desta.
Arquitectura Tecnológica – define todo o software e hardware que a empresa necessita
para suportar todo o sistema da empresa (dados, negócio e aplicações).
Para aplicar esta framework temos de passar pela ADM (Architecture Development Method) cuja
estrutura é definida pelo ADC (Architecture Development Cycle). Este método é iterativo e é
necessário haver um processo de validação dos resultados com os requisitos iniciais da empresa.
[19]
Figura 3 - Framework de Zachman [29]
14
5.2.2.3 ITIL
O ITIL (IT Infrastructure Library) foi desenvolvido, reconhecendo o facto de que as empresas
dependem cada vez mais do IT, para cumprir os seus objectivos organizacionais. Este oferece uma
framework comum para todas as actividades do departamento de IT. Estas actividades estão
divididas em processos que quando juntos providenciam uma framework efectiva para tornar o IT
Service Management mais maduro. Cada um destes processos trabalha sobre uma ou mais tarefas
do departamento de IT, como desenvolvimento de serviços, gestão de infra-estruturas, fornecimento
e suporte de serviços e gestão da mudança. Desta forma torna-se possível descrever as melhores
práticas do IT Service Management independentemente da estrutura da organização. O ITIL está
dividido em seis conjuntos:
Figura 4 - Ciclo ADC proposto pela framework TOGAF
15
Service Support;
Service Delivery;
Planning to Implement Service Management;
ICT Infrastructure Management;
Applications Management;
Business Perspective. [21]
Existem diversos benefícios inerentes ao uso do ITIL relacionados com a organização:
Definição de uma estrutura mais clara, eficiente e focada nos objectivos da organização;
A organização tem mais controlo sobre a infra-estrutura e sobre os serviços tornando
assim a implementação de mudanças mais simples de gerir;
Uma estrutura efectiva de processos providencia uma framework para um outsourcing
efectivo de elementos dos serviços de IT;
Suporta a introdução de sistemas de gestão de qualidade baseados na ISO 9000 ou no
BS15000, permitindo assim uma mudança cultural no tema de prestação de serviços;
Providencia uma comunicação interna e com os fornecedores coerente e uma
identificação e standardização de procedimentos. [22]
Contudo existem também desvantagens inerentes ao uso do ITIL, tais como:
Demora muito tempo e precisa de demasiado esforço a introduzir necessitando de uma
mudança na cultura da organização;
Estruturas de processos demasiado objectivas podem afectar a qualidade do serviço e
podem ser vistas como burocracia (nomeadamente, os processos desnecessários ou
over-engineered);
Não existe melhoramento nos serviços de IT se não houver compreensão acerca do que
os processos relevantes deveriam resolver;
Uma implementação bem sucedida requer o envolvimento de todo o pessoal;
Se não houver investimento suficiente em aplicações de suporte e treino então os
processos não vão atingir o rendimento máximo e os serviços não vão ser melhorados.
[22]
16
5.2.2.3.1 Gestão de Mudança no ITIL
“The main goal of Change Management is for all the changes that need to be made to IT
infrastructure and services to be performed and implemented correctly by ensuring standard
procedures are followed.” [23]
O ITIL afirma que a Gestão de Mudança tem de trabalhar para garantir que as mudanças são:
Justificadas;
São executadas sem pôr em perigo a qualidade do serviço IT;
São gravadas, documentadas e classificadas;
Foram testadas num ambiente de teste;
São guardadas na Configuration Manager Database (CMDB);
Podem ser desfeitas através de planos de recuperação se as funções de sistema
funcionarem incorrectamente após implementação.
Mas o que é uma mudança?
“A change is the addition, modification or elimination of an authorized, planned or supporting
service (component) and its related documentation.” [5]
As vantagens e desvantagens deste processo estão descritas na tabela 1.
17
Vantagens Desvantagens
O número de potenciais incidentes e problemas
associados a cada mudança são reduzidos.
Os vários departamentos têm de aceitar a autoridade
da Gestão da Mudança sobre os assuntos relativos à
mudança.
Se a mudança tiver um impacto negativo na
estrutura IT, o processo de retornar a uma
configuração estável e segura é relativamente
simples e rápido.
As pessoas responsáveis pela Gestão da Mudança não
têm um conhecimento profundo da organização
tornando impossível que realizem as suas tarefas de
uma forma adequada.
O número de retrocessos necessários é reduzido. O departamento da gestão da mudança não têm as
ferramentas de software indicadas para monitorizar e
documentar o processo adequadamente.
Os custos associados a uma mudança são
avaliados tornando assim possível calcular o
retorno do investimento
Não existe o empenhamento necessário dos gestores
de topo para implementar os processos de uma forma
rigorosa.
CMDB é actualizado. Demasiados processos restritivos são adoptados não
permitindo a ocorrência natural de inovações.
As mudanças são mais facilmente aceites e a
tendência de resistência a esta é reduzida.
Demasiados processos restritivos são adoptados
tornando o processo de gestão de mudança trivial,
afectando a qualidade dos serviços.
Tabela 1 - Vantagens e Desvantagens do processo de Gestão de Mudança do ITIL
18
Tendo estes factores em conta, o ITIL procurou perceber que actividades, a Gestão de Mudança,
devia conter para que o processo de mudança fosse correcto e definiu a esfera de acção desta da
seguinte forma.
Desta forma é proposta uma solução para gerir a mudança dentro da componente IT da
organização, definida pelo processo de Gestão de Mudança. [5]
Figura 5 - Esfera de acção da Gestão da Mudança [5]
19
5.2.2.3.2 Processo de Gestão de Mudança
O objectivo do processo de Gestão de Mudança [5] é garantir que as mudanças são guardadas,
avaliadas, prioritizadas, planeadas, testadas e documentadas de uma forma controlada e universal à
organização.
Este processo é definido pelas seguintes actividades:
Criação e salvar o pedido de mudança (i.e. Request for Change - RFC);
Revisão do RFC;
Avaliar a mudança;
Autorizar a ocorrência da mudança;
Coordenar a implementação;
Avaliar o resultado.
Figura 6 - Processo de Gestão da Mudança [23]
20
Este processo torna-se fundamental numa organização que queira evoluir de forma sustentada.
Assim no contexto da gestão de mudança utilizando arquitecturas empresariais, o processo descrito
nesta secção dá uma ferramenta importante na execução e validação das mudanças dentro da área
IT. Contudo depende quase inteiramente na componente humana para ser executado, sendo este
factor uma desvantagem ao seu uso. [5]
5.2.3 Mudança num ambiente modelado
“Organizational change can be regarded as a process that changes the state of the organization”
[24]
Tal como foi descrito no capítulo 4.1, a mudança traduz-se na conversão de um estado A para um
estado B. Contudo, num ambiente modelado não podemos ser tão abstractos na nossa abordagem
ao problema. Assim, tal como proposto em [24] torna-se necessário introduzir dois novos conceitos:
Cenário;
Processo de Mudança.
Estes dois conceitos são de grande importância para a gestão da mudança, visto fornecerem
ferramentas que permitem observar a organização num dado estado (por exemplo: em t1 = Hoje, e t2
= Amanhã) e permitem também, através do processo de mudança, ligar dois cenários que ocorrem
em diferentes alturas representando as alterações que ocorreram entre eles.
Figura 7 - Mudança num ambiente modelado [24]
21
5.2.3.1 Cenários
Um cenário é uma visão parcial da organização num instante de tempo específico. Este permite a
introdução do conceito de tempo no nosso modelo, permitindo ver qual o estado da organização num
dado momento do tempo. Um cenário pode conter processos, recursos, sistemas e objectivos, entre
outros, mais as relações que estes têm entre si.
Os cenários tornam-se numa ferramenta importante para a modelação de uma organização e
posteriormente para uma gestão correcta da mudança. Estes, devido ao facto de as técnicas de
modelação organizacional abordarem unicamente a organização como um objecto estático que não
evolui, obriga a uma modificação desta abordagem. A organização passa a ser vista como um objecto
dinâmico que muda, permitindo assim observar as alterações efectuadas o que permite fazer uma
gestão de mudança mais correcta e uma validação das alterações.
No contexto da Gestão da Mudança, este conceito ganha outra importância devido aos factores
acima descritos mas acima de tudo porque nos permite representar a organização Hoje (AS_IS) e
amanhã (TO_BE), que será útil na validação das mudanças. Este processo está descrito no capítulo
da solução.
Organização
(TO_BE)Organização
(AS_IS)
Cenário TO_BE
(modelo organizacional
no instante n)
Cenário AS_IS
(modelo organizacional
no instante actual)
Modeling
Change Process
ImplementationModeling
Figura 8 - Cenário AS_IS e TO_BE
22
5.2.3.2 Processo de Mudança
O processo de mudança é um processo de negócio que provoca alterações estruturais na
organização. Este é aplicado sobre um determinado cenário produzindo no final um cenário diferente
do inicial, introduzindo desta forma uma ordem temporal nos cenários.
Este processo modifica entidades variadas na organização, tais como:
Processos;
Sistemas;
Plataformas;
Aplicações;
Objectivos.
Este conceito é relevante para gestão da mudança, porque nos fornece a ferramenta para
introduzir a mudança na organização dentro de um ambiente modelado. Esta é executada como um
processo de negócio aceite dentro da empresa e efectua as alterações pretendidas pelo gestor.
5.2.4 Blueprints
Uma Arquitectura Empresarial tem como objectivo modelar os artefactos e as relações entre
estes na organização. Sendo uma Arquitectura Empresarial algo que define uma organização e
sendo um elemento muito complexo torna-se necessário encontrar uma forma simples de organizar
os seus elementos. Desta forma nasceu o conceito de blueprint. Desde o seu aparecimento que este
conceito tem sido considerado um elemento muito importante, especialmente pela área IT, devido à
sua capacidade de aumentar a comunicação entre pessoas, à facilidade com que permite descrever
um conceito.
23
De forma a produzir um blueprint não basta adoptar uma qualquer notação (ex: UML), é
necessário:
Uma teoria, que define regras de negócio;
Um modelo, que identifica as propriedades e semânticas de um artefacto;
Uma notação, para exprimir graficamente os artefactos;
Um problema, que justifique a produção do blueprint, tornando possível decidir que tipo
de artefactos devem aparecer. [25]
5.2.5 Problemas de Actualização
Tal como vimos anteriormente, os modelos criados podem ser uma ferramenta que dá um grande
suporte à organização. Contudo, muitas vezes, estes caem desuso não acompanhando a
organização nas mudanças que esta sofre, ou seja, em geral este é criado para um fim específico
não sendo actualizado sempre que a organização sofra alterações. [26]
Figura 9 - Exemplos de Blueprints
24
Mas porque é que este facto acontece?
Existem diversas explicações, tais como:
Falta de motivação;
Falta de compreensão da importância do modelo;
Dificuldade na actualização do modelo. [26]
Para resolver esta questão, o Centro de Engenharia Organizacional (CEO) propõe uma forma de
actualização do modelo, descrita na figura abaixo:
Figura 10 - Actualização Dinâmica do Meta-modelo [27]
25
No modelo, proposto pelo CEO, são definidas excepções ao fluxo normal do modelo e processos
de avaliação à irregularidade encontrada. Este processo é definido por Human Quality Control, que é
executado pelos indivíduos integrantes das várias actividades que compõem os processos da
organização. Este avalia os recursos que lhe chegam, e caso haja alguma irregularidade é obrigação
deste criar uma anotação que posteriormente irá ser avaliada pelo dono do processo, decidindo se é
do interesse da organização actualizar o modelo. Através deste sistema, nomeadamente do facto de
todas as alterações ficarem registadas, evita-se a perda da experiência obtida com a irregularidade
encontrada, aprendendo com isso e melhorando sistematicamente os processos. [27]
Este modelo engloba também o conceito de excepção. Uma excepção é uma situação em que
ocorre um desvio ao fluxo normal, onde acções assíncronas são disparadas para lidar com situações
anómalas. O uso deste novo conceito traz diversas vantagens, tais como:
O fluxo normal fica representado de forma mais clara;
Não é necessário antecipar todos os modos de falha, que são baseados na experiência e
intuição dos modeladores, ou das suas fontes de informação. [27]
Assim é introduzido o conceito de gestão dinâmica no modelo da organização, permitindo uma
constante actualização do mesmo permitindo que este se mantenha alinhado com a realidade actual
da empresa. Este processo é importante para a gestão de mudança devido ao facto de manter o
modelo actualizado, que serve de base para o processo de validação das mudanças, e ao facto de
aumentar o conhecimento da organização sobre si própria, através das propostas de alteração
efectuadas. Sem o modelo actualizado, qualquer gestão feita relativamente às alterações efectuadas
nunca estaria actualizada, não sendo uma mais-valia para a organização e não dando, por
consequência, suporte ao gestor.
26
6. Arquitectura da solução
Após ser efectuada uma investigação sobre a problemática da Gestão da Mudança, do estudo de
diferentes metodologias, o próximo passo consiste na apresentação de uma proposta de solução.
Este capítulo contém uma clarificação do contexto em que a tese é desenvolvida, a apresentação
das premissas necessárias para uma validação correcta das mudanças a efectuar, um conjunto de
casos de uso de forma a clarificar o contexto de utilização da solução e uma descrição detalhada da
proposta de solução desenvolvida de forma a cumprir o objectivo colocado pelo ITIL relativo à Gestão
de Mudança na área de IT.
“To implement approved changes efficiently, and with acceptable risk to the existing and to the
new IT services.” [30]
6.1 Contexto
A Link Consulting é uma empresa de consultadoria que forneceu suporte logístico, intelectual e
tecnológico na investigação e execução deste trabalho de investigação.
Esta empresa trabalha directamente na área de Arquitecturas Empresariais, tendo experiência
ampla no seu desenvolvimento. Exibe também conhecimento específico sobre os processos de ITIL,
sendo o mais relevante no contexto deste trabalho o de Gestão de Mudança. A partir desta realidade
foi possível desenvolver, utilizando o conhecimento partilhado, uma ferramenta que dê suporte à
Gestão da Mudança.
Existindo a possibilidade de a solução apresentada ser adicionada ao seu conhecimento geral, é
prevista a possibilidade de ser usada pela Link Consulting, tanto na gestão interna de projectos como
pelos seus potenciais ou actuais clientes.
27
6.2 Assumpções
A solução proposta (Ver secção 5.4) apresenta contudo algumas assumpções sem as quais não
poderia ter sido desenhado e sem as quais não funciona correctamente:
É necessário existir uma forma de representação da organização, nomeadamente um
meta-modelo;
O gestor tem de apresentar uma realidade à qual aspira (cenário SHOULD_BE) sempre
que pretende validar um conjunto de acções planeadas;
Informação relativa às alterações a efectuar deve estar disponível;
É de notar que o resultado da validação vai depender em grande parte da compreensão que o
gestor demonstra acerca da sua visão para empresa, tendo neste contexto elevada importância o
cenário futuro que apresentar. Apesar de este ser um risco presente, não pode ser evitado
dependendo do grau de conhecimento patente no gestor em questão.
6.3 Casos de Uso
Neste capítulo são descritos alguns casos de uso da ferramenta proposta de forma a facilitar a
sua compreensão e o contexto onde esta é útil.
6.3.1 Pedido de Validação da Mudança
Figura 11 - Pedido de Validação de uma Mudança
28
O gestor pretende efectuar uma mudança na organização, nomeadamente na área IT. O gestor
começa por efectuar um pedido para efectuar a mudança, que será seguido pela execução da
validação desta mudança. Esta actividade inclui a utilização das acções a efectuar (planeadas pelo
gestor, de forma a executar a mudança) e a definição do cenário desejado que espelha o estado da
organização após a implementação da mudança. Após ser efectuada esta validação, o gestor gera os
blueprints, que organizam os resultados, dando informação pertinente a este sobre se a mudança foi
validada ou não, e consequentemente as razões que levaram a esta situação.
6.3.2 Pedido de Actualização do Meta-Modelo
Figura 12 - Pedido de actualização do meta-modelo
29
O gestor pretende efectuar uma mudança na organização, contudo não consegue representar a
informação necessária a essa mudança de forma a efectuar posteriormente a validação. Desta forma
o processo inicia-se com um pedido de update à representação da organização, com o intuito de
permitir a representação da informação necessária. É feita a análise ao pedido e caso se verifique a
sua viabilidade o modelo é actualizado, prosseguindo posteriormente o percurso normal da validação
da mudança (descrito no caso de uso 5.3.1).
6.3.3 Pedido de Actualização da realidade da Organização
Figura 13 - Pedido de actualização da realidade da organização
30
O gestor pretende efectuar uma mudança na organização, contudo a realidade desta não
corresponde à informação contida na representação actual da organização (cenário AS_IS). Desta
forma torna-se necessário actualizar esta informação, para que a validação seja correcta e actual.
Assim o processo inicia-se com um pedido de actualização do cenário AS_IS, este é actualizado e de
seguida é feita a validação da mudança pretendida. Prosseguindo posteriormente o percurso normal
da validação da mudança (descrito no caso de uso 5.3.1).
6.4 Processo Geral de Suporte à Gestão da Mudança
Para executar uma Gestão da Mudança correcta, três acções têm de estar presentes no
processo.
1. Análise – Nesta fase, a mudança tem de ser estudada e planeada de forma a perceber
qual a sua relevância e impacto na organização. Esta fase será efectuada pelo gestor
que propõe a mudança, ou caso esteja implementado um processo como o proposto pelo
ITIL [23] (Ver secção 4.2.2.3.2) será efectuada pelo CAB (Change Advisory Board). O
resultado nesta análise irá definir o risco associado à implementação da mudança,
definindo desta forma o seu futuro.
2. Implementação – Tal como o nome indica esta fase corresponderá à implementação da
mudança analisada e planeada.
3. Revisão – Nesta fase é verificado se a implementação efectuada foi bem sucedida,
podendo esta ser revista e refeita caso ocorram problemas. [4]
É importante notar que o processo proposto dá suporte a uma destas fases, nomeadamente à
fase de análise. Este dará suporte ao planeamento da mudança verificando se o que está proposto
está de acordo com as acções a efectuar dentro da organização, minimizando desta forma o risco
associado a esta e dando uma ferramenta de suporte à gestão da mudança.
A fase de análise pode ser considerada a fase mais importante deste processo. É aqui que a
mudança é analisada e planeada sendo o seu futuro definido. Desta forma torna-se necessário
minimizar o risco associado à execução da mudança. É neste contexto que o processo proposto
ganha importância, dando uma ferramenta para minimizar este problema, permitindo verificar se
todas as acções planeadas permitem atingir o propósito desenhado por aqueles que propuseram a
mudança.
31
6.5 Descrição do Processo Geral de Suporte à Gestão da Mudança
A solução desenvolvida traduz-se num diagrama realizado com BPMN (Business Process
Modeling Notation). Esta notação permitiu-nos descrever de uma forma correcta a forma como o fluxo
de informação está organizado e as actividades pela qual a mudança terá de passar de forma a ser
validada. Os Anexos 1, 4, 5, 6 e 12 apresentam o processo proposto.
Esta secção explica em detalhe todas as actividades que compõem este processo.
6.5.1 Processo Geral de Suporte à Gestão da Mudança
O processo denominado como “Processo Geral de Suporte à Gestão da Mudança” (ver Anexo 1),
corresponde à base principal da nossa solução. Este processo tem como objectivo verificar se as
acções planeadas pelo gestor para implementar na organização, permitem atingir o estado desejado
por este para a organização em que se encontra.
Este processo é constituído por um caminho que vamos denominar de “normal”, ou seja,
corresponde à sequência de actividades pelas quais a mudança vai passar de forma a ser avaliada
correctamente.
Lista de
Mudanças
Pretendidas
(SHOULD_BE)
+
Validar
Alterações
Propostas+
Executar Gap
Analysis
Propor cenário
SHOULD_BE
Meta-
modelo
Final
Início
Validação Mudança
Propor nova representação
SHOULD_BE = TRUE
Rever Alterações
Propostas = TRUE
Alterações Validadas = FALSE
Alterações Validadas = TRUE
Consome
ProduzConsome
Figura 14 - Caminho normal do Processo Geral
32
As actividades que compõem este caminho são:
Propor cenário SHOULD_BE: O evento “Início Validação da Mudança” leva a esta actividade,
começando assim o processo. Assim ao gestor será requisitado que faça um estudo do que pretende
atingir com a mudança a efectuar e que apresente um cenário no qual descreve um futuro ideal ao
qual almeja que a organização atinja. Esta actividade é de elevada importância porque fornece uma
base de comparação para a validação posterior, permitindo verificar a eficácia das alterações
propostas.
Executar Gap Analysis: Após ser efectuada a proposta por parte do gestor vai-se efectuar a
diferença entre os dois cenários existentes, o cenário AS_IS e o cenário SHOULD_BE, ou seja, obter
a diferença entre a realidade actual, modelada, da organização e a realidade que o gestor pretende
atingir. Esta comparação é essencial na validação das alterações propostas pelo gestor porque nos
permite verificar o que falta Hoje de forma a conseguirmos atingir o Amanhã.
Validar Alterações Propostas: Esta actividade corresponde ao culminar do processo. Aqui as
acções planeadas pelo gestor vão ser comparadas com as acções obtidas na actividade “Executar
Gap Analysis” permitindo assim verificar se o que o gestor planeou está correcto e pode avançar para
a fase de Implementação prevista no processo de Gestão de Mudança (Ver secção 5.4). Com este
processo acaba então a validação. Uma descrição mais pormenorizada é apresentada no subcapítulo
relativo a esta actividade (Ver 5.5.1.3).
Estas actividades acima descritas compõem o que denominamos por “Caminho normal”. Contudo
existem mais dois inícios possíveis para este processo. Estes ocorrem de forma a precaver situações
inesperadas e oferecer uma forma de resolução, como por exemplo a impossibilidade de representar
a mudança no modelo actual da organização (Ver secção 4.2.5 sobre problemas de actualização) e a
não consistência da realidade da organização com o cenário actual da organização, ou seja quando o
cenário AS_IS não contém a informação actualizada da organização. Desta forma introduzimos o
conceito de excepções que permitem tratar situações anómalas ao fluxo normal do processo. Estes
caminhos alternativos são compostos pelas seguintes actividades:
33
Actualização do meta-modelo: Caso o gestor não consiga representar a mudança pretendida, o
evento “Impossibilidade de representar a mudança pretendida” ocorre, iniciando assim esta
actividade. Dentro desta, irá ser efectuada uma análise do problema e irá ser proposta uma forma de
modificar o modelo da organização de forma a introduzir a informação necessária para representação
da mudança (esta actividade é explicada em detalhe na secção 5.5.2). Após esta actividade finalizar
o fluxo de informação, o “Caminho Normal” é retomado executando os passos acima descritos (Ver
Anexo 1 e 2).
Update cenário AS_IS: Esta actividade ocorre após o gestor verificar que a realidade actual
física da organização não está de acordo com a realidade actual modelada da organização. Desta
forma ocorre o evento “Cenário AS_IS não corresponde à realidade” que inicia a actividade que
estamos a descrever. Esta actividade vai unicamente actualizar o modelo com a informação real.
Desta forma poderemos continuar o processo de validação executando a actividade “Executar Gap
Analysis”. O processo continua com esta actividade porque torna-se desnecessário requisitar ao
gestor uma nova proposta de um cenário futuro, visto que este nunca vai ser alterado por este desvio
do caminho normal (Ver Anexo 3).
6.5.2 Actualização do meta-modelo
Tal como explicado na secção acima, esta actividade (Ver Anexo 4) tem como objectivo resolver
uma situação anómala específica, nomeadamente a impossibilidade de representar a mudança
pretendida no modelo actual da organização. Esta situação levanta diversos problemas (ver secção
4.2.5, sobre problemas de actualização), mas traz diversas vantagens ao nosso processo, tais como:
Manutenção do modelo actual;
Aumento da percepção por parte do gestor da forma como a organização em que se insere
se organiza e como está estruturada;
Consolidação da aprendizagem da organização sobre as mudanças efectuadas sobre o seu
modelo, sobre a forma como está organizada e estruturada. Com isto é possível encontrar
mais rapidamente soluções para os problemas encontrados propondo uma solução que no
passado foi bem sucedida, trazendo assim vantagens para a organização.
Visto esta actividade ser de uma complexidade considerável, tal como efectuado em [33] vamos
propor um conjunto de roles de forma a perceber melhor as interacções inerentes a esta actividade
(ver secção 5.5.4.2). Esta é composta pelas seguintes actividades:
34
Verificação Histórico: O evento “Início Actualização Meta-modelo”executa a actividade a ser
descrita aqui, ou seja “Verificar Histórico”. Esta actividade consiste na verificação do histórico
guardado pela organização, ou seja na avaliação da aprendizagem da organização de forma a
verificar se existe alguma solução para o problema encontrado. Caso não exista, o processo continua
com a actividade “Propor alteração ao meta-modelo”, caso exista então o processo continua com a
actividade “Análise da regra existente”. Esta actividade introduz um conceito muito importante para a
organização, o conceito de aprendizagem [33].
Propor alteração ao meta-modelo: Esta actividade ocorre se nos depararmos com uma
situação nunca antes ocorrida na organização, ou seja, não foi encontrada nenhuma regra de solução
para o problema existente. Torna-se então necessário recorrer à análise efectuada, estudá-la e criar
uma proposta de modificação ao modelo existente de forma a resolver o problema ocorrido. Caso a
proposta seja aceite então esse conhecimento vai ser adicionado à base de dados que gere a
aprendizagem da organização, sendo criada uma nova regra aumentando assim a aprendizagem da
organização, passando posteriormente para a análise e implementação da regra. Caso a proposta
não seja aceite então terá de ser criada uma nova proposta de forma a resolver o problema existente.
Note-se que este trabalho será desenvolvido pelo role Criador.
Análise da regra existente: Esta actividade tem como objectivo analisar a regra de solução
encontrada e verificar como pode ser usada para resolver o problema existente. No final verifica-se a
regra é válida e útil aceitando ou não a sua utilização na forma de resolver o problema. Caso seja
aceite então a actividade “Update meta-modelo” será executada. Caso não seja aceite então terá de
ser criada uma nova regra que resolva o problema encontrado.
Update meta-modelo: Tal como o nome da actividade indica, quando o processo chega a esta
actividade terá de ser feito um update ao meta-modelo permitindo mantê-lo constante com a
realidade da organização e com as necessidades desta. Chegar a esta actividade implica uma de
duas situações, primeiro que a organização já se tinha deparado com um problema semelhante e já
tinha portanto aprendido a resolvê-lo, ou então que não existia nenhuma forma de resolver o
problema existente e foi necessário desenvolver uma solução que aumentou posteriormente a
percepção desta em relação a si própria e o seu conhecimento sobre aquele problema específico.
Com o final desta actividade chegamos ao fim podendo prosseguir com a validação da mudança
garantindo que o modelo da organização nesse momento é capaz de representar aquela mudança
específica.
35
6.5.3 Validar Acções Propostas
Para finalizar o processo de validação da mudança planeada, temos a actividade que
efectivamente valida as alterações planeadas pelo gestor, indicando se estas permitem atingir o
estado pretendido pelo gestor (ver Anexo 6). Com esta actividade, damos um suporte real a Gestão
da Mudança, nomeadamente à fase de Análise do processo, diminuindo a probabilidade de erro na
implementação das alterações planeadas pelo gestor. Esta actividade irá indicar as razões pelas
quais as alterações não são validadas e quais destas é que não foram validadas, permitindo ao
gestor focar-se sobre estes problemas numa fase inicial. Esta actividade propõe também a utilização
de uma base de aprendizagem por parte da organização, mantendo um registo de todas as acções
que não foram validadas e quais as soluções que foram encontradas para esses problemas,
permitindo desta forma manter um histórico das acções da organização, aumentado a percepção por
parte desta, melhorando também a capacidade de resposta por parte do utilizador e diminuindo a
probabilidade de ocorrência de erros na revisão das alterações, devido ao facto de já existirem
algumas soluções implementadas anteriormente.
Dito isto, este processo é composto pelas seguintes actividades.
Executar Validação: Esta actividade é iniciada pelo evento “Início Validação” e efectua a
comparação entre as acções obtidas na comparação entre o cenário AS_IS e o cenário
SHOULD_BE, verificando se todas as alterações propostas pelo gestor (TO_BE) resolvem todas as
diferenças encontradas. Caso todas as diferenças sejam resolvidas então o processo acaba dando
como resultado final a validação de todas as propostas do gestor. Caso existam alterações que não
estejam abrangidas pelo cenário proposto pelo gestor então passamos para a actividade “Propor
alteração da representação SHOULD_BE”. Por último caso existem diferenças que não são
resolvidas pelas alterações então será iniciada a actividade “Verificar existência de solução” que irá
procurar uma solução para o problema encontrado.
Propor alteração da representação SHOULD_BE: Para as propostas feitas pelo gestor que não
foram contempladas na realidade, que descreve o que este pretende ver a organização atingir, é
proposto uma alteração ao cenário SHOULD_BE apresentado pelo gestor de forma a contemplar
todas as alterações que não estavam previstas nesse cenário. Se esta proposta for aceite então este
processo acaba recomeçando o processo geral, nomeadamente na actividade “Propor cenário
SHOULD_BE” (ver secção 5.5.1). Caso não seja aceite, então passamos para a actividade “Propor
revisão das alterações propostas”.
36
Propor revisão das alterações propostas: Visto o gestor não ter aceite a proposta de alteração
à realidade futura, então o que terá de ser revisto serão as alterações propostas. Desta forma é
proposta uma revisão a essas alterações de forma a estarem de acordo com a realidade proposta. Se
essa proposta for aceite, então a actividade “Rever alterações propostas” é iniciada e este processo
de validação (i.e. a actividade “Validar acções Propostas”) será refeito com o novo planeamento de
alterações.
Verificar existência de solução: Se se verificar a necessidade de rever as propostas de
alteração efectuadas então o processo iniciará esta actividade de forma a verificar se o conhecimento
obtido pela organização contém uma resposta para os problemas identificados permitindo uma
resolução mais expedita e optimizada dos problemas encontrados. Caso não contenha uma reposta
será necessário criar uma solução para o problema encontrado que posteriormente será adicionado
ao know-how da organização melhorando o conhecimento desta.
Rever alterações propostas: Nesta actividade o gestor analisa os problemas encontrados e
revê as propostas de alteração efectuadas de forma a que na próxima iteração do ciclo estas já
resolvam os problemas identificados.
6.5.4 Descrição dos Roles
“Roles are a separation of concerns mechanism that allows business objects to be observed from different
perspectives.” [32]
É importante notar que esta distinção entre os intervenientes no processo é importante. O
conceito de role permite decompor o sistema num conjunto de objectos de negócio capazes de
separar claramente os componentes chave e as colaborações existentes. Desta forma a
compreensão da organização é melhorada, percebendo quem executa o quê e com que
responsabilidades associadas. [32] [33]
37
6.5.4.1 Actividade “Verificar existência de solução”
A actividade acima descrita (ver secção 5.5.1 ), propõe caminhos a percorrer de forma a o gestor
corrigir os problemas que o impedem de atingir o estado pretendido. Esta terá de ser dividida, de
forma a ser melhor perceptível, em diferentes roles, que serão os seguintes:
Avaliador;
Criador;
Coordenador.
O processo é iniciado pelo Avaliador, que tal como o nome indica avalia a acção não validada,
verificando o histórico com o intuito de procurar informação sobre acções passadas relativas ao
problema apresentado. Após esta verificação a acção do Avaliador termina, sendo continuada por um
dos outros dois roles propostos.
Figura 15 - Role Avaliador “Verificar existência de solução”
38
Caso seja encontrada uma regra de solução anterior, o role Coordenador toma controlo e executa
a parte restante do processo, tendo por base o documento detalhado da regra de solução (ver secção
10.7. Este utiliza a regra encontrada pelo avaliador e propõe uma alteração de forma a ser uma
solução ao problema encontrado, utilizando a experiência da organização relativa a este problema.
Assim é permitida uma optimização dos recursos e diminuinda a probabilidade de erro no
planeamento, tal como descrito na secção anterior.
Caso o Avaliador, não encontre uma regra de solução, então o role Criador toma controlo. Este
analisa o problema e propõe uma regra de solução que permitirá, caso seja aceite, enriquecer a
experiência da organização relativamente a esse problema específico. Esta regra será adicionada ao
histórico da organização para utilização futura. A acção do Criador acaba neste ponto, passando
posteriormente o controlo ao role Coordenador.
Figura 16 - Role Criador “Verificar existência de solução”
39
6.5.4.2 Actividade “Actualização do meta-modelo”
Nesta actividade (ver Anexo 4) verificámos que existem os mesmos três roles descritos cujo
funcionamento geral mantém-se inalterado, salvo pequenas alterações às suas funções. Assim, os
três roles são:
Avaliador;
Criador;
Coordenador.
Figura 17 - Role Coordenador “Verificar existência de solução”
40
A actividade inicia-se com o Avaliador que, tal como o nome indica irá avaliar a mudança que se
pretende efectuar, e irá verificar se já existe uma solução para resolver o problema encontrado. Este,
se encontrar uma solução já existente passa então controlo ao Coordenador que irá analisá-la de
forma a verificar se esta pode ser totalmente aplicada ou parcialmente aplicada permitindo no entanto
a resolução rápida do problema apresentado. Se verificar que a regra pode ser aplicada então é feito
um update ao meta-modelo acabando esta actividade e prosseguindo o processo de validação. Se
decidir que não pode utilizar a solução então o Coordenador passa o controlo ao Criador que irá
desenvolver uma solução para o problema em mãos.
Figura 18 - Role Avaliador “Actualização Meta-modelo”
Figura 19 - Role Criador “Actualização Meta-modelo”
41
Caso o Avaliador não encontre nenhuma solução na “memória” da organização, este passa
controlo ao role Criador que irá propor uma alteração ao meta-modelo. Esta será aceite ou não. Caso
não seja então o Criador terá de propor uma nova alteração que resolva os problemas existentes.
Caso seja aceite então a nova regra será adicionada à memória de organização passando
posteriormente o controlo ao role Coordenador, cujo funcionamento está descrito no parágrafo acima.
Figura 20 - Role Coordenador “Actualização Meta-modelo”
42
6.6 Vantagens
A solução acima descrita ganha uma grande importância no contexto actual das organizações,
visto o investimento em ferramentas IT ter aumentado consideravelmente nos últimos anos. Estas
mudam, logo é do interesse de todos que essas mudanças corram bem e não afectem o bom
funcionamento destas organizações, permitindo uma optimização dos recursos e uma não afectação
dos serviços.
Desta forma esta solução oferece o seguinte:
Uma forma de diminuição da ocorrência de erros na fase de implementação da mudança;
Uma automatização e optimização do processo de validação da mudança;
Uma obrigação à formalização das alterações planeadas e efectuadas;
Uma forma de aprendizagem por parte das organizações;
Um aumento da percepção por parte dos intervenientes da organização em que se
inserem e do caminho que esta está a tomar.
7. Implementação
Esta secção descreve em pormenor a implementação de um protótipo que suporta o processo de
validação da Mudança descrito na secção anterior. Este produzirá algumas vistas de forma a informar
o gestor permitindo uma melhor compreensão dos resultados obtidos. Os detalhes relativos ao
protótipo e às vistas produzidas serão explicados em detalhe nesta secção.
As secções abaixo irão focar-se sobre este tema de forma a proporcionar uma melhor
compreensão.
43
7.1 Protótipo
O protótipo desenvolvido tem como objectivo ser geral a qualquer organização, contudo como
aplicação prática este foi aplicado utilizando o meta-modelo KYE de forma a proporcionar-nos um
ambiente de teste fiável. Desta forma retiramos que o processo proposto como solução é
independente do contexto organizacional e pode ser aplicado a qualquer organização que o deseje.
O protótipo foi desenvolvido sobre as seguintes aplicações:
BMS – Blueprint Management System;
SA – System Architect;
Estas duas ferramentas fornecem-nos as condições necessárias para resolver os requisitos
apontados na secção 5.2.
Visto a área IT ser uma área muito vasta, e as regras pelas quais é gerida serem igualmente
vastas e dependentes da organização, foi necessário limitar a abrangência destas. Para isso a
validação das alterações propostas foi limitada apenas para os seguintes artefactos:
Aplicações;
Componentes;
Plataformas.
7.1.1 Requisitos
De forma a garantir que este protótipo seja implementado com sucesso é necessário garantir as
seguintes condições:
Os resultados obtidos através deste protótipo têm de ser o mais fiel possível;
O protótipo tem de ser extensível e configurável de forma a aumentar e modificar os
artefactos verificados;
O protótipo deve promover a fácil obtenção de resultados;
O protótipo deve promover a fácil compreensão dos resultados;
O protótipo deve ser escalável de forma a adicionar novas vistas e regras de negócio;
O protótipo deve ser independente do modelo utilizado;
O protótipo deve apresentar uma forma de representar o cenário SHOULD_BE.
44
Se garantirmos o cumprimento destes requisitos esperamos que a qualidade do protótipo
desenvolvido seja assegurada.
7.1.2 Arquitectura Lógica do Protótipo
De acordo com [34] o modelo module viewtype é usado normalmente para representar as
principais unidades de um sistema. Tendo isto em atenção e aplicando os conceitos propostos por
[34] apresentamos a nossa visão da arquitectura do protótipo desenvolvido.
Figura 21 - Arquitectura Conceptual do Protótipo
7.1.2.1 Presentation Layer
A camada de Apresentação (ver Figura 22) decompõe-se nos seguintes elementos,
demonstrando as ligações entre os diferentes módulos que a constituem.
Presentation Layer
Business Layer
Scenario OrganizationData Collection
Presentation Layer
uses
Figura 22 - Camada de Apresentação
45
Esta camada é constituída por dois módulos diferentes:
Data Collection;
Scenario Organization.
O módulo Data Collection é responsável por obter a informação de validação relevante contida
nos reports criados. Este módulo será posteriormente usado pelo Scenario Organization que usará
e organizará a informação retirada e produzirá cenários que permitam ao utilizador retirar ilações
sobre a validação das suas acções e o nível de maturidade destas acções.
7.1.2.2 Business Layer
A camada de Negócio (ver Figura 23) decompõe-se nos seguintes elementos, demonstrando as
ligações entre os diferentes módulos que a constituem.
Business Rules Control
Report Generation
Data Validation
Scenario Importation
Business Layer
uses
uses
uses
Figura 23 - Camada de Negócio
46
Esta camada é constituída pelos seguintes módulos:
Scenario Importation;
Data Validation;
Business Rules Control
Report Generation.
O módulo Scenario Importation é responsável pela importação do cenário SHOULD_BE
apresentado anteriormente (ver secção 5.2). Este módulo oferece duas opções de inserção dos
dados relativos a esse cenário (ver secção 6.1.3). O módulo Business Rules Control gere todas as
regras de negócio necessárias para efectuar a validação das alterações. Estes dois módulos
apresentados, serão usados pela validação da mudança, processo este controlado por Data
Validation, este recolhe toda a informação necessária e faz uma análise das alterações propostas
retirando conclusões acerca dos dados apresentados. Concluindo este processo o módulo Report
Generation usa os resultados obtidos através da validação e gera os reports necessários que serão
usados na camada de Apresentação de forma a serem apresentados ao gestor.
7.1.3 Cenário SHOULD_BE
O cenário SHOULD_BE, tal como indicado anteriormente é um requisito à solução desenvolvida.
Desta forma tornou-se necessário encontrar uma forma de o representar, permitindo que este esteja
disponível para validar as alterações planeadas. Assim foi necessário alterar ligeiramente o meta-
modelo da organização, mantendo naturalmente a estrutura e ligações inter-artefactos, sendo
posteriormente desenvolvidas duas formas possíveis de inserção do cenário SHOULD_BE, estas são
as seguintes:
Reports;
Inserção directa na enciclopédia base da organização.
7.1.3.1 Meta-Modelo
Para ser possível a introdução de um cenário futuro, nomeadamente o SHOULD_BE, foi
necessário modificar ligeiramente o meta-modelo, acrescentando a cada artefacto considerado (no
nosso caso, Aplicações, Componentes e Plataformas), informação adicional.
47
Esta informação adicional corresponde na realidade a uma cópia do artefacto original, ou seja, o
artefacto, por exemplo Aplicação, contém a propriedade Components e a propriedade
ComponentsSB (Ver Figura 24). Esta última corresponde ao processo ao qual o meta-modelo foi
submetido, permitindo que este consiga representar os dois cenários necessários para a execução
deste processo, o cenário AS_IS e o cenário SHOULD_BE.
Figura 24 – Exemplo de artefacto com informação SHOULD_BE
Esta solução tem associadas duas desvantagens. Obriga a uma maior ocupação de espaço físico
e a uma possível duplicação da informação. Contudo pensamos que estas são desvantagens
aceitáveis perante o cenário de optimização de tempo e recursos da organização.
Tendo pesado estas desvantagens vamos então descrever em mais pormenor estas duas formas
de inserção:
Forma de Inserção Descrição
Reports Após definirmos a forma de representação do cenário SHOULD_BE,
torna-se necessário compreender como vamos inserir esta informação
de forma a correr o processo descrito anteriormente. A primeira forma
desenvolvida é focada nas acções que o gestor pretende efectuar.
Para isso desenvolveu-se um template (ver Anexo 8) que o gestor pode
utilizar. Este depois será importado pelo protótipo.
Inserção Directa Este método é mais directo, porque implica inserir directamente os
dados na enciclopédia que define a organização
Tabela 2 - Formas de Inserção
48
7.1.4 Interface Gráfica
A interface do protótipo desenvolvido é apresentada na figura seguinte. Podemos ver as duas
opções de importação do cenário.
Figura 25 - Ecrã principal do validador de alterações
Tal como apresentado na figura anterior, existem duas opções de selecção. A primeira “Validate
Should Be Actions” corresponde à importação através do report. A segunda, “Validate Should Be
Representation” corresponde à importação do cenário através do método de importação directa.
O ciclo inicia-se efectuando o processo descrito na secção 5, e após validar as opções apresenta
o seguinte ecrã.
49
Figura 26 - Ecrã de selecção do tipo de organização dos resultados finais
Nesta fase da solução é oferecido ao gestor a escolha sobre a forma de visualização dos
resultados obtidos. Este depara-se com três escolhas:
1. Written Report:
2. Overall View;
3. Specific Element View.
50
Os resultados, tal como o nome das opções indicam, podem ser apresentados através de:
Tipo de Output Descrição
report Para cada acção é especificado a validação/não validação da
acção e as razões para tal problema ter acontecido.
Overall View Corresponde a uma vista geral das alterações propostas pelo
gestor. Indica quais as vistas validadas e não validadas, e quais as
acções sobre os seus sub-elementos que foram validadas ou não
validadas.
Specific Element View Corresponde a uma vista específica sobre um elemento específico.
Indica se foi validado ou não, que sub-elementos usa, a acção que
se pretende efectuar sobre esse elemento e uma possível solução
para a resolução do problema encontrado.
Tabela 3 - Tipos de Output
7.2 Vistas de Gestão da Mudança
As vistas de Gestão de Mudança revolvem em torno de um conceito, o de dar suporte à validação
das alterações propostas por parte do gestor. Desta forma estas tentam explicitar de uma forma
simplista e de fácil compreensão através da classificação e agrupamento de artefactos o estado de
cada alteração, permitindo desta forma ao gestor efectuar uma gestão mais correcta, e acima de tudo
mais consciente do problema encontrado e da forma de o resolver.
Change Management Blueprints
Overall Specific Element
Figura 27 - Change Management Blueprints
51
Este tipo de blueprints é segmentado em dois subtipos:
Overall View;
Specific Element View.
Os artefactos abrangidos neste tipo vista, serão todos aqueles que possam ser alterados pelas
alterações propostas pelo gestor, no nosso caso vamos apenas considerar os seguintes artefactos,
baseados no meta-modelo KYE:
Applications;
Components;
Platforms.
7.2.1 Overall View
O conceito fundamental deste tipo de blueprints é as alterações propostas pelo gestor. Esta vista
tem no topo da hierarquia de conceitos a divisão entre as acções validadas e não validadas,
permitindo assim uma primeira filtragem das alterações problemáticas. Encapsulados nestas divisões
aparecem as acções possíveis de se efectuar sobre os artefactos, nomeadamente as acções
CREATE, UPDATE e DELETE, obrigando a uma nova filtragem entre as alterações, permitindo uma
maior compreensão por parte do gestor sobre o artefacto em questão. Por último, os artefactos
específicos são organizados por categorias, ou seja, os tipos a que pertencem, como por exemplo
Applications, Components e Platforms.
Change Management Blueprints
Overall Specific Element
Figura 28 - Overall Blueprint
52
7.2.1.1 Questões dominantes
Este tipo de vistas tentam resolver uma série de problemáticas, permitindo em caso de sucesso,
uma melhor compreensão do estado das alterações. Assim estas vistas abordam as seguintes
questões:
Que artefactos estão de acordo com a realidade pretendida?
Quais as razões da não validação das acções sobre determinado artefacto?
Que artefactos usam o sub-artefacto “X”?
A esta vista é aplicado um filtro de conformidade que permite verificar que acções sobre os sub-
artefactos são validadas. O filtro pinta a verde as acções que estão validadas e a vermelho as que
não estão validadas, após aplicar as regras de negócio definidas pela organização, como por
exemplo:
Para criar uma aplicação “X”, esta tem de conter pelo menos um componente. Logo esse
componente tem de ser criado também, caso não exista.
Se repararmos no exemplo apresentado (ver Anexo 9) verificamos que a aplicação DOORS é
validada porque todos os componentes que utiliza foram criados permitindo assim a sua criação,
respeitando a regra de negócio existente,
7.2.2 Specific Element View
Change Management Blueprints
Specific ElementOverall
Figura 29 - Specific Element Blueprint
53
O conceito fundamental deste tipo de blueprints é uma alteração específica proposta pelo gestor.
Esta vista tem como objectivo elucidar de uma forma mais concreta o gestor sobre o estado de uma
dada instância de um artefacto da organização. Para isso esta vista tem no topo da hierarquia as
acções efectuadas sobre o artefacto, a solução proposta para resolução de problemas encontrados, e
os sub-artefactos associados a este. Esta informação permite um nível de compreensão mais
profunda por parte do gestor.
Encapsulados nestas divisões aparecem as acções possíveis de se efectuar sobre os artefactos,
nomeadamente as acções CREATE, UPDATE e DELETE, permitindo uma divisão das alterações a
efectuar ao artefacto e permitindo uma associação entre a solução para o problema e a acção que se
pretende efectuar. É também aplicado um filtro de conformidade a esta vista, pintando de verde os
elementos validados e a vermelhos os não validados, nomeadamente os sub-artefactos e as acções
a efectuar.
7.2.2.1 Questões dominantes
Este tipo de vistas tentam resolver uma série de problemáticas, permitindo em caso de sucesso,
uma melhor compreensão do estado das alterações. Assim estas vistas abordam as seguintes
questões:
Quais as acções validadas e não validadas efectuadas sobre o artefacto “X”?
Qual a solução proposta para uma acção não validada?
Qual a razão da não validação de uma acção “Y” efectuada sobre o elemento “X”?
O funcionamento desta vista é demonstrado através de dois exemplos, um de validação da acção
e outro de não validação (ver Anexo 10).
54
8. Validação da Solução
A próxima secção é dedicada à explicação do método usado com o intuito de validar de uma
forma correcta a solução e o protótipo apresentados.
8.1 Contextualização
A empresa denominada Link Consulting, para além do facto de ter servido como base de suporte
ao desenvolvimento da solução apresentada, tornou-se também uma fonte segura e activa de
validação do trabalho desenvolvido.
Assim durante o período de finalização do trabalho, foram efectuadas diversas reuniões, sendo
estas integradas por elementos constituintes desta empresa de forma a verificar a validade do
processo desenvolvido. Estas sessões de brainstorming foram incrivelmente úteis para o trabalho,
proporcionando diversas refactorizações ao processo proposto e a adição de novas características de
forma a tornar o trabalho mais completo e útil para uma empresa e um gestor em geral. Podemos
observar a versão final do processo apresentado nos Anexo 1, 4, 5, 6 e 12. As principais novas
características adicionadas após estas reuniões resumem-se a:
Definição de roles que definirão as características do sujeito que efectua essas
actividades;
Adição de aprendizagem da organização.
Organização
Avaliador
Coordenador
Criador
Documento
detalhado da
regra de
solução
Base de
Dados de
acções de
resolução
Solução aceite?
Regra de solução encontrada
Análise
alteração não
validada
Propor update
das alterações
planeadas
Adicionar regra
ao histórico
Propor regra de
solução
Verificação
Histórico
Proposta
de
alteração
Início Verificação
de solução
Fim
Produz
Consome
Não
Sim
Não
Sim
Produz
Utiliza
Figura 30 - Resultado final após validação
55
8.2 Método utilizado na validação
A metodologia utilizada na validação desta solução é constituída por duas fases distintas, ambas
apoiadas pelo protótipo desenvolvido, estando estes testes limitados aos artefactos considerados no
desenvolvimento do protótipo. Contudo é de notar que este processo almeja validar toda a
informação modelada da organização.
As fases planeadas, descritas nas secções 7.2.1 e 7.2.2 aplicam, respectivamente, casos de
teste fictícios e um caso real, desenvolvido pela Link Consulting.
8.2.1 Casos de teste fictícios
Na primeira fase, foram desenvolvidos casos de teste fictícios, não correspondendo a nenhuma
situação real estudada. Esta fase tem como vantagem a despistagem de possíveis erros no
desenvolvimento do protótipo garantindo desta forma a completude e veracidade nos resultados que
apresenta. Garante também a validação de pequenos casos de forma a permitir uma melhor
compreensão dos resultados obtidos.
Desta forma vamos apresentar dois casos distintos, apresentados no anexo 11, que
correspondem respectivamente às seguintes acções:
Criar uma aplicação;
Criar uma aplicação e modificar outra.
É de notar que apesar da aparente simplicidade dos casos apresentados as acções propostas
contém um nível de profundidade complexo, sendo necessário interagir com diversos artefactos
distintos, como por exemplo, Componentes, Plataformas e Projectos. Tornando este caso muito mais
complexo. As tabelas apresentada em baixo apresentam todas as acções efectuadas nos dois casos
de teste, não mencionando os artefactos, relacionados com as acções que se pretende efectuar, que
não têm projectos associados.
56
Action Type Name Project
CREATE Application Doors Project 1
CREATE Component Comp 1 Project 2
CREATE Platform Plat 1, Plat 2, Plat 3
and Doors
Project 3
UPDATE Platform Office 2007 SP1 Project 4
UPDATE Component Doors Integration and
Excel Exploratory
Project 5
DELETE Component EA Client Project 6
Tabela 4 - Acções associadas ao caso de teste relativo à criação de uma aplicação
Action Type Name Project
CREATE Application App X Project 1
UPDATE Application App Y Project 2
DELETE Platform Plat 3 Project 3
DELETE Component Comp 1 Project 4
Tabela 5 - Acções associadas ao caso de teste relativo à criação de duas aplicações
57
8.2.1.1 Resultados obtidos
Os casos definidos tiveram de ser importados para o System Architect de forma a correr o
processo proposto.
Vamos então especificar para os dois casos apresentados os resultados obtidos.
Criação de uma aplicação e alteração de outra
Após os dados relativos a este teste terem sido importados para o SA o protótipo foi executado.
Validou os resultados e deu a opção ao gestor de gerar blueprints de forma a facilitar a compreensão
dos resultados obtidos. Assim para iniciar decidimos gerar um Overall View Blueprint de forma a ter
uma melhor noção do estado geral do que está planeado. O blueprint gerado foi o seguinte:
A partir daqui concluímos que as acções planeadas por cima das duas aplicações não foram
validadas, sendo insuficiente o que está planeado. Desta forma vamos mais fundo na nossa
compreensão acerca do porquê desta não validação, gerando respectivamente os blueprints Specific
View dos elementos em questão, nomeadamente o App X e o App Y.
Figura 31 – Acções não validadas na criação de uma aplicação e alteração de outra
58
Daqui retiramos que não existe nenhum projecto que crie os componentes 2 e 3, impedindo
assim a criação da aplicação X. Este resultado respeita a regra de negócio definida que afirma que
uma aplicação não pode ser criada sem ter nenhum componente existente associado. Este blueprint
propõe também uma solução para o problema encontrado, sugerindo que seja adicionado um
projecto que crie os artefactos em questão, neste caso os componentes 2 e 3.
Figura 32 - Specific View App X
Figura 33 - Specific View App Y
59
Tal como vimos anteriormente para a App X, a App Y tem os mesmos problemas, com a
diferença que ocorrem em mais componentes. Assim a solução prevê-se igual.
É então proposta ao gestor uma alteração aos projectos propostos. De seguida ele volta a
executar a actividade “Executar Gap Analysis” descrita na secção 5.5.1. Voltamos a pedir que seja
gerado o Overall View blueprint que nos devolve o seguinte resultado:
Observando este blueprint retiramos que pelo menos um dos problemas encontrado foi resolvido,
sendo que os projectos propostos agora suportam a criação da App X sem problemas. Contudo
verificamos que a App Y ainda não foi validada. Voltamos a gerar o blueprint (ver figura 33) e
notamos que os mesmos problemas se mantêm, excepto para os componentes 2 e 3. É então
proposto ao gestor uma nova alteração aos projectos planeados. De seguida ele volta a executar a
actividade “Executar Gap Analysis” descrita na secção 5.5.1. Voltamos a pedir que seja gerado o
Overall View blueprint que nos devolve o seguinte resultado:
Figura 34 - Acção criar validada na criação de uma aplicação e alteração de outra
Figura 35 - Acções validadas na criação de uma aplicação e alteração de outra
60
Com a geração deste blueprint o processo acaba permitindo ao gestor pôr em produção o que
está planeado.
Criação de uma aplicação
Após os dados relativos a este teste terem sido importados para o SA, o protótipo foi executado.
Validou os resultados e deu a opção ao gestor de gerar blueprints de forma a facilitar a sua
compreensão dos resultados obtidos. Assim para iniciar decidimos gerar um Overall View Blueprint
de forma a ter uma melhor noção do estado geral do que está planeado. O blueprint gerado foi o
seguinte:
Da análise da imagem anterior retiramos que os projectos propostos pelo gestor são suficientes
para criar a aplicação pretendida. Verificamos que existem algumas acções (ênfase nas setas
vermelhas) efectuadas sobre componentes e plataformas que não foram validadas mas essas
ocorrências não invalidam as acções que se pretendem efectuar, neste caso a criação da aplicação
Doors.
8.2.2 Caso real
A aplicação de um caso real corresponde à segunda fase definida da validação da solução. Esta
fase impõe um grau de seriedade e consistência diferentes da que a primeira fase impõe, devido ao
facto de ser aplicado a uma situação real, desenvolvida pela Link Consulting. Isto permite verificar, ou
não, tudo o que foi afirmado.
O caso escolhido corresponde há alteração de diversos componentes, aplicações e plataformas
utilizadas pelo Banco Espírito Santo (BES). As acções efectuadas sobre estes artefactos estão
definidas pela imagens 37, 38 e 39 e pela tabela 6.
Figura 36 Acções validadas na criação de uma aplicação
61
Figura 37 - Acções efectuadas sobre os artefactos
Figura 38 - Ligações entre os diferentes artefactos
62
Action Type Name Project
CREATE Application TCI, Gestor de Imagem Project
CREATE Component A1, A2, A3. A4, A5, A6, A7, A8, A9. A10, A11, A12, A13,A14, A17, I1, I2, I3, I4, I5, LN1, LN2,
LN3, LN4, LN5, LN6, LN7, LN8, LN9, L10, LN 13
Project
UPDATE Application DPO, BESnet Particulares, BESnet Negócios, NPT, Posto de Trabalho Balcão
Project
UPDATE Platform Flex View, Bank View, COBOL/CIC5/CB2, PackBase, EAI TIBCO, File Broker
Project
DELETE Platform ISU Project
Tabela 6 - Acções associadas ao caso real
Figura 39 - Tipo dos artefactos
63
8.2.2.1 Resultados obtidos
Após os dados relativos a este teste terem sido importados para o SA, o protótipo foi executado.
Validou os resultados e deu a opção ao gestor de gerar blueprints de forma a facilitar a sua
compreensão dos resultados obtidos. Assim para iniciar decidimos gerar um Overall View Blueprint
de forma a ter uma melhor noção do estado geral do que está planeado. O blueprint gerado foi o
seguinte:
Figura 40 - As acções criar relativa aos componentes são validadas, o resto não é: Overall View
64
Daqui conclímos que temos de rever o projecto de forma a validar as acções efectuadas sobre as
plataformas que são modificadas, tal como as acções sobre as aplicações criadas e modificadas.
Desta forma utilizamos o Specific Element View blueprint para tentar perceber melhor o que se
passava com os elementos problemáticos.
Deste blueprint concluímos que não existe nenhum projecto que modifique a aplicação BESnet
Negócios, de forma a passar a utilizar os componentes A13 e A14. É de notar que este procedimento
foi executado para todos os elementos problemáticos, sendo todos os problemas encontrados
resolvidos. De seguida foi efectuada nova validação, seguindo os passos da solução apresentada.
Voltámos a gerar um blueprint do tipo Overall View e o resultado obtido foi o seguinte:
Figura 41 - Specific View App BESnet Negócios
65
Aqui podemos observar que já são poucas as acções não validadas. Assim vamos aplicar o
mesmo procedimento que foi efectuado anteriormente de forma a resolver os problemas encontrados,
e o resultado obtido foi:
Figura 42 - Acções quase validadas: Overall View
66
Após esta última iteracção concluímos que a forma como o projecto está estruturado permite
atingir os objectivos pretendidos, podendo desta forma passar para a fase de produção. É de notar
que este objectivo foi atingido em três iteracções do processo apresentado.
67
8.2.3 Conclusões
Após ser efectuada a validação do processo podemos retirar certas conclusões, algumas delas já
apregoadas anteriormente na apresentação da solução.
Primeiro percebemos que o facto de a organização “aprender” com todas as decisões tomadas
facilita o esforço e o tempo dedicados pelo gestor ao planeamento de uma qualquer mudança a
efectuar na organização. Isto ocorre devido há existência de uma proposta de solução para o
problema encontrado utilizando as experiências anteriores como referência. Segundo concluí que a
geração de blueprints permite um nível de compreensão muito superior, facilitando a resolução dos
problemas encontrados. Estes dois factos são muito importantes para o aumento do self-awareness
permitindo que o gestor conheça de uma forma muito mais complexa e profunda a organização em
que se insere, nomeadamente a forma como está organizada.
Para finalizar concluímos que a forma como este processo se adapta a novas situações
corresponde ao que tínhamos previsto, permitindo acompanhar a organização na sua evolução ao
longo do tempo.
68
9. Conclusões
A importância da Gestão da Mudança é hoje em dia um conceito cada vez mais aceite na
realidade empresarial. Percebemos que esta temática, se bem empregue e implementada, permite
uma optimização da componente IT da organização e uma redução significativa dos custos
associados a uma alteração dentro da realidade da organização.
Para atingir estes objectivos foram desenvolvidas diversas teorias, nomeadamente na
componente humana e organizacional. Visto termos concluído que a componente humana tinha
associadas diversas teorias, sendo algumas delas apresentadas no trabalho relacionado desta tese,
decidimos enveredar por um caminho mais relacionado com a componente organizacional. Nesta
área encontrámos apenas uma teoria, actualmente com algum grau de maturação, nomeadamente a
o processo de Gestão de Mudança apresentado pelo ITIL.
Durante a pesquisa efectuada sobre esta matéria, percebemos que o processo proposto pelo ITIL
era direccionado a um género de mudança mais complexo e expansivo, deixando alguma liberdade
para alterações mais pequenas, ou seja, não tão importantes. Assim, utilizando todo o conhecimento
adquirido na pesquisa efectuada, foi possível propor um processo que permita preencher o espaço
que o ITIL decidiu não preencher. Este vazio, na minha opinião é importante para que, cada vez mais,
uma organização consiga funcionar de uma forma mais correcta, optimizando as suas acções,
limitando cada vez mais a margem de erro, a margem de guess work que ainda assola os gestores
de hoje em dia.
Outra conclusão retirada deste estudo foca-se no facto de que diversas mudanças propostas não
serem bem executadas e que as representações criadas da organização ficam sit on the shelf, não
sendo actualizadas nem trabalhadas ao longo do tempo, o que leva a concluir que o conhecimento
dos colaboradores da organização é limitado. Procura-se melhorar esta vertente com o processo
proposto, dando possibilidade a todos os elementos de fazerem sugestões sobre a informação que
pensam ser essencial.
69
Gostava de salientar que o que proponho trabalha directamente com a informação presente na
componente modelada da organização, algo que raramente vi expresso nas teorias apresentadas
durante a pesquisa que efectuei. Este facto permite introduzir um grau de exactidão elevado,
associado ao facto de a validação das alterações efectuadas ser feita de uma forma automática,
sendo unicamente pedido ao stakeholder que insira a informação necessária para validar as acções
planeadas, nomeadamente o cenário que este pretende atingir e as alterações que este pretende
efectuar. Outro aspecto que considero muito importante, é o processo de aprendizagem que foi
adicionado a este processo. Penso que este factor permite dar um passo importante na
materialização de um bom processo de mudança, elevando este conceito a um nível superior. O facto
de a organização aprender com as suas acções, erros e experiências melhora a gestão de mudança
efectuada por esta sobre esta, sendo refinada cada vez mais à medida que o tempo passa.
Contudo penso que o trabalho necessita de maturação, de mais validações e de mais esforço no
sentido de limar algumas arestas. Verifica-se também que está criada a base da solução para alguns
problemas de uma temática complexa, sendo necessário dar continuidade ao trabalho desenvolvido.
9.1 Trabalho Futuro
O foco deste trabalho centrou-se na criação de uma forma para validar a planificação do gestor
de uma forma automática e que garantisse um certo nível de segurança aquando a passagem dos
projectos para produção.
Contudo percebemos que este processo pode ser melhorado de diversas formas. Do ponto de
vista da optimização consideramos que o facto de a actividade de gap analysis ser efectuada sempre
que uma alteração é efectuada aos projectos é claramente prejudicial à rapidez do processo. Desta
forma acredito que o processo pode ser estudado e melhorado de forma a eliminar esta deficiência.
Outro aspecto, que penso ser muito relevante, foca-se na tarefa de aprendizagem proposta. Esta
foca-se na experiência passada, como na avaliação das acções que foram implementadas
correctamente. Penso que com algum estudo esta tarefa pode ser incrementalmente melhorada,
permitindo no futuro ser associado uma componente de proposta de solução juntando a experiência
anterior com uma avaliação do problema actual, permitindo desta forma melhorar consideravelmente
o processo.
70
10. Referências
1. Tan, C C. The Theory and Practice of Change Management . Asian Business & Management.
Março de 2006, pp. 153-155.
2. Reh, F. John. Manager. About.com. [Online] 20 de Maio de 2008. [Citação: 13 de Novembro
de 2008.] http://management.about.com/od/policiesandprocedures/g/manager1.htm.
3. Nelson, Kate e Aaron, Stacy. Change Management No Longer Optional for Clients.
Management Consulting News. [Online] [Citação: 13 de Novembro de 2008.]
http://www.managementconsultingnews.com/articles/aaron_nelson_change.php.
4. Bray, Alec. The Enterprise Change Process. s.l. : Telelogic, 2008.
5. van Bon, Jan, et al. Foundations of IT Service Management Based on ITIL v3. Zaltbommel :
Van Haren Publishing, 2007. ISBN 978 90 8753 057 0.
6. Ewton, Zane. Change Management Theories: Models of change. Associated Content. [Online]
02 de 09 de 2006.
http://www.associatedcontent.com/article/56933/change_management_theories.html?cat=3.
7. Six Change Approaches - Kotter and Schlesinger. Value Based Management. [Online] 25 de 03
de 2008. http://www.valuebasedmanagement.net/methods_kotter_change_approaches.html.
8. Kotter's 8-Step Change Model. Mind Tools. [Online] 27 de 08 de 2008.
http://www.mindtools.com/pages/article/newPPM_82.htm.
9. Cellars, Tara. Change Management Models: A Look at McKinsey's 7-S Model, Lewin's Change
Management Model and Kotter's Eight Step Change Model. Associated Content. [Online] 10 de 05 de
2007.
http://www.associatedcontent.com/article/237685/change_management_models_a_look_at.html?page
=2&cat=3.
10. Havelock, Ronald G. Guiding Change in Special Education: How to Help Schools with New
Ideas and Practices. s.l. : Corwin Press, 2003. ISBN 0761939652, 9780761939658.
71
11. Towards Organizational Self-awareness - A Methodological Approach to Capture and
Represent Individual and Inter-Personal Work Practices. Vicente, David Miguel Rolo. 2007.
12. Zacarias, Marielba, et al. Towards Organizational Self-Awareness: An Initial Architecture and
Ontology. [autor do livro] Peter Rittgen. Handbook of Ontologies for Business Interaction. s.l. : Idea
Group Inc (IGI), 2007.
13. Making Sense of Enterprise Architecture as Tools of Organizational Self-Awareness (OSA).
Magalhães, Rodrigo, Zacarias, Marielba e Tribolet, José.
14. Vernadat, F. Enterprise modeling and integration: principles and applications. s.l. : Springer,
1996. ISBN 0412605503, 9780412605505.
15. Zachman, John A. Enterprise Arcthitecture: The Issue of the Century. Database
Programming and Design Magazine. 1997.
16. Pangaro, Paul. Organizational Modeling Defined - PANGARO Incorporated:. PANGARO
Incorporated. [Online] Organizational Modeling Defined - PANGARO Incorporated:.
http://www.pangaro.com/PI-Brochure/org-modelling-briefly.html.
17. Smith, E. What is Enterprise Modelling? Wisegeek. [Online] http://www.wisegeek.com/what-is-
enterprise-modelling.htm.
18. Perks, Col e Beveridge, Tony. Guide to Enterprise IT Architecture. s.l. : Springer, 2003. ISBN
0387951326, 9780387951324.
19. Group, The Open. Structure of the TOGAF Document. The Open Group. [Online]
http://www.opengroup.org/architecture/togaf8-doc/arch/chap01.html#tag_02_03.
20. The Zachman Framework Populated with Baseball Models. Bahill, Terry, Botta, Rick e
Daniels, Jesse. s.l. : Journal of Enterprise Architecture, 2006.
21. Directory, ITIL and ITSM. The Itil & ITSM World. What is ITIL? [Online] ITIL and ITSM
Directory, 30 de Maio de 2007. http://www.itil-itsm-world.com/what.htm.
22. van Bon, Jan. Introduction to ITIL. s.l. : The Stationery Office, 2005. ISBN 0113309732,
9780113309733.
72
23. Change Management - Introduction and Objectives. ITIL- IT Service Management. [Online]
OSIATIS S.A. .
http://itil.osiatis.es/ITIL_course/it_service_management/change_management/introduction_and_object
ives_change_management/introduction_and_objectives_change_management.php.
24. Applying Business Process Modeling To Organizational Change. Mendes, Ricardo, et al.
25. An Approach for Creating and Managing Enterprise Blueprints: A case for IT Blueprints.
Pereira, Carla, et al.
26. AS_IS Organizational Modeling - The problem of its dynamic management. Castela, Nuno e
Tribolet, José.
27. Representação AS_IS em Engenharia Organizacional. Castela, Nuno e Tribolet, José.
28. Um perfil para modelação de Arquitecturas dos Sistemas de Informação. Vasconcelos,
André, Sousa, Pedro e Tribolet, José.
29. Osvalds, Gundars. Use of UML 2.0 Diagrams for Systems Architecture Modeling. 2009
Embarcadero Technologies, Inc. [Online] http://conferences.embarcadero.com/article/32216.
30. Hewlett-Packard. ITIL Essentials for the IT Service Management. [Document] s.l. : Hewlett-
Packard Compay and Quint Wellington Redwood, 2001.
31. Tavassoli, Dominic. Five CIO Challenges Addressed by Better Change Management. [Paper]
s.l. : Telelogic, March 2008.
32. A Role-Based Framework for Business Process Modeling. Caetano, Artur, et al.
33. GOD-theory for organizational engineering: continuously modeling the coninuous
(re)Generation, Operation and Deletion of the enterprise. Aveiro, David, Silva, António Rito e
Tribolet, José.
34. Clemens, Paul, et al. Documenting Software Architectures: Views and Beyond. s.l. : Addison-
Wesley, 2003. ISBN: 0201703726, 9780201703726.
73
11. Anexos
11.1 Anexo 1: Processo de validação (Ciclo Geral)
Lista de
Mudanças
Pretendidas
(SHOULD_BE)
+
Validar
Alterações
Propostas
+
Actualização do
meta-modelo
+
Executar Gap
Analysis
Update
cenário AS_IS
Propor cenário
SHOULD_BE
Meta-
modelo
Cenário AS_IS não
corresponde à realidade
Impossibilidade de
representar a
mudança pretendida
Final
Início
Validação Mudança
Propor nova representação
SHOULD_BE = TRUE
Rever Alterações
Propostas = TRUE
Alterações Validadas = FALSE
Alterações Validadas = TRUE
Modelo
actualizado
Produz
Consome
ProduzConsome
Figura 43 - Ciclo Geral de Validação
74
11.2 Anexo 2: Processo de validação (Excepção não é possível representar a mudança)
Figura 44 - Excepção (caso não seja possível representar a mudança)
+
Actualização do
meta-modelo
Propor cenário
SHOULD_BE
Meta-
modelo
Impossibilidade de
representar a
mudança pretendida
Modelo
actualizado
Produz
Consome
75
11.3 Anexo 3: Validação (Excepção cenário AS_IS não representa à realidade)
Lista de
Mudanças
Pretendidas
(SHOULD_BE)
+
Executar Gap
Analysis
Update
cenário AS_IS
Cenário AS_IS não
corresponde à realidade
Produz
Figura 45 - Excepção (caso o cenário AS_IS não esteja alinhado com a realidade)
76
11.4 Anexo 4: Actualização do meta-modelo
Organização
Criador
Coordenador
Avaliador
Documento com
alterações a efectuar
ao
meta-modelo
Adicionar proposta
de regra ao histórico
Proposta aceite?
Solução aceite?
Regra de solução
encontrada?
Verificação
Histórico
Propor
alteração ao
meta-modelo
Análise da
regra existenteUpdate
meta-modelo
Meta-
modelo
Início actualização
meta-modelo
Fim
Proposta aceite
Não
Consome
Consome
Sim
Sim
Sim
Não
Produz
Não
Sim
Consome
Produz
Figura 46 - Processo de Actualização do meta-modelo
77
11.5 Anexo 5: Gap Analysis
2ª Fase
Lista de
Mudanças
Pretendidas
(SHOULD_BE)
Comparar
Cenários
Cenário
SHOULD_BECenário
AS_IS
FimInício Gap Analysis
Produz
ConsomeConsome
Figura 47 - Gap Analysis
78
11.6 Anexo 6: Processo de validação da mudança
Validação das alterações
+
Verificar existência
de solução
Lista de
Mudanças
pretendidas
(SHOULD_BE)
Conjunto de
alterações já
planeadas
(TO_BE)
Propor alteração da
representação
SHOULD_BE
Aceite?
Alterações planeadas permitem
executar mudança pretendida?
Aceite?
Gerar Blueprint
Report
Propor revisão
das alterações
propostas
Rever
alterações
propostas
+
Executar
validação
Proposta
de
alteração
Regras de
Validação
Fim
Alterações Validadas = FALSE
Fim
Executar gap analysis
Fim
Rever alterações
Fim
Alterações Validadas = TRUE
Início Validação
Consome
Produz
Utiliza
Não
Sim
Alterações planeadas
não permitem atingir o estado pretendido
Consome
Sim
Consome
Alterações não contempla
das no cenário SHOULD_BE
Não
Sim
Figura 48 - Processo de validação da mudança
79
11.7 Anexo 7: Documento detalhado da regra de solução
O histórico que apoia a organização no tratamento de acções não validadas deve conter um
conjunto de informações que considero importantes para no futuro compreender a origem da situação e
a forma da resolução encontrada. Assim as informações que consideramos relevantes são:
Informação Nota
Alteração não validada Nome da alteração não validada
Razões Descrição detalhada das razões da não
validação dessa alteração
Actores Intervenientes da análise, resolução e
proposta e respectiva função
Data de Resolução Datas relevantes na resolução da alteração
Solução encontrada Descrição detalhada da solução encontrada
Tabela 7 - Informação que compõe o documento detalhado
80
A informação aqui apresentada contribui de diversas formas a uma aprendizagem cada vez maior
por parte da organização e dos gestores que a constituem. Com a informação aqui apresentada,
proposta por [33], podemos obter informações relativas a:
Alteração não validada: Disponibiliza informações relativas ao tipo de comportamento
disfuncional que ocorreu, permitindo uma maior contextualização e percepção do problema em
si;
Razões: Descreve as razões da ocorrência de uma não validação. Esta informação permite
uma maior compreensão sobre as razões desta ocorrência, permitindo acrescentar notas
informativas (ex: adição de um novo departamento à organização não é validado devido ao
facto de aumentar consideravelmente a burocracia da organização);
Actores: Stakeholders que participam no processo de análise, resolução e proposta de
solução ao problema encontrado. Esta informação permite introduzir uma forma de
responsabilização pelas acções propostas.
Data de resolução: Introduz o conceito de tempo às alterações adicionadas ao histórico,
garantindo uma timeline o que permite uma melhor compreensão das regras adicionadas
melhorando consequentemente a compreensão das decisões tomadas pela organização
permitindo que as decisões sejam conscientes;
Solução encontrada: A descrição da solução apresentada servirá posteriormente para
optimizar a resposta da organização a um problema igual ou semelhante, permitindo uma
resposta rápida ao problema encontrado.
81
11.8 Anexo 8: Template utilizado para importação de cenário SHOULD_BE
Foi criado um novo tipo de importação que utilizará um novo ficheiro que representará o estado
SHOULD_BE. A imagem seguinte mostra um template desse mesmo ficheiro:
Action Type Name Subtype Values
Tabela 8- Template SHOULD_BE
Qual a semântica associada à estrutura deste ficheiro?
O template que define a estrutura, consiste na categorização da representação que o gestor
pretende ver implementada na organização. Este ficheiro irá definir o estado que o gestor pretende que
a empresa atinja após as alterações definidas. Assim a coluna “Action” definirá a acção a executar
(sendo esta uma das seguintes: CREATE, UPDATE ou DELETE), a coluna “Type” corresponderá ao
tipo do elemento que se pretende alterar (dentro do contexto do projecto, visto que é este artefacto
que, no KYE metamodel, permite efectuar alterações à estrutura da organização). Esta coluna poderá
definir propriedades do tipo:
Business Process;
Applications;
Components;
Platforms;
Informational Entities;
Projects;
Repository.
A coluna “name” corresponderá, tal como o nome indica, ao nome do artefacto. A coluna “subtype”
corresponde ao tipo dos sub-elementos do artefacto, cujo nome será preenchido com os valores
definidos em “values”.
Apresentamos como exemplo o seguinte cenário SHOULD_BE.
82
Figura 49 - Exemplo de cenário SHOULD_BE
83
11.9 Anexo 9: Exemplo Overall View
Components used by elements
Aligned Elements Not Aligned Elements
Actions
Components
Platforms
Actions
DeleteUpdateCreate
Applications
DeleteUpdateCreate
Components
Components
Applications
Platforms
Components
Applications
Platforms
Components
Applications
Platforms
Components
Applications
Platforms
Applications
Platforms
Components
Applications
Platforms
Office 2007 SP1
DOORSPlatform 4Platform 3
Component 2Component 1
Excel
Exploratory
Module
EA ClientDOORS
Integration
EA Client
Excel
Exploratory
Module
DOORS
Integration
Component 2Component 1
DOORS
Figura 50 - Exemplo Overall View
84
11.10 Anexo 10: Exemplos Specific View
Figura 52 - Exemplo de uma acção não validada
Component Component 1
SubComponents
Action
Platforms
Solution Proposed
Components
Applications
Platform 3
Assign a project
CREATE
85
Figura 53 - Exemplo de uma acção validada
Application DOORS
SubComponents
Components
Action
Solution Proposed
Platforms
Applications
Component 2Component 1
Excel
Exploratory
Module
EA ClientDOORS
Integration
Assign a project
CREATE
86
11.11 Anexo 11: Casos de teste fictícios
Figura 54 - Caso de teste: Criar uma aplicação
87
Figura 55 - Caso de teste: Criar uma aplicação e modificar outra
88
11.12 Anexo 12 : Verificar existência de solução
Organização
Avaliador
Coordenador
Criador
Documento
detalhado da
regra de
solução
Base de
Dados de
acções de
resolução
Solução aceite?
Regra de solução encontrada?
Análise
alteração não
validada
Propor update
das alterações
planeadas
Adicionar regra
ao histórico
Propor regra de
solução
Verificação
Histórico
Proposta
de
alteração
Início Verificação
de solução
Fim
Produz
Produz
Consome
Não
Sim
Não
Produz
Utiliza
Figura 56 - Processo de verificação de existência de solução
![[AS] Arquitecturas del Sur, 2012, Nº 41, p. 42-53 La ...[AS] Arquitecturas del Sur, 2012, Nº 41, p. 42-53 La celebración del HanalPixán en el sureste mexicano. Transformaciones](https://static.fdocumentos.com/doc/165x107/5eaee84c2f86583b74094b18/as-arquitecturas-del-sur-2012-n-41-p-42-53-la-as-arquitecturas-del.jpg)
![Juhani Pallasmaa [AS] Arquitecturas del Sur, 2009, Nº … · [AS] Arquitecturas del Sur, 2009, Nº 36, p.80-93 Tocando el Mundo – espacio vivencial, visión y hapticidad](https://static.fdocumentos.com/doc/165x107/5b8465fd7f8b9a784a8c333a/juhani-pallasmaa-as-arquitecturas-del-sur-2009-no-as-arquitecturas-del.jpg)
