arquitectura tecnológica de sistemas de informação ... · arquitectura de sistemas de...

Arquitectura Tecnológica de

Sistemas de Informação Empresariais

Plano da Disciplina

Edição de Setembro 2003

Pedro Sousa ([email protected])

Ricardo Mendes ([email protected])

Departamento de Engenharia Informática Instituto Superior Técnico

Relatório da disciplina Arquitectura Tecnológica de Sistemas de Informação

2 DE 96


3 DE 96

Índice

1 Introdução ........................................................................ 7

2 Justificação e Objectivos................................................... 9

3 Enquadramento.............................................................. 16

3.1 Enquadramento Científico .............................................................. 16

3.2 Enquadramento na Área Científica de SI ....................................... 22

3.3 Enquadramento no ensino Graduado e Pós-Graduado .................. 24 3.3.1 Área de Especialização em Sistemas de Informação Empresariais ....................26 3.3.2 Área de Especialização em Programação e Sistemas de Informação................27

3.4 Enquadramento na realidade das Organizações............................. 28

4 Programa........................................................................ 30

4.1 Introdução ....................................................................................... 31

4.2 Organizações................................................................................... 32

4.3 Arquitectura de Sistemas de Informação ....................................... 33

4.4 Arquitectura Aplicacional ............................................................... 34

4.5 Arquitectura Tecnológica............................................................... 35

4.6 Arquitectura de Soluções Standards .............................................. 36

5 Organização e Plano de Aulas ....................................... 38

6 Elementos de Estudo....................................................... 49

7 Orientações Pedagógicas ................................................ 53

8 Avaliação de Conhecimentos.......................................... 57

8.1 Formas da Avaliação ....................................................................... 57 8.1.1 Avaliação através dos Trabalhos..........................................................................58 8.1.2 A avaliação através do Exame ................................................................................58

8.2 Calendarização do Esforço dos Alunos .......................................... 59

9 Experiência Adquirida nas Edições Anteriores.............. 61


4 DE 96

9.1 Experiência relativa aos Trabalhos ................................................ 61

9.2 Experiência relativa ao programa da Disciplina............................. 64

9.3 Inquéritos aos Alunos..................................................................... 64

10 Referências................................................................... 67

Anexo I – Notas das Edições Anteriores ............................... 69

Anexo II – Exames das Edições Amteriores......................... 72

Anexo III- Exemplo de um Trabalho .................................. 82


5 DE 96


6 DE 96

Abreviaturas usadas neste documento:

• ACM - Association for Computing Machinery

• AIS - Association for Information Systems

• AOSIE – Arquitectura Organizacional de Sistemas de

Informação Empresariais (disciplina)

• ATSI– Arquitectura Tecnológica de Sistemas de

Informação. (disciplina)

• DEI – Departamento de Engenharia Informática.

• LEIC – Licenciatura em Engenharia Informática e de

Computadores.

• LESIM – Licenciatura em Engenharia de Sistemas de

Informação e Multimédia.

• GEP - Gabinete de Estudos e Planeamento

• MEIC – Mestrado em Engenharia Informática e de

Computadores.

• POSI – Pós Graduação em Sistemas de Informação.

• SI – Sistemas de Informação.


7 DE 96

1 Introdução

Este documento constitui o relatório da disciplina de Arquitectura

Tecnológica de Sistemas de Informação, doravante designada pela sigla

ATSI. Actualmente, esta disciplina corresponde às seguintes duas

disciplinas do ensino graduado:

• À disciplina de Arquitectura Tecnológica de Sistemas de

Informação leccionada no 5º ano da LEIC (Licenciatura em

Engenharia Informática e Computadores) do DEI, no polo

da Alameda. Esta é uma disciplina leccionada no 2º

semestre desde o ano lectivo de 1999/2000.


Informação Empresariais leccionada no 4º ano da LESIM

(Licenciatura em Engenharia de Sistemas de Informação e

Multimédia), do DEI, no polo do Tagus Park. Esta disciplina

será ministrada pela primeira vez no 1º semestre do ano

lectivo de 2003/2004.

Relativamente ao ensino pós-graduado, a disciplina de ATSI

corresponde também:


Informação do Mestrado em Engenharia Informática e de

Computadores (MEIC), leccionada no 2º semestre.

• À disciplina de Sistemas de Informação Empresariais,

leccionada no 3º semestre da Pós graduação em

Sistemas de Informação (POSI) do DEI, embora de uma

forma condensada.

A escolha da disciplina apresentada neste relatório teve o

seguintes propósitos:


8 DE 96

• Apresentar uma disciplina que seja inequivocamente

central à Área Científica de Sistemas de Informação.

• Apresentar uma disciplina que explicite e traduza uma

posição do candidato perante a Área Científica de

Sistemas de Informação.

• Dar continuidade à experiência pedagógica adquirida nos

últimos quatro anos.

• Dar consistência à experiência adquirida ao longo de seis

anos de projectos de realização de Arquitecturas de

Sistemas de Informação em Organizações reais.

• Apresentar uma disciplina que tenha sido proposta ou

significativamente re-estruturada pelo candidato.

Em conformidade com estes propósitos, este relatório apresenta a

disciplina de ATSI desdobrada nos seguintes tópicos, cada um abordado

num capítulo próprio:

• Justificação e Objectivos

• Enquadramento

• Programa

• Organização e Plano de Aulas

• Elementos de Estudo

• Orientações Pedagógicas

• Avaliação de Conhecimentos

• Experiência Adquirida nas Edições Anteriores

• Referências


9 DE 96

2 Justificação e Objectivos

Dotar uma organização dos sistemas de informação adequados -

ao seu negócio e à própria organização - é uma tarefa complexa

envolvendo inúmeras variáveis, todas elas podendo contribuir para o

insucesso deste processo. Entre as situações mais frequentes,

podemos enumerar as seguintes:

• A implementação do sistema foi um processo demasiado

longo, não sendo compatível com a constante evolução da

organização. O sistema entrou em permanentes

alterações, ou deixou mesmo de ser útil, antes de entrar

em produção.

• O sistema faz o que foi solicitado pelo cliente mas não faz

tudo o que devia fazer para entrar em produção na

organização.

• O sistema foi feito e entregue como especificado mas os

utilizadores continuam a usar o sistema antigo.

• O sistema precisa de informação que não lhe pode ser

fornecida, tornando-se por isso inoperante.

• O sistema é mais um dos sistemas existentes na

organização que contém informação redundante e

inconsistente.

• O sistema automatiza e acelera partes de um processo,

mas o impacto na globalidade do processo é desprezável.

• O sistema duplica funcionalidades de outros que já existem

na organização.

• O sistema usa tecnologias alternativas a outras existentes


10 DE 96

noutros sistemas na organização.

• Para funcionar o sistema implica novos e significativos

investimentos ao nível da integração com outros sistemas

Todas estas situações podem acontecer independente da

concepção e desenvolvimento do sistema de informação ter sido

brilhantemente executada. Estas situações são frequentes, e resultam

fundamentalmente da falta de uma visão abrangente que assegure que

os requisitos do sistema e os da organização sejam mutuamente

compatíveis. Identificar e analisar estes factores de compatibilidade

entre os sistemas e a organização é o assegurar o alinhamento entre a

Arquitectura de Sistemas de Informação e a Arquitectura Empresarial.

Em muitas situações de desalinhamento entre os sistemas e a

organização é frequente dizer-se que os “requisitos” do sistema não

foram bem especificados por parte dos elementos da organização

cliente responsáveis pelo projecto. Para um profissional de sistemas de

informação, é evidente que o “cliente” não sabe, nem deve saber, como

especificar com o detalhe necessário os sistemas que precisa. Cabe ao

profissional usar as práticas e os métodos adequados de forma a

assegurar cenários possíveis e coerentes. Cabe ao profissional

identificar as variáveis que têm que ser tidas em conta para que os

sistemas estejam adequados à organização. Por outras palavras, cabe

ao profissional garantir que Arquitectura de Sistemas de Informação está

alinhada com a Arquitectura Empresarial.

É este o problema central da disciplina de ATSI, e é certamente

um problema da engenharia informática.

Desta forma, o objectivo principal da disciplina de ATSI é:

Dotar os alunos dos conhecimentos necessários à realização de uma Arquitectura de Sistemas de Informação numa Organização.

Ou, por outras palavras, ensinar os alunos responder à questão:


11 DE 96

Que sistemas são adequados a esta Organização e com este Negócio?

Os conhecimentos necessários à realização de uma Arquitectura

de Sistemas de Informação numa Organização estruturam-se em 4

grandes áreas:

1ª Área: A da caracterização do problema que se pretende

resolver. Como as organizações são uma parte importante

do problema, saber caracterizar e modelar os aspectos

relevantes das organizações é fundamental para estruturar

o problema e encontrar as soluções adequadas.

2ª Área: A das ferramentas e dos métodos de construção de

Arquitecturas de Sistemas de Informação. Como os

sistemas propostos na Arquitectura de Sistemas de

Informação devem estar devidamente enquadrados na

organização, é necessário estudar também as ferramentas

e os métodos de construção de Arquitecturas

Empresarias, bem como os métodos de alinhamento entre

estas duas arquitecturas.

3ª Área: A da engenharia de concepção, desenvolvimento e

integração de Sistemas de Informação.

4ª Área: A do conhecimento das soluções disponíveis no

mercado. A informatização das organizações passa em

larga medida por usar produtos/soluções disponíveis no

mercado. Desta forma, é importante que os alunos tenham

uma noção do tipo de produtos/soluções podem considerar

na arquitectura que propõem.

O foco da disciplina de ATSI é a 2ª área: Arquitecturas de

Sistemas de Informação e Arquitecturas Empresariais. Conduto, para


12 DE 96

que este possa ser exercitado, é necessário que os alunos tenham os

conhecimentos mínimos das restantes áreas.

A 3ª área, é o foco de todo um conjunto de várias áreas Científicas

do DEI, estando cabalmente abordado pelas respectivas disciplinas, em

particular as disciplinas da área de Arquitectura e Sistemas Operativos

e da área de Metodologia e Tecnologia da Programação, bem como as

disciplinas de “Base de Dados e Análise” e “Concepção de Sistemas de

Informação” da área de Sistemas de Informação.

Pelo contrário, a 1ª e a 4ª área não estão suficientemente cobertas

nas licenciaturas do DEI, deixando algumas lacunas no conhecimento

dos alunos.

Tendo em conta este contexto e o enquadramento da disciplina de

ATSI na licenciatura, analisado em detalhe no capítulo seguinte, a

prossecução do objectivo global da disciplina de ATSI implica atingir os

seguintes objectivos parciais:

1º Objectivo: Que os alunos percebam o conceito de Arquitectura

de Sistemas de Informação e o conceito de

Arquitectura Empresarial, bem como as

dependências e os pontos de alinhamento entre

estes conceitos. Este conhecimento passa pela

identificação e compreensão das seguintes

Arquitecturas:

a. Arquitectura de Negócio. Identificação e

estruturação dos processos de negócio da

organização.

b. Arquitectura de Informação. Identificação,

estruturação e caracterização da informação

necessária à execução dos processos de negócio.

c. Arquitectura de Aplicações. Identificação,

estruturação e caracterização das Aplicações


13 DE 96

(Sistemas de Informação) a desenvolver para

suportar o negócio e a gestão da Informação

descritas nas arquitecturas anteriores.

d. Arquitectura Tecnológica. Identificação dos

componentes tecnológicos necessários a cada

aplicação, bem como a identificação dos

componentes tecnológicos que devem ser

transversais a todas as aplicações.

2º Objectivo: Que os alunos tenham um conhecimento mínimo das

organizações reais, para que consigam compreender

e modelar os problemas que se propõem resolver.

3º Objectivo: Que os alunos tenham um conhecimento mínimo das

soluções e tecnologias existentes no mercado, para

que possam propor soluções eficazes, e que não se

fundamentem exclusivamente em desenvolvimentos

à medida.

De forma a assegurar estes objectivos, a disciplina de ATSI, inclui

os módulos apresentados na tabela apresentada na página seguinte.


14 DE 96

Tabela I - Justificação do Conteúdo da disciplina de ATSI

Objectivos de ATSI

Módulos de ATSI Objectivos dos Módulos

Todos Introdução • Motivação para a disciplina

• Caracterização do tipo de problemas que se pretendem evitar/resolver

1º Organizações • Caracterização das diferentes áreas

e tipos das organizações.

• Visão geral dos principais processos de negócio e das respectivas necessidades de informação.

• Análise detalhada de alguns processos de negócio.

Arquitectura Empresarial e

Arquitectura de Sistemas de

Informação

• Métodos e ferramentas para o desenvolvimento de Arquitecturas Empresariais e Arquitecturas de Sistemas de Informação. Arquitectura de Negócio e de Informação.

Arquitectura de Aplicações • Apresentar e caracterizar os

diferentes tipos de Sistemas de Informação, focando os respectivos aspectos arquitecturais.

• Apresentar os métodos de determinação e caracterização das aplicações que suportam o negócio a gestão da informação.

2º

2.a,b

2.c

2.d

Arquitecturas Tecnológicas • Apresentar e caracterizar os

diferentes componentes de uma Arquitectura Tecnológica de Sistemas de Informação.

3º Arquitecturas de Soluções

Standards

• Conhecimento e análise das arquitecturas de soluções B2B, B2C, B2E, CRM e ERPs

• Aplicação a casos concretos

Todos Consolidação • Revisão e consolidação das

matérias


15 DE 96


16 DE 96

3 Enquadramento

O enquadramento desta disciplina deve ser analisado sob

diferentes aspectos, nomeadamente os seguintes:

• O científico.

• O do alinhamento com as orientações estratégicas da Área

Científica de Sistemas de Informação.

• O dos programas dos restantes disciplinas da licenciatura

• O da relevância para a resolução de problemas reais das

organizações.

3.1 Enquadramento Científico

O enquadramento científico da disciplina é perceptível através da

análise de um documento “Model Curriculum and Guidelines for

Graduate Degree Programs in Information Systems”, da

responsabilidade da Association for Computing Machinery (ACM) e da

Association for Information Systems (AIS) [MSIS2000], documento que

consideramos uma referência incontestável nesta matéria.

O currículo expresso neste documento para a graduação em

Sistemas de Informação estrutura-se nas seguintes áreas (transcritas

na Tabela II) :

• Foundations - Um conjunto de conhecimento de base em:

o em Sistemas de informação

o em áreas de Negócio e Organizações

• IS Core - Um núcleo de Sistemas de Informação, o qual


17 DE 96

inclui a principal formação em Sistemas de Informação e a

visão integrada destas matérias.

• Career Electives - Áreas de especializações em função

das diferentes especializações profissionais.

Tabela II- Estrutura do Curriculum Information Systems do ACM

Foundations

IS

Foundations

Business

Foundations

IS Core

Career Electives

• Fundamental

s

of IS

• IT Hardware

and Software

• Programming

,

Data and Object

Structures

• Financial

• Accounting

• Marketing

• Customer

Focus

• Organizationa

l Behavior

•Data management

•Analysis,

modeling, and

design

•Data

communications

and networking

• Project and

change

management

• IS policy and

strategy

Integration

• Consulting

• Decision Making

•Electronic Commerce

•Enterprise Resource

Planning

• Globalization

• Human Factors

•Knowledge

Management

• Managing the IS

Function

•Project Management

• Systems Analysis and

Design

•Technology

Management

• Telecommunications

Após a aprendizagem das matérias do “IS core”, existe a

necessidade da sua síntese e integração. É pertinente salientar que nas

versões anteriores deste currículo, a integração não aparecia de forma

explícita. No currículo actual, a necessidade de integração de

conhecimentos é apresentada como uma mais valia importante do

curriculum. Esta integração de conhecimento dá-se em 3 perspectivas:


18 DE 96

o Integrating the Enterprise

o Integrating the IS Function

o Integrating IS Technologies

Na Tabela III apresenta-se o texto original introdutório a cada um

destas perspectivas.

Tabela III - Perspectivas da Integração do Curriculum IS do ACM

Integrating the

Enterprise.

This course is oriented toward what to build, not how to build it. It focuses on organizational and managerial issues at the level of the enterprise as a whole. Its objectives are to

• provide an integrated view of the firm and its relations with suppliers and customers

• demonstrate an integrated set of business processes and functional applications that meet business needs

Integrating the

IS Function.

This course focuses on managing IS functions on a day-to-day basis. Its objectives are to

• design effective/efficient IS organizational processes

• assess the impact of emerging technologies

• define human resource needs and management methods

• IS governance alternatives

• define the role of the CIO

• apply methods to measure and demonstrate the value of IS

Integrating IS

Technologies.

This course is concerned with how to develop an integrated IS enterprise architecture including

• evaluate and select from architectural and platform choices, priorities, and policies

• assessment of the impact of emerging technologies

• evaluate the role of standards

• evaluate effect of vendor strategies

A disciplina de ATSI tem o foco na perspectiva equivalente à

“integrating the Enterprise”, partilhando o objectivo de ensinar os alunos

a determinar que sistemas devem ser feitos e não como é que estes

devem ser feitos. Contudo existem também alguns tópicos comuns com

a perspectiva “Integrating IS Technologies”, em particular as matérias do

módulo de Arquitecturas Tecnológicas de ATSI.


19 DE 96

Analisando com mais detalhe o currículo proposto para a

perspectiva equivalente à “integrating the Enterprise”, apresentado na

Tabela IV, e comparando-o com os programa proposta para a disciplina,

apresentado no capítulo 4-Programa , é possível constatar inúmeros

pontos de alinhamento, evidenciando a semelhança dos objectivos e

tópicos abordados.

Tabela IV- Descrição do Módulo Integrating the Enterprise

CATALOG

Information systems role in transforming organizations and industries. An integrated view of the organization from an external and internal perspective. IS’s internal role in integrating the enterprise through a cohesive set of business processes and functional applications to meet business needs. Enterprise resource planning and enterprise functionality. Collaborative systems. Consideration of external relations with suppliers, outsourcers, and customers

OBJECTIVES

Understand:

• The configuration of business processes that are necessary to run the corporation and their relationships with legacy systems and other functional applications

• How to design an application architecture to provide the information needed for decision making and knowledge management

• How IS can enable new organizational forms

• The concept and major components of a typical enterprise-wide conceptual database

• The concept of ERP and how it is implemented in business processes

• The role of collaborative systems in developing more flexible, fast response organizations.

TOPICS

Organizational needs for integration and flexibility

• Overview of a typical “business architecture”

• The role and content of an enterprise conceptual data model

• Generic business processes

• Business process reengineering

• The integration of business, ERP functions/applications

• ERP trends and major vendors of software and services

• Interorganizational systems (supply chain and EDI)

• Collaborative systems and knowledge management


20 DE 96


21 DE 96

Existem no entanto várias diferenças que importa realçar, sendo a

sua análise feita de seguida:

• O facto da disciplina de ATSI incluir no seu programa

matérias que no Curriculum do ACM estão ao nível do

Bussiness Foundation.

• O facto da disciplina de ATSI incluir uma forte componente

sobre as metodologias e ferramentas usadas na definição

de Arquitectura de Sistemas de Informação, algo que não

está explícito no programa curricular do ACM.

• O facto da disciplina de ATSI abordar os sistemas B2B,

B2C, B2E, CRM, DW, e ERPs com igual relevância,

enquanto que o programa curricular do ACM tende a estar

mais focado nos ERPs.

A primeira diferença justifica-se pela necessidade de mitigar as

lacunas que os alunos têm nestas áreas. No curriculum da LEIC,

apenas na disciplina de Arquitectura Organizacional de Sistemas de

Informação Empresariais (AOSIE) são abordados matérias

correspondentes ao Bussiness Foundation, nomeadamente ao nível do

“Organizational Behavior” e “Costumer Focus”. Esta disciplina é também

fundamental na preparação dos alunos para compreender e discutir

com algum detalhe as matérias dadas em ATSI, como por exemplo os

processos de negócio

As restantes diferenças resultam da postura da disciplina de ATSI

perante o problema da Arquitectura de Sistemas de Informação.

Na disciplina de ATSI, os métodos de identificação das aplicações

que optimizam simultaneamente a automação dos processos de

negócio e a gestão da informação, produzem soluções “óptimas”, não

condicionadas por outros factores que não sejam o Negócio e a


22 DE 96

Informação. Posteriormente, há que considerar outros factores, como a

realidade informática da organização e a realidade do mercado de

soluções/produtos informáticos, entre outros factores. Cada uma das

aplicações identificadas na Arquitectura de Sistemas de Informação

poderá ser implementada por:

• Parametrização de soluções/produtos comerciais.

• Desenvolvimento à medida.

• Re-engenharia das soluções já existentes na organização.

Nesta aproximação, o ERP e as soluções B2B, B2C, B2E, CRM e

DW aparecem como possíveis implementações das aplicações

identificadas e definidas previamente na arquitectura. No curriculum do

ACM, adopta-se uma postura mais centrada num ERP, à volta do qual

se vai integrando as restantes soluções, nunca se chegando a ter a

visão “óptima”.

Independentemente da melhor ou pior eficácia de cada uma das

aproximações, julgamos que a seguida na disciplina de ATSI é

claramente mais adequada à formação de um engenheiro e à postura

de uma escola de Engenharia como é o IST.

3.2 Enquadramento na Área Científica de SI

A Área Científica de Sistemas de Informação deve assegurar a

formação de Engenheiros Informáticos profissionais em Sistemas de

Informação. As áreas de formação que um profissional em Sistemas de

Informação deverá ter está bem patente no texto do currículo definido

pelo ACM para o ensino graduado de Sistemas de Informação [MSIS

2000], que aqui transcrevemos:

“Information systems professionals work with information

technology and must have sound technical knowledge of computers,

communications, and software. Since they operate within organizations

and with organizational systems, they must also understand

organizations and the functions within organizations (accounting, finance,


23 DE 96

marketing, operations, human resources, and so forth). They must

understand concepts and processes for achieving organizational goals

with information technology. The academic content of an information

systems degree program therefore includes information technology,

information systems management, information systems development

and implementation, organizational functions, and concepts and

processes of organizational management”

A Área Científica de Sistemas de Informação inclui um conjunto de

disciplinas que podemos agregar em duas grandes áreas:

• Disciplinas em que o objecto de estudo são os “ internals”

dos sistemas, focando-se na a concepção,

desenvolvimento e integração de sistemas de informação,

• Disciplinas em que o objecto de estudo é a relação entre

as organizações e os sistemas. Uma destas disciplinas, a

AOSIE1, foca a missão, gestão, objectivos e valor dos

sistemas de Informação nas organizações, muito na linha

das orientações da área Integrating the IS Function, tal

como apresentado na Tabela III. A outra disciplina, a ATSI,

foca a identificação e a caracterização dos sistemas a

implementar, como vimos.

A análise aos programas das disciplinas da Área de Sistemas de

Informação permite evidenciar que as disciplinas de AOSIE e ATSI são

as únicas a abordar de forma sistemática as organizações como

objecto de estudo, a primeira sob uma perspectiva da estratégica e da

gestão da sua informatização e a segunda sob a perspectiva da

concepção da sua informatização.

Neste contexto, e tendo em conta que AOSIE antecede ATSI, o

enquadramento da disciplina de ATSI na Área Científica de Sistemas de

1 Arquitectura Organizacional de Sistemas de Informação Empresariais.


24 DE 96

Informação é total, tal como o é relativamente ao currículo MSIS2000.

3.3 Enquadramento no ensino Graduado e Pós-Graduado

Tal como mencionado no início deste documento (página 7), a

disciplina de ATSI é actualmente leccionada em duas licenciaturas, no

5º ano da LEIC e no 4º ano da LESIM, e em duas pós-graduações, no

MEIC e no POSI.

Este cenário está mudar com a implementação da re-estruturação

em curso e definida em [DEI 2010]. O DEI concluiu em 2002 uma

revisão das suas Licenciaturas com vista a dar resposta a uma série de

desafios importantes, tanto no âmbito da racionalização de recursos

internos, como no âmbito das matérias disciplinares, fazendo face às

constantes tendências da evolução tecnológica. Neste sentido

consideramos relevante enquadrar o posicionamento da disciplina de

ATSI nesta reflexão colectiva sobre a evolução do ensino graduado no

DEI e IST.

Nesta re-estruturação, as licenciaturas LESIM e LEIC aparece

como uma única licenciatura, cujo currículo está estruturado em quatro

níveis, de acordo com o seguinte esquema:

Área deEspecialização

Principal


Secundária

TroncoComum

IST

TroncoComum

DEI

Pós Graduação


Principal


Secundária

TroncoComum

IST

TroncoComum

DEI

Pós Graduação

As disciplinas do troco comum do IST são fundamentalmente as

de Matemática e as de Física. As disciplinas do tronco comum DEI


25 DE 96

constituem a formação base da Engenharia Informática, sendo

constituído maioritariamente por disciplinas focadas na engenharia da

programação, das interfaces, das redes e comunicações, dos sistemas

operativos, dos algoritmos e na computação.

No que diz respeito aos Sistemas de Informação, estas disciplinas

visam responder à questão “como fazer Sistemas de Informação”, em

particular as disciplinas da Área Científica de Metodologia e Tecnologia

da Programação, como a disciplina “Engenharia de Software”, e a

disciplina de “Base de Dados”, da Área Científica de Sistemas de

Informação.

A disciplina de “Organização e Gestão de Empresas” destaca-se

do tronco comum DEI por ser a única da Área Científica de Gestão e

Economia. O objectivo desta disciplina é fornecer conhecimentos

básicos de organização e gestão de empresas. Esta disciplina irá

certamente colmatar muitas as lacunas que os alunos têm no

conhecimento das organizações. Em conjunto com a disciplina de

AOSIE, estas disciplina dão aos alunos uma sólida base de “Bussiness

Foundation” do [MSIS2000], preparando-os para a disciplina de ATSI2.

Sobre este tronco comum de Engenharia Informática, seguem-se

as Áreas de Especializações, duas das quais incluem disciplinas da

Área Científica de Sistemas de Informação: a especialização em

Sistemas de Informação Empresariais e a especialização em

Programação e Sistemas de Informação.

2 Obviamente que estas disciplinas (Organização e Gestão de Empresas e AOSIE) têm objectivos próprios que ultrapassam largamente a preparação dos alunos para ATSI.


26 DE 96

3.3.1 Área de Especialização em Sistemas de Informação Empresariais

No quadro seguinte apresentamos as disciplinas da Área de

Especialização em Sistemas de Informação Empresariais.

Tabela V - Disciplinas da Área de Especialização de SI Empresariais

Área de Especialização de

Sistemas de Informação Empresariais

Área Científica Disciplina

Sistemas de Informação ANÁLISE E CONCEPÇÃO DE SISTEMAS DE

INFORMAÇÃO

ARQUITECTURA ORGANIZACIONAL DE

SISTEMAS DE INFORMAÇÃO EMPRESARIAIS

ARQUITECTURA TECNOLÓGICA DE SISTEMAS

DE INFORMAÇÃO EMPRESARIAIS

SOLUCÕES EMPRESARIAIS INTEGRADAS

Inteligência Artificial SISTEMAS DE APOIO À DECISÃO

A disciplina de ATSI aparece nesta re-estruturação da Licenciatura

com a designação de Arquitectura Tecnológica de Sistemas de

Informação Empresariais, herdando o nome que tinha na LESIM - Tagus

Park. Contudo, para evitar redundância de nomes, e por se tratar da

mesma disciplina, continuaremos a usar a sigla ATSI para designar esta

disciplina.

Como vimos, o focos da disciplina de ATSI é responder à questão

“Que sistemas devem ser feitos nesta organização?”, e é a única

disciplina com este propósito. De uma forma simplificada, e por isso

mesmo imprecisa, podemos considerar que a principal questão


27 DE 96

respondida em cada disciplina desta Área de Especialização é:

• “Análise e Concepção de Sistemas de Informação” - Como fazer os Sistemas ?.

• “Arquitectura Tecnológica de Sistemas de Informação Empresariais” - Que Sistemas fazer?

• “Arquitectura Organizacional de Sistemas de Informação Empresariais” - Como gerir os Sistemas e a função Informática ?

• “Soluções Empresariais Integradas” - Como integrar os Sistemas ?

• “Sistemas de Apoio à Decisão” – Como inferir conhecimento a partir da informação existente?

Desta forma, e no sentido em que o foco da disciplina de ATSI é

complementar ao das restantes disciplinas, consideramos que ATSI

está perfeitamente enquadrada no conjunto de disciplinas da

especialização em Sistemas de Informação Empresariais, bem como

na Área Científica de Sistemas de Informação.

3.3.2 Área de Especialização em Programação e Sistemas de Informação

Relativamente à Área de Especialização Programação e Sistemas

de Informação, e por limitação do número de disciplinas, foi incluído

apenas uma disciplina da Área Científica de Sistemas de Informação,

designada por “Sistemas de Informação Empresarias”. A apresentação

desta disciplina neste relatório justifica-se apenas pela clarificação dos

pontos comuns com a disciplina de ATSI.

A disciplina de “Sistemas de Informação Empresarias” tem como

objectivo dar uma visão da integração e da implementação dos

sistemas de informação nas organizações, começando pela

Arquitectura de Sistemas de Informação, passando pela Gestão dos

Sistemas de Informação e pela Gestão da Função Informática dentro da

organização.


28 DE 96

Em termos de conteúdos programáticos, esta disciplina resulta

fundamentalmente da fusão dos programas das disciplinas de AOSIE e

de ATSI.

Do programa de ATSI, serão leccionadas as matérias relativas às

noções de Arquitectura de Sistemas de Informação e de Arquitectura

Empresarial, mas numa perspectiva mais focada na compreensão e

utilização do que na concepção, para a qual seria necessário um foco e

uma componente prática extensa, que não é possível dados os

objectivos desta disciplina.

3.4 Enquadramento na realidade das Organizações

No relatório de 2001 “Critical Issues of Information Systems

Management” da Computer Sciences Corporation [CIISM 2001],

podemos constatar que as duas questões consideradas mais críticas

pelos responsáveis da “Information Technologies” são precisamente:

• “Optimizing Enterprise-wide IS Services”, no sentido em

que deverá existir maior partilha e reutilização dos

Sistemas de Informação pelas várias áreas das

organizações.

• “Optimizing Organizational Effectiveness”, no sentido em

que a constante evolução dos Processos de Negócio faz

com que os sistemas de informação esteja quase sempre

desalinhados com as necessidades do negócio e dos

processos de negócio.

A análise destas questões e o estudo das soluções possíveis

estão na origem e na motivação dos conceitos de Arquitectura

Empresarial e Arquitectura de Sistemas de Informação. O propósito de

conceber uma Arquitectura de Sistemas de Informação é precisamente

resolver estas questões, para além de outras.


29 DE 96

Neste contexto, a disciplina de ATSI revela-se também pertinente

no panorama dos temas que mais preocupam os responsáveis pela

Informática e Tecnologias de Informação das organizações.


30 DE 96

4 Programa

O programa proposto para esta disciplina estrutura-se num

conjunto de módulos, cada um dando resposta a um dos objectivos da

disciplina, tal como podemos constatar na Tabela I (página 14) que aqui

replicamos para comodidade da leitura:

Cópia da Tabela I - Justificação do Conteúdo da disciplina de ATSI

Objectivos de ATSI

Módulos de ATSI Objectivos dos Módulos

Todos Introdução • Motivação para a disciplina

• Caracterização do tipo de problemas que se

pretendem evitar/resolver

1º Organizações • Caracterização das diferentes áreas e tipos das

organizações.

• Visão geral dos principais processos de negócio

e das respectivas necessidades de informação.

• Análise detalhada de alguns processos de

negócio.

Arquitectura Empresarial e

Arquitectura de Sistemas de

Informação

• Métodos e ferramentas para o desenvolvimento

de Arquitecturas Empresariais e Arquitecturas

de Sistemas de Informação. Arquitectura de

Negócio e de Informação.

Arquitectura de Aplicações • Apresentar e caracterizar os diferentes tipos de

Sistemas de Informação, focando os respectivos

aspectos arquitecturais.

• Apresentar os métodos de determinação e

caracterização das aplicações que suportam o

negócio a gestão da informação.

2º

2.a,b

2.c

2.d Arquitecturas Tecnológicas • Apresentar e caracterizar os diferentes

componentes de uma Arquitectura Tecnológica

de Sistemas de Informação.

3º Arquitecturas de Soluções

Standards

• Conhecimento e análise das arquitecturas de

soluções B2B, B2C, B2E, CRM e ERPs

• Aplicação a casos concretos

Todos Consolidação • Revisão e consolidação das matérias


31 DE 96

De seguida apresentamos o detalhe programático de cada

módulo, em secções próprias.

4.1 Introdução

Como vimos este módulo tem dois grandes objectivos: (i) motivar

os alunos para a disciplina e (ii) caracterizar os problemas mais

frequentes da realidade informática das organizações. Estes dois

objectivos são também determinantes para os alunos estabelecerem as

expectativas e os objectivos que devem atingir após a conclusão desta

disciplina.

A motivação é feita através da análise de uma série de erros

típicos e do respectivo impacto nas organizações. O estabelecimento

das expectativas é feito simultaneamente, ficando os alunos com a clara

noção dos problemas e situações que deverão saber ultrapassar após a

conclusão da disciplina.

Os tópicos a desenvolver são:

o Evolução dos Sistemas de Informação nas Organizações. § A Formação, Proliferação, Dispersão e Unificação

o Arquitecto, Arquitectura e Arquitectura de Sistemas de

Informação. § Missão de um Arquitecto e da Arquitectura. § Requisitos de uma Arquitectura

o A Estrutura Organizacional e os Sistemas de Informação § A evolução da Estrutura Organizacional e a evolução dos

Sistemas de Informação § Processos de Negócio e Sistemas de Informação

o Dados, Informação e Sistemas de Informação. § Os Dados como património das Organizações § Independência dos Dados face aos Sistemas de

Informação § O que é a Arquitectura de Informação e de Sistemas de


32 DE 96

Informação § Aplicações, Programas e Sistemas de Informação. § A Variância dos Processos de Negócio e Invariância da

Arquitectura de Informação.

4.2 Organizações

O principal objectivo deste segundo módulo é dar aos alunos uma

caracterização das diferentes das organizações, para que estes

possam compreender a adequabilidade das diferentes soluções

informáticas a cada organização.


o Introdução aos Tipos de Organizações

§ Industriais

§ Grossistas/Armazenistas

§ Distribuição e Retalho

§ Logística

§ Serviços.

o Áreas das Organizações

§ Financeira

§ Recursos Humanos

§ Produção

§ Marketing

§ Comercial

§ Compras

o Níveis de Gestão e Necessidades de Informação

§ Gestão Estratégica

§ Gestão Intermédia

§ Gestão Operacional

o Sistemas de Informação Empresariais

§ Sistemas Informação para a cada combinação


33 DE 96

entre os Níveis de Gestão e as Área da Organização.

4.3 Arquitectura de Sistemas de Informação

O objectivo deste módulo é desenvolver os conceitos de

Arquitectura Empresarial e de Arquitectura de Sistemas de Informação,

tanto ao nível dos conceitos e da informação envolvidos como ao nível

das ferramentas e métodos do seu desenvolvimento.


o Definição da Arquitectura Empresarial e de Sistemas de Informação e seus modelos de representação

o Frameworks de Arquitectura Empresarial

§ Framework de Zachman

§ Outros Frameworks (INDEX, Gartner,..)

o Elementos da Arquitectura de Sistemas de Informação

§ Arquitectura do Negócio

§ Arquitectura da Informação

§ Arquitectura Aplicacional

§ Arquitectura Tecnológica

§ Plano de Implementação

o Modelos de Alinhamento

§ Alinhamento do Negócio com os Sistemas

§ Alinhamento do Negócio com a Informação

§ Alinhamento dos Sistemas com a Informação

o Ferramentas de suporte ao Desenvolvimento de Arquitecturas Empresarias e de Sistemas de Informação:

§ Características fundamentais

§ Exemplos de ferramentas.(ex: System Architect)


34 DE 96

4.4 Arquitectura Aplicacional

Este módulo tem dois objectivos principais: (i) dar aos alunos

uma caracterização sumária diferentes tipos de sistemas de

informação, não de uma perspectiva tecnológica mas sim de uma

perspectiva funcional, e (ii) apresentar aos alunos os métodos de

identificação e caracterização das aplicações adequadas ao negócio e à

gestão da informação.

Os tópicos a abordar são:

o Taxionomia dos Sistemas de Informação

§ Sistemas Transaccionais e Operacionais

§ Sistemas de Suporte à Decisão

• Armazéns de dados (Data Warehouses)

• Armazéns de dados temáticos (Data Marts)

• Sistemas de Exploração de Dados (Business Intelligence)

o Sistemas Operacionais

§ Sistemas de Gestão Financeira

§ Sistemas de Gestão de Recursos Humanos

§ Sistemas de Gestão da Produção

§ Sistemas de Gestão de Marketing

§ Sistemas de Gestão Comercial

§ Sistemas de Gestão das Compras

o Introdução aos Sistemas B2B, B2C, B2E, CRM e ERPs.

o Introdução aos Sistemas de Gestão Documental e Workflow

o Métodos e Ferramentas de determinação e identificação das aplicações da Arquitectura de Aplicações.

§ Matrizes de CRUD

§ Afinidade de Processos de Negócio e das Entidades Informacionais

§ Cobertura e abrangência das Arquitecturas.


35 DE 96

4.5 Arquitectura Tecnológica

O objectivo deste módulo é, primeiramente, enumerar e

sistematizar os conceitos tecnológicos constituintes de uma

Arquitectura de Sistemas de Informação. Muitos destes conceitos são já

leccionados noutras disciplinas, sendo aqui apenas referido como

devem ser considerados numa Arquitectura Tecnológica.

Os tópicos abordados são:

• Elementos Tecnológicos da Arquitectura de Sistema de Informação.

• Implementação de um Sistema de Informação nas Organizações

• Ambiente de Desenvolvimento, de Teste, de Staging e de Produção.

• Migração de Dados.

• Passagem a Produção.

• Arquitecturas Escaláveis e de Alta Disponibilidade. Disaster Recovery.

• Implementação de Processos de negócio

• Requisitos transaccionais, síncronos e assíncronos.

• O papel do Midleware.

• O papel dos Sistemas de Workflow.

• Desdobramento das Transacções de Negócio em transacções computacionais.

• Arquitecturas de Interoperabilidade

• Integração de Processos de Negócio e de Sistemas de Workflow.

• Integração de Dados e Meta-data.


36 DE 96

4.6 Arquitectura de Soluções Standards

Este módulo pretende enumerar e sistematizar os padrões

Arquitecturais que são a realidade da informática actual.

• ERPs

• Áreas funcionais

• Integração com os outros sistemas

• Apresentação de um produto

• Sistemas B2B. Sistemas de Sourcing, Sistemas de Procurement, Extranets, Suplly Chain Management, Gestão de Catálogos. MarketPlaces.

• Sistemas B2C:

• Portais de Informação: Gestão de Conteúdos, Motores de Integração, Motores de Pesquisa

• Portais de Serviços: Gestão dos Serviços e respectivas transacções. Gestão de Catálogos, Gestão das Encomendas/Reservas.

• Portais de Compras: Gestão das Vendas, Gestão dos Pagamentos, Picking & Packing, Logística Inversa

• Sistemas B2E

• Sistemas de Workflow

• Sistemas de Gestão Documental

• Sistemas de Gestão de Conhecimento

• DW e Sistemas de Suporte à Decisão

• Sistemas CRM

• CRM Operacional: Marketing, Suport, Gestão de Vendas

• CRM Analítico: Data Marts de Produtos, Clientes, Transacções

• Contact Centers


37 DE 96


38 DE 96

5 Organização e Plano de Aulas

A organização e o plano das aulas da disciplina pressupõe um

determinado modelo de aulas, estruturado em 3 tipos distintos:

• Aulas Teóricas. Aulas de apresentação de conceitos e

exposição da matéria.

• Aulas Práticas/Dúvidas. Aulas focadas no esclarecimento

de dúvidas colocadas pelos alunos, e na resolução de

casos concretos usando os métodos e ferramentas que os

alunos deverão usar na realização dos trabalhos.

• Aulas de Apresentação. Aulas em que os alunos

apresentam trabalhos realizados por si, seguindo-se uma

breve discussão e análise.

Com excepção da primeira e nas duas últimas semanas de aulas,

as aulas são encadeadas no seguinte ciclo:

• Na aula teórica é exposto um tema, são apresentadas as

fontes de estudo e é apresentado o enunciado do trabalho,

que os alunos deverão realizar e apresentar na aula de

Apresentação.

• Na aula prática/dúvidas esclarece-se e tiram-se dúvidas

sobre o tema dado em aulas teóricas bem como sobre o

trabalho que os alunos têm que resolver. Em particular

pode-se apresentar trabalhos semelhantes exemplificando-

se a aplicação dos métodos e ferramentas apropriadas.

• Na aula de apresentação, todos os alunos entregam os

trabalhos e são escolhidos 2 ou 3 trabalhos para

apresentação e discussão na aula. A escolha dos


39 DE 96

trabalhos é feita para que todos os grupos apresentem pelo

menos uma vez.

A justificação da escolha deste modelo baseado em ciclos para o

ensino das matérias de ATSI será feita no capítulo7-Orientações

Pedagógicas, onde consideramos mais apropriado.

A calendarização das aulas teóricas, práticas e de apresentação

deverá ser instanciado ao horário da disciplina de forma a que haja um

maior tempo possível entre a aula teórica e a aula de apresentação,

aumentando também o tempo que os alunos dispõem para a realização

do trabalho.

No 1º semestre do ano lectivo de 2003/2004 a disciplina de ATSI

terá no Tagus Park, o seguinte horário:

• Aula Teórica – 2 feira (90 minutos)

• Aula Apresentação – 2 feira (120 minutos), depois da aula Teórica.

• Aula Prática/Dúvidas - 4 feira (90 minutos)

A disciplina inclui 13 destes ciclos semanais, completando um

total de 65 horas. Na prática, apenas 12 ciclos são efectivos devido aos

feriados e pontes, sendo estas situações mitigadas eliminando na

prática a 12ª semana.

Na primeira semana, não existe aula de Apresentação.

A distribuição da matéria por cada ciclo é apresentada na tabela

seguinte:


40 DE 96

Tabela VI - Módulos e Tópicos de ATSI

Ciclo Módulo / Tópicos

1ª Introdução

2ª Organizações – Tipos, Áreas, Gestão e SI

3ª Arquitecturas Empresariais

4ª Arquitectura de Sistemas de Informação

5ª Arquitectura de Aplicações

6ª Arquitectura Tecnológica

7ª Arquitecturas dos Sistemas ERPs

8ª Arquitecturas dos Sistemas B2B

9ª Arquitecturas dos Sistemas B2C

10ª Arquitecturas dos Sistemas B2E e DW

11ª Arquitecturas dos Sistemas CRM

12ª Consolidação

13ª Consolidação e Exame

Nas páginas seguintes apresenta-se com algum detalhe cada um

destes ciclos semanais.

1ª Ciclo Introdução

Tópicos

da Aula Teórica

15 Setembro

• Evolução dos Sistemas de Informação nas Organizações

• Arquitecto, Arquitectura e Arquitectura de Sistemas de Informação

• A Estrutura Organizacional e os Sistemas de Informação

• Dados, Informação e Sistemas de Informação.

Trabalho Leitura dos artigos seleccionados

Estudo deste manual.

Indicação das expectativas dos alunos nesta disciplina.

Aula Prática

17 Setembro

Definição de Grupos. Apresentação da Organização em estudo nesta edição da disciplina, e que servirá de base a todos os trabalhos da disciplina. Apresentação da notação dos conceitos básicos: Processos Negócio, Entidades Informacionais, Aplicações e Tecnologia

Aula de Discussão dos Trabalhos


41 DE 96

Apresentação

22 Setembro

2ª Ciclo Organizações - Tipos, Áreas, Gestão e SI

Tópicos

da Aula Teórica

22 Setembro

• Tipos de Organizações

• Áreas das Organizações

• Níveis de Gestão e Necessidades de Informação

Na aula teórica será feita uma visão geral de cada tópico, de acordo com o âmbito do programa, devendo ser um ou dois dos tópicos abordados com mais detalhe.

Trabalho

(Fase 1)

Os alunos deverão identificar os macro processos de negócio da organização em estudo, abrangendo as áreas descritas no enunciado.

Será distribuído aos alunos uma template para a definição das arquitecturas, e exemplos de trabalhos já feitos para servir como guia e exemplo.

Aula Prática

24 Setembro

Esclarecimento de dúvidas, normalmente sobre a caracterização da organização em estudo, ou sobre o nível de detalhe com que os “macro” processos de negócio devem ser especificados.

Exemplos de especificação de processos de negócio aplicados a outras organizações.

Aula de Apresentação

29 Setembro

Apresentação e discussão de 2 trabalhos (Fase 1).

3ª Ciclo Arquitecturas Empresariais

Tópicos

Da Aula Teórica

29 Setembro

• Modelos de Representação da Arquitectura Empresarial

• Frameworks de Arquitectura Empresarial

Trabalho

(Fase 2)

Desenvolvimento da Arquitectura de Negócio da empresa em estudo, detalhando os macro processos de negócio especificados na semana anterior.

Os alunos podem rever os trabalhos que entregaram e discutiram na semana anterior, evitando a propagação de erros à medida que vão avançando no trabalho.

A Arquitectura de Negócio entregue é um elemento de avaliação.

Aula Prática

1 Outubro

Apresentação de casos e exemplos das práticas e métodos de levantamento, estruturação e representação dos processos de negócio

Clarificação de dúvidas, normalmente sobre do nível de detalhe e da


42 DE 96

informação que faz sentido incluir na definição de processos de negócio com vista à realização de uma Arquitectura de Sistemas de Informação.


6 Outubro

Entrega, apresentação e discussão de 2 trabalhos de Arquitectura de Negócio, que incluem as fases 1 e 2.

4ª Ciclo Arquitectura de Sistemas de Informação

Tópicos

da Aula Teórica

6 Outubro

• Elementos da Arquitectura de Sistemas de Informação

• Modelos de Alinhamento

• Ferramentas de suporte

Trabalho

(Fase 3)

Com base na Arquitectura de Processos de Negócio apresentada os alunos deverão desenvolver a Arquitectura de Informação correspondente, identificando e estruturando as entidades informacionais necessárias à execução dos processos de negócio.

Os alunos devem ter acesso a outras Arquitecturas já feitas para que sirvam de exemplo.

Aula Prática

8 Outubro

Esclarecimento de dúvidas

Apresentação de casos e exemplos das práticas e métodos de identificação e estruturação das entidades Informacionais que constituem a Arquitectura de Informação.

Exemplos de validação da cobertura e da abrangência da Arquitectura de Informação.


13 Outubro

Apresentação e discussão de 2 trabalhos (Fase 3)

5ª Ciclo Arquitectura de Aplicações

Tópicos

da Aula Teórica

13 Outubro

• Taxionomia dos Sistemas de Informação.

• Sistemas Operacionais.

• Introdução aos conceitos de ERP´s, DW, CRM, B2B, B2C e B2E.

• Métodos de identificação e caracterização das aplicações

Trabalho

(Fase 4)

Os alunos deverão detalhar a Arquitectura de informação, identificando os principais atributos de cada entidade informacional definida na semana anterior.

Os alunos podem rever o trabalho entregue na semana anterior, acrescentando ou removendo entidades informacionais.

A Arquitectura de Informação entregue é um elemento de avaliação


43 DE 96

Aula Prática

15 Outubro

Esclarecimento de dúvidas e apresentação de casos e exemplos de aplicação dos métodos de definição da Arquitectura de Informação.

Exemplos de validação da cobertura e da abrangência da Arquitectura de Informação.


20 Outubro

Entrega, apresentação e discussão de 2 trabalhos de Arquitectura de Informação, que inclui as fases 3 e 4.

6ª Ciclo Arquitectura Tecnológica

Tópicos

da Aula Teórica

20 Outubro

• Componentes da Arquitecturas Tecnológica

• Arquitecturas de Interoperabilidade

• Tecnologias de implementação de Processos de Negócio

• Tecnologias de implementação das entidades Informacionais

Trabalho

(Fase 5)

Com base na Arquitectura de Processos de Negócio e na Arquitectura de Informação definidas os alunos deverão desenvolver a Arquitectura de Aplicações correspondente, identificando e as aplicações que optimizam a execução dos processos e a gestão da informação..

Os alunos devem ter acesso a outras Arquitecturas já feitas para que sirvam de exemplo, facilitando o trabalho aos alunos.

Aula Prática

22 Outubro

Esclarecimento de dúvidas e apresentação de casos e exemplos de utilização das ferramentas e metodologias para o desenvolvimento da Arquitectura de Aplicações.


27 Outubro


7ª Ciclo Arquitectura dos Sistemas ERPs

Tópicos

da Aula Teórica

27 Outubro

• Áreas Funcionais de um ERP

• Necessidade e Integração com outros Sistemas

• Apresentação de um Produto/Tecnologia

Esta aula pode/deve ser leccionada por um consultor com experiência na condução de projectos de implementação de ERPs.

Trabalho

(Fase 6)

Os alunos deverão refinar ou acrescentar a Arquitectura Aplicações resultante do trabalho anterior com a inclusão de um ERP para as áreas de Contabilidade, Finanças, Imobilizado, Gestão de Stocks e Armazéns. Os alunos deverão descrever:

• A correspondência entre o ERP e as aplicações identificadas na Arquitectura de Sistemas de Informação, bem com os processos de negócio que devem suportar,


44 DE 96

• As entidades informacionais que devem gerir e/ou aceder em modo leitura, explicitando as dependências (necessidades de integração) entre o ERP e as diferentes aplicações propostas na Arquitectura de Aplicações.

• A especificação os seus principais requisitos e perfis de utilizadores,

Os alunos podem corrigir/alterar/melhorar a Arquitectura de Aplicações a usar como ponto de partida para este trabalho

Aula Prática

29 Outubro

Esclarecimento de dúvidas e apresentação de casos e exemplos


3 Novembro


8ª Ciclo Arquitectura dos Sistemas B2B

Tópicos

Da Aula Teórica

3 Novembro

• Sistemas de Procurement,

• Sourcing

• Suplly Chain Management

• Extranets,

• Gestão de Catálogos

• MarketPlaces

Trabalho

(Fase 7)

Os alunos deverão refinar/acrescentar a Arquitectura Aplicações resultante do trabalho anterior (portanto já com o ERP) com aplicações B2B, seguindo as mesmas etapas que no exercício da semana anterior

Os alunos podem corrigir/alterar/melhorar a Arquitectura de Aplicações a usar como ponto de partida para este trabalho.

Aula Prática

5 Novembro

Esclarecimento de dúvidas e apresentação de casos e exemplos


10 Novembro


9ª Ciclo Arquitectura dos Sistemas B2C

Tópicos

Da Aula Teórica

10 Novembro

• Portais de Informação

• Portais de Serviços

• Portais de Compras

Trabalho Os alunos deverão refinar/acrescentar a Arquitectura Aplicações


45 DE 96

(Fase 8)

resultante do trabalho anterior (portanto já com o ERP e com as soluções B2B) com aplicações B2C, seguindo as mesmas etapas que no exercício da 7ª semana.


A Arquitectura de Aplicações com o ERP, as soluções B2B e B2C constitui um elemento de avaliação.

Aula Prática

12 Novembro

Esclarecimento de dúvidas e apresentação de casos e exemplos.


17 Novembro

Entrega, apresentação e discussão de 2 trabalhos (Fase 5,6,7,8)


46 DE 96

10ª Ciclo Arquitectura dos Sistemas CRM

Tópicos

da Aula Teórica

17 Novembro

• CRM Operacional

• CRM Analítico

• Contact Centers

Trabalho

(Fase 9)

Os alunos deverão refinar/acrescentar a Arquitectura Aplicações resultante do trabalho anterior (portanto já com o ERP e com as soluções B2B e B2C) com aplicações de CRM, seguindo as mesmas etapas que no exercício da 7ª semana.


Aula Prática

19 Novembro



24 Novembro


11ª Ciclo Arquitectura dos Sistemas B2E e DW

Tópicos

Da Aula Teórica

24 Novembro

• Sistemas de Workflow

• Sistemas de Gestão Documental

• Sistemas de Gestão de Conhecimento

• Sistemas de Suporte à Decisão e DW

Trabalho

(Fase 10)

Os alunos deverão refinar ou acrescentar a Arquitectura Aplicações resultante do trabalho anterior (portanto já com o ERP e com as soluções B2B e B2C e CRM) com aplicações B2E, seguindo as mesmas etapas que no exercício da 7ª semana .


Aula Prática

26 Novembro



3 Dezembro



47 DE 96

12/13ª Ciclo Consolidação

Aula Teórica

10 Dezembro

Aula Prática

17 Dezembro

Revisão da Matéria

Esclarecimento de dúvidas.

Trabalho

(Fase 11)

Os alunos deverão desenvolver a Arquitectura Tecnológica, identificando os componentes e tecnologias que devem ser transversais a todas as aplicações, bem como a identificação de outros requisitos particulares, entre os leccionados na aula da 6ª semana.

Os alunos deverão ainda apresentar o Plano de implementação das arquitecturas, identificando a ordem de implementação das aplicações.

Os alunos deverão apresentar a versão final de todos as entregas

• A Arquitectura de Negócio,

• A Arquitectura de Informação

• A Arquitectura de Aplicações, com o ERP e soluções B2B, B2C, B2E e CRM

• A Arquitectura Tecnológica

• O Plano de implementação das Arquitecturas


15 Dezembro

das 15:30 às 19:00

Entrega dos trabalhos (relatório com todas as fases) e Exame Final.


48 DE 96


49 DE 96

6 Elementos de Estudo

Neste capítulo apresentamos os elementos de estudo propostos

para a disciplina de ATSI. A disciplina aborda três grandes áreas,

identificadas no capítulo 2-Justificação e Objectivos como:

1. Conhecimento das Organizações

2. Conhecimento dos métodos e ferramentas de

desenvolvimento de Arquitecturas de Sistemas de Informação

e de Arquitecturas Empresariais

3. Conhecimentos sobre as soluções e tecnologias correntes no

mercado nas áreas dos sistemas B2B, B2C, B2E,CRM, DW e

ERPs.

Como estas áreas são oriundas de comunidades distintas é

natural que não haja um único elemento de estudo as aborde de forma

compreensiva e abrangente.

Esta mesma realidade aplica-se também à área relativa ao ponto

3, onde também não existe um único elemento de estudo que abranjam

todos os tipos de sistemas, na perspectiva que pretendida em ATSI. Os

elementos de estudo são normalmente “white papers” disponibilizados

por alguns fabricantes e portais da especialidade, que pela sua

volatilidade, são normalmente indicados aos alunos ao longo das aulas

Desta forma, os elementos de estudo de base são apenas para as

duas primeiras áreas, tal como apresentadas no quadro seguinte:


50 DE 96

Tabela VII - Elementos de Estudo Base

Área

Conhecimento das Organizações

“Sistemas de Informação para as Organizações”, . José Rascão. Edições Sílabo.2001 - ISBN 972 618 244 1

Este livro aparece como elemento de estudo apenas em 2003/2004. Nos anos anteriores esta componente da matéria tinha capítulos de outros livros e os slides das aulas.

Área

Métodos e Ferramentas de Desenvolvimento de

Arquitecturas de Sistemas de Informação

“Enterprise Architecture Planning, Developing a Blueprint for Data, Applications and Technology”. Steven H. Spewak, Wiley-QED, 1992. - ISBN 0 471 599859

Este tem sido o livro usado. Recentemente saiu um novo livro, mas ainda não foi possível a sua avaliação por, só agora em Agosto, estar disponível.

“Enterprise Architecture Using the Zachman Framework”, by Carol O'Rourke, Neal Fishman, Warren Selkow. Thomson/Course Technology. 2003. ISBN: 0619064463.

Para além destes elementos de estudo, para cada módulo existe

um conjunto de outros elementos que complementam os primeiros. Os

elementos de estudo sem referência ao editor e sem URL são

disponibilizados no site da disciplina de ATSI (http://mega.ist.utl.pt/~ic-

atsi).

Tabela VIII - Elementos de Estudo Adicionais

Módulos de ATSI

Elementos Adicionais

Introdução • Critical Issues of Information Systems Management”,

Computer Sciences Corporation. (2000) http://www.csc.com/aboutus/uploads/CI_Report.pdf

• Model Curriculum and Guidelines for Graduate Degree Programs in Information Systems, Association for Computing


51 DE 96

Machinery (ACM) e Association for Information Systems

http://www.acm.org/education/curricula.html

• “You Can´t ‘Cost-Justify’ Architecture”, Zachman, John (2001), http://www.brcommunity.com/cgibin/x.pl/commentary/b059.html

Organizações • Processos, Nuno Bernardo

http://www.spi.pt/documents/books/ecommerce/

• Relações com Parceiros de Negócio, Carlos Brito, Carla Ramos


• Logística, José de Carvalho, Fausto Faustino, Ricarlo Gomes Félix


• Digitalenterprise- Portal http://www.digitalenterprise.com

Arquitectura

Empresarial e

Arquitectura de

Sistemas de

Informação

• “The Framework for Enterprise Architecture:- Getting Beyond the Legacy”, John A. Zachman

• “The Challenge is Change– How do you intend to assimilate ever increasing rates of change?”, John A. Zachman

• “The Framework for Enterprise Architecture: - Background, Description and Utility” John A. Zachman

• “Enterprise Information Architecture.”, Clive Finkelstein,

• “The Zachman Framework: An introduction”, Hay, David C. (1997), http://www.tdan.com/i001fe01.htm

• “The Use of Zachman Framework Primitives for Enterprise Modeling”, Gundars Osvalds

• “Enterprise Architecture and Legacy Systems”, Zachman, John (1996), http://www.zifa.com

• “You Can´t ‘Cost-Justify’ Architecture”, Zachman, John (2001), http://www.brcommunity.com/cgi-bin/x.pl/commentary/b059.html

• Enterprise Architecture Community - Portal http://www.eacommunity.com


52 DE 96

Arquitectura de

Aplicações

• “Data Stores, Data Warehousing and the Zachman Framework ”, McGraw - Hill, 1997, W.H. Immon, and , John Zachman - ISBN 0 07 031429 2

• “Data Architecture. The information Paradigm”. W.H. Immon. QED Techical Publishing Group 1992. - ISBN 0 89435 358 6

• “Practical Application Architecture”, Alex Cullen,

• “The Popkin Process for Enterprise Architecture”, The Popkin Software

Arquitecturas

Tecnológicas

• “IT Architectures and Middleware, Strategies for Building Large Integrated Systems”. Chris Britton, Addison Wesley, 2001 - ISNB 0 201 70907 4

Arquitecturas de

Soluções

Standards

• Slides da Aulas

• White papers dos fabricantes


53 DE 96

7 Orientações Pedagógicas

A metodologia pedagógica seguida na disciplina tem como base a

natureza particular das matérias dadas, centradas à volta da

arquitectura, modelação e estruturação das organizações e dos

sistemas de informação. O processo de aprendizagem destas matérias

passa necessariamente pela experimentação e discussão dos

resultados obtidos. É um processo cíclico, em que em cada etapa se

acrescentam mais variáveis aumentando o nível de complexidade, mas

em que a experimentação e discussão fazem parte de cada etapa deste

ciclo.

Esta experimentação deverá acompanhar as matérias

leccionadas, num processo sequencial e evolutivo, devendo os alunos

consolidar através da experimentação e discussão os conhecimentos

obtidos antes de abordarem outros temas. Assim, a metodologia

pedagógica da disciplina fundamenta-se na aplicação das seguintes

técnicas:

• Aulas de Exposição. Estas aulas caracterizam-se por

uma comunicação quase exclusiva do docente para os

alunos. É adequada e quase inevitável na apresentação de

matérias novas para os alunos.

• Aulas Orientadas. Nas aulas orientadas, os alunos são

guiados pelo docente a chegar às conclusões e aos

raciocínios pretendidos pelo docente. A comunicação é

bidireccional, entre os alunos e o docente. Estas aulas são

particularmente eficazes quando os alunos já têm um nível

de conhecimento mínimo que lhes permita intervenções e

raciocínios enquadrados nas matérias.

• Aulas de Discussão. As aulas de discussão são aulas


54 DE 96

onde os alunos são esperados a ter uma forte intervenção,

sob pretexto de uma solução apresentada ou de um caso

de estudo. A comunicação é também bidireccional, não

apenas entre o docente e os alunos mas também entre os

alunos Estas tipologia de aulas implica que os alunos

conheçam e tenham experiência que sustente os

argumentos que usam nas suas intervenções.

A aplicação destas técnicas nas aulas segue momentos distintos,

tal como é evidenciado no seguinte quadro.

Tabela IX – Aplicação das Técnicas Pedagógicas ao longo das Aulas

Técnicas Pedagógicas Dominantes Semana

Módulo

Aula Teóricas Aula

Prática

Aula de

Apresentação

1ª Introdução Aulas de Exposição

Aulas de Exposição

Aulas Orientadas

2ª Organizações Aulas de Exposição

Aulas Orientadas

Aulas de Discussão

3ª Arquitectura Empresarial


Aulas Orientadas

Aulas de Discussão

4ª Arquitectura Sistemas de Informação


Aulas Orientadas

Aulas de Discussão

5ª Arquitectura Aplicacional


Aulas Orientadas

Aulas de Discussão

6ª Arquitectura Tecnológica


Aulas Orientadas

Aulas de Discussão

7ª Arq. - Sistemas ERPs

Aulas Orientadas

Aulas Orientadas

Aulas de Discussão

8ª Arq. - Sistemas B2B

Aulas Orientadas

Aulas Orientadas

Aulas de Discussão

9ª Arq. -Sistemas B2C

Aulas Orientadas

Aulas Orientadas

Aulas de Discussão

10ª Arq. -Sistemas B2E

Aulas Orientadas

Aulas Orientadas

Aulas de Discussão

11* Arq. -Sistemas CRM

Aulas Orientadas

Aulas Orientadas

Aulas de Discussão


55 DE 96

12ª/13 Consolidação Aulas de Discussão

Aulas de Discussão

Aulas de Discussão

Nas primeiras aulas teóricas, até à 6ª semana, a técnica

pedagógica dominante é a das aulas de Exposição, dado o pouco

conhecimento que os alunos têm das matérias e extensão das

mesmas. Contudo, após a 6ª semana, as aulas teóricas são dedicadas

à aplicação dos conceitos dados a soluções específicas, sendo mais

fácil a utilização da técnica das aulas orientadas.

Nas duas últimas semanas as aulas teóricas, práticas e as de

apresentação, são aulas consolidação e preparação para o exame,

sendo conduzidas usando as técnicas de discussão.

Nas aulas práticas, e não considerando a da primeira semana que

é usada como aula teórica, as aulas seguem a técnica das aulas

orientadas, estando sempre limitadas ao âmbito da resolução do

problema e à aplicação dos conhecimentos adquiridos até então.

Finalmente, nas aulas de apresentação segue-se a técnica de

aulas de discussão, sendo conduzidas de forma a promover a

intervenção entre os alunos. Como os alunos fizeram o mesmo

trabalho, estão fortemente motivados para inquirir os colegas sobre as

opções que tomaram e sentem-se também particularmente à vontade

para avaliar os prós e os contras das opções dos colegas.

Um factor que tem condicionado bastante a possibilidade de dar

aulas orientadas é o elevado número de alunos que, quando superior

aos 30 alunos torna a prática desta técnica pedagógica

significativamente mais difícil.

Quanto às estratégicas pedagógicas a usar nas aulas, podemos

constatar que os artefactos usados da disciplina seguem os sugeridos

pelo currículo do ACM [MSISI2000] para o curso correspondente a esta

disciplina na área científica de Sistemas de Informação, como é

evidenciado na tabela seguinte.


56 DE 96

Tabela X - Estratégias Pedagógicas Aconselhadas e Adoptadas

Suggested pedagogical approaches for delivering the

course (MSIS 2000-ACM)

Estratégia correspondentes adoptadas na disciplina

Lectures Existem 3 tipos de aulas, Teóricas, Práticas e de Apresentação

Case studies on business process reengineering, ERP systems, supply chain management, and customer management

Durante as aulas práticas são apresentados exemplos de trabalhos já feitos, não só nestes temas mas em noutros temas da matéria de ATSI.

Exercises using a visual tool for specification of business processes and enterprise data models

Ferramenta de suporte à Arquitectura Empresarial

Ferramenta de modelação de Processos

Interaction with an ERP tool (but not ERP systems development, per se)

Não tem correspondente na disciplina. Embora fosse possível, implicaria um foco das aulas práticas e trabalhos quase exclusivamente no ERP.

Student team projects involving, for example, the specification of an integrated business process

A disciplina tem trabalhos práticos semanais, que cobrem a maioria da matéria leccionada.

Student presentations Existem as aulas de Apresentação onde os alunos expõem o seu trabalho, havendo posteriormente um espaço para discussão com os colegas e docente

Industry lecturers Está planeada uma de duas apresentações:

• de um fabricante ou implementador de ERPs, onde é apresentado a arquitectura de um produto

• de um consultora, onde é apresentado a implementação de um ERP numa organização.


57 DE 96

8 Avaliação de Conhecimentos

Neste capítulo apresenta-se o método de avaliação de

conhecimentos não só os teóricos e práticos adquiridos mas também a

capacidade de consulta de informação e a capacidade de apresentação

desse conhecimento. Apresentamos também a calendarização da

avaliação tal como está programada.

8.1 Formas da Avaliação

Esta avaliação é feita em duas componentes:

• Avaliação dos trabalhos ao longo da disciplina, que no seu

total deverá contribuir para 70% da nota final. Os trabalhos

são avaliados numa escala de 0 a 5.

• Exame, com um peso de 30% na nota final. Os exames

são avaliados numa escala de 0 a 20.

A relação 70/30 para a contribuição das notas do trabalhos/exame

para a nota final dos trabalhos pretende assegurar que o exame seja

ainda a componente com maior peso na avaliação, quando comparado

com cada um dos 4 trabalhos3 individualmente. Pretende-se que os

trabalhos sejam vistos também como parte fundamental do processo de

aprendizagem e não apenas de avaliação.

Muito embora a escala de cada um destes componentes seja

diferentes, a notas finais são sempre dadas numa escala de 0 a 20 para

os alunos da licenciatura e numa escala de 0 a 5 para os alunos de pós-

graduação.

3 Ou partes de um único trabalho


58 DE 96

8.1.1 Avaliação através dos Trabalhos

A avaliação dos trabalhos pretende avaliar

• a capacidade de pesquisa e consulta da informação

• A capacidade de síntese e de apresentação

• A aplicação dos conhecimentos adquiridos

A componente dos trabalhos, que vale 70 % da nota final, é feita

tendo em conta a média pesadas da nota de cada uma das 4 entregas

dos trabalhos com o seguinte peso cada:

Tabela XI - Pesos dos Trabalhos na nota final

Entrega Fases Peso na nota final

1ª Entrega Fases 1 e 2 15%

2ª Entrega Fases 3 e 4 15%

3ª Entrega Fases 5, 6, 7 e 8 20%

4ª Entrega Fases 9, 10 e 11 20%

Os trabalhos são normalmente feitos com grupos de 3 elementos.

8.1.2 A avaliação através do Exame

Com o exame pretende-se avaliar de forma individual os aspectos

que os restantes formas de avaliação não abrange, nomeadamente:

• Capacidade de compreensão das questões que lhe são

colocadas e capacidade de síntese das respostas.

• Avaliação dos conhecimentos fundamentais.


59 DE 96

O exame tem como nota mínima os 8 valores, pretendendo que os

alunos estudem toda a matéria e não justifiquem a sua passagem a esta

disciplina exclusivamente através dos trabalhos.

8.2 Calendarização do Esforço dos Alunos

Muito embora os alunos tenham que apresentar as fases dos

trabalho todas as semanas, implicando assim uma avaliação contínua, a

distribuição do esforço que o aluno precisa de dedicar à disciplina não é

uniforme, tendo a experiência mostrado que é relativamente intensa nas

semanas das entragas dos trabalhos.

Desta forma, e considerando o plano de aulas apresentado no

capítulo 5 - Organização e Plano de Aulas, é esperado um esforço

significativo por parte dos alunos nas seguintes semanas:

Tabela XII – Semanas de maior esforço dedicado a ATSI

Semana Motivo

3ª Entrega das Fases 1 e 2 do Trabalho

5ª Entrega das Fases 3 e 4 do Trabalho

8ª e 9ª Entrega das Fases 5,6,7,8 do Trabalho

12ª e 13ª Entrega das Fases 9,10,11 do Trabalho, integradas num relatório final com as restantes fases

Variável Exame


60 DE 96


61 DE 96

9 Experiência Adquirida nas Edições Anteriores

Como já foi referido, a disciplina de ATSI é leccionada há quatro

anos, ao longo dos quais foi alvo de várias alterações com vista à sua

melhoria contínua. Neste capítulo apresentamos os principais

ensinamentos e melhorias realizadas.

O primeiro comentário geral é que a disciplina não tem alunos

reprovados. Sendo uma disciplina opcional e feita maioritariamente por

trabalhos, com entregas ao longo do semestre, os alunos ou desistem

no início do semestre, ou fazem os trabalhos e acabam por passar à

disciplina. A taxa dos alunos que desiste da disciplina nas primeiras

semanas tem sido cerca de 10%.

9.1 Experiência relativa aos Trabalhos

O sucesso do trabalho dos alunos determina em larga medida o

sucesso da disciplina, pelo que o melhorar os aspectos relativos à

condução do trabalho é fundamental par ao sucesso da disciplina.

Apresentamos de seguida um quadro com as principais questões

verificadas e as medidas correctivas tomadas.


62 DE 96

Tabela XIII - Evolução das Medidas relativas aos Trabalhos

Sintoma Medida Correctiva Ano

1 Os trabalhos que envolvam terceiras entidades (empresas) acabam por se atrasar devido a falta de disponibilidade por parte destas.

Todos os trabalhos são feitos sem qualquer dependência de entidades externas.

00/01

2 Cada trabalho novo implica um tempo de aprendizagem elevado para que possa ser tratado com o nível de detalhe necessário à sua realização.

Em vez de terem de fazer vários trabalhos sobre organizações e contextos diferentes, os alunos fazem apenas um trabalhos numa única organização. Este trabalho é faseado em várias entregas, cada uma correspondente a um aumento de detalhe do trabalho ou do âmbito do trabalho.

01/02

3 O enunciado do trabalho não descreve a organização (ou problema) com o detalhe suficiente para que não haja dúvidas nos alunos relativamente a uma série de aspectos

As dúvidas e esclarecimento relativas ao trabalho que ocorrem nas aulas práticas são publicadas numa lista de FAQs no site da disciplina.

02/03

4 Os alunos sentem que aprendem muito com a apresentação e a discussão dos trabalhos nas aulas de Apresentação, mas como já entregaram o trabalho sentem que são avaliados antes de uma etapa importante da sua aprendizagem.

Cada elemento da avaliação é feito e discutido em duas etapas, sendo avaliado apenas na segunda. Na primeira etapa os alunos determinam as linhas gerais e tomam as grandes decisões do trabalho. Na segunda etapa, os alunos especificam e detalham o trabalho.

Na aula de apresentação da primeira etapa, os alunos têm a oportunidade de validar as suas ideias gerais e de as corrigir antes de iniciarem sua a etapa do trabalho, normalmente a que obriga a uma maior esforço.

Na aula de apresentação da segunda etapa, entregam as duas etapas para avaliação.

03/04

5 Como os alunos não sabem quando irão apresentar os trabalhos,

Os trabalhos incluem uma template de resumo das principais decisões, facilitando simultaneamente (i) a

03/04


63 DE 96

têm que preparar e levar o material de apresentação em todas as aulas de Apresentação

avaliação do trabalho, (ii) a apresentação do mesmo nas Aulas de Apresentação, (iii) a compreensão do trabalho pelos alunos durante as Aulas de Apresentações.

O resultado da aplicação destas medidas correctivas está patente

na tabela seguinte, onde se apresenta o número de alunos, o número de

entregas e o número de elementos de avaliação.

Tabela XIV - Evolução das Entregas e Avaliações do Trabalho

Ano Nr Alunos

Nº Entregas

Nº Avaliações Observações

1999/2000 43 3 3 3 trabalhos independentes, cada trabalho com 1 avaliação apenas

2000/2001 30 7 7 7 trabalhos independentes, cada trabalho com 1 avaliação apenas

2001/2002 34 7 5 1 trabalho evolutivo, sobre uma Empresa de Retalho, sendo avaliado em 5 das 7 entregas

2002/2003 67 2 2 1 trabalho evolutivo, sobre o DEI, sendo avaliado nas 2 das suas 2 entregas

Em 2001/2002 passou-se a ter apenas 1 trabalho com várias

entregas. A experiência de 2002/2003 foi, em termos da avaliação e do

feedback para os alunos inferior à de 2001/2002, tendo sido

condicionada fundamentalmente pelo elevado número de alunos e pela

necessidade de leccionar a disciplina apenas com 5 créditos, que

corresponde a um docente apenas para as aulas teóricas, práticas, de

apresentação e para a correcção dos trabalhos.

Esta situação deverá ser corrigida no próximo ano lectivo

2003/2004, onde está previsto um número de alunos inferior a 30 e o

envolvimento de um monitor de para apoio ás aulas práticas. Nestas


64 DE 96

circunstâncias, está previsto um trabalho com 10 entregas sendo 4 para

avaliação, tal como está planeado e descrito nos capítulos anteriores

deste relatório. A relação de 10 entregas/discussões para 4 avaliações

permite que todas as avaliações sejam feitas sobre entregas

previamente discutidas, implementado assim a medida 4 da Tabela XIII -

Evolução das Medidas relativas aos Trabalhos.

9.2 Experiência relativa ao programa da Disciplina

A análise das variações do programa da disciplina ao longo dos 4

anos em que esta foi leccionada permite perspectivar também a forma

como esta se enquadra na licenciatura evolução das matérias e dos

interesses mostrado pelos alunos.

Desde a sua criação que esta disciplina tem mantido o foco

principal na questão da determinação das aplicações que deverão existir

para suportar eficazmente um determinado negócio. Contudo, e como

vimos, a disciplina aborda tem abordado também aspectos relacionados

com a compreensão e a modelação dos processos de negócio, e

aspectos relacionados com as tecnologias de base à sua construção.

Ao longo dos 4 anos em que a disciplina foi leccionada, tem-se

assistido a uma gradual transferência da atenção dedicada aos modelos

de middleware e de integração de sistemas de informação, para

questões relacionadas com a aplicabilidade das mesmas no suporte

aos requisitos impostos pelos processos de negócio.

Esta questão assume um papel relevante pois os alunos tendem

sempre a propor soluções técnicas mais complexas do que as exigidas

pelo negócio, não tendo noção das inúmeras desvantagens associadas

ao excesso de complexidade.

9.3 Inquéritos aos Alunos.

A avaliação ao funcionamento das disciplinas que o Gabinete de

Estudos e Planeamento (GEP) do IST faz às disciplinas, sob a forma de

um inquérito aos alunos, é um elemento importante a ter em


65 DE 96

consideração na melhoria da disciplina.

No quadro seguinte apresentamos a informação sobre a disciplina

que é relevante para análise neste relatório. Nele constam apenas os

resultados relativos aos anos lectivos de 2000/2001 e 2001/2002,

porque:

• O resultados dos primeiro ano (1999/2000), sendo

semelhantes aos do ano 2000/2001, não são significativos:

em primeiro lugar porque a disciplina foi leccionada por

três docentes com pedagogias, elementos de estudo e

trabalhos independentes e, em segundo lugar, porque o

inquérito foi respondido apenas por um número

extremamente reduzido de alunos.

• No ano de 2002/2003 não houve avaliação por parte do

GEP porque, por falha dos serviços administrativos a

disciplina não constava na lista das disciplinas em vigor.

Os valores apresentados correspondem à apreciação dos alunos

a cada tópico, numa escala de 0 a 5 valores, tendo respondido ao

inquérito cerca de 20 alunos em cada ano. Na última linha do quadro

apresenta-se o valor médio da Apreciação Global considerando todas

as disciplinas da Licenciatura (LEIC).

Tópicos apreciados 2000/2001 2001/2002

Coordenação das aulas 3,31 3,44

Contribuição dos elementos de estudo 2,25 3,13

Articulação com conhecimentos anteriores

3,06 3,47

Contributo da disciplina para a formação

3,94 4,35

Adequação do método de avaliação ao conteúdo

3,53 4,05


66 DE 96

Horas semanais dispendidas em Trabalho/estudo

11-15 6 a 10

Apreciação Global de ATSI 3,29 3,9

Média da Licenciatura 3,54 3,71

Embora reduzida, esta informação permite-nos constatar que os

alunos consideram que:

• os elementos de estudo são o aspecto mais fraco da

disciplina.

• o contributo que a disciplina tem para a sua formação é o

aspecto que mais valorizam.

• que a disciplina melhorou, pelo menos nos anos

observados, passando a ter uma apreciação superior à

média das disciplinas da licenciatura.


67 DE 96

10 Referências

[CSC2001] - “Critical Issues of Information Systems Management” da Computer Sciences Corporation. Disponibilizado on-line em http://www.csc.com/aboutus/uploads/CI_Report.pdf

[DEI 2010] – www.dei.ist.utl.pt

[MSIS 2000] – “MSIS 2000 - Model Curriculum and Guidelines for Graduate Degree Programs in Information Systems”, da responsabilidade da Association for Computing Machinery (ACM) e Association for Information Systems. Disponível on-line em http://www.acm.org/education/curricula.html.


68 DE 96


69 DE 96

Anexo I – Notas das Edições Anteriores

Neste anexo apresentamos as notas de ATSI nos 4 anos lectivos

em que foi ministrada a alunos da Licenciatura e da Pós-Gradução.

Na tabela seguinte, a coluna “Nº de Alunos” refere-se aos alunos

que frequentaram a disciplina, fizeram os trabalhos, foram às aulas de

apresentação, e ultrapassaram a nota mínima no exame. Em cada ano,

as notas dos alunos da Licenciatura e de Pós-Graduação estão

individualizadas. As notas dos alunos de Pós Graduação estão

apresentadas numa escala de 0 a 20. Os gráficos de barras mostram o

nº de alunos nas abcissa e a nota correspondente na ordenadas

Tabela XV - Notas de ATSI

Ano 1999/2000 Nº Alunos Média

0

2

4

6

8

10

12

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Series2

Lice

ncia

tura

42 15,3

1 aluno com nota de 15 valores

Pós

–G

radu

ação

1 15



70 DE 96

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Lice

ncia

tura

14 14,1

0

1

2

3

4

5

6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Pós

–G

radu

ação

16 15,6


0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Lice

ncia

tura

22 14


71 DE 96

0

0,5

1

1,5

2

2,5

3

3,5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Pós

-G

radu

ação

12 15,3


0

2

4

6

8

10

12

14

16

18

20

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Lice

ncia

tura

52 13,6

0

1

2

3

4

5

6

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Series1

Pós

-G

radu

ação

15 15,4


72 DE 96

Anexo II – Exames das Edições Amteriores

– LEIC/MEIC – ATSI

2º Semestre 1999/2000

1º Exame – 26 e 27/Junho

Notas: Exame individual Com consulta. A interpretação do enunciado faz parte da própria avaliação. A cotação de cada questão encontra-se entre parêntesis no topo do respectivo

grupo. Enunciado entregue no dia 26/Junho às 10h e exame recebido no dia 27/Junho às

13h. Pretende-se respostas sucintas. A informação não relevante para um resposta só

contribui para a sua desvalorização.

Grupo I – ATSI (3 + 2 + 2 + 2 valores)

1 A constante evolução e mudança das organizações, dos negócios e da tecnologia são uma das principais dificuldades na gestão e planeamento da função informática de hoje. Indique, justificando, quais os principais factores de um projecto de ATSI que permitem gerir estas evoluções.

2 Descreva a relação entre modelação de ATSI e a modelação de software em geral, ou de SI em particular. Justifique.

3 Compare e discute, neste contexto, a relação entre as linguagens EAB e UML (Unified Modeling Language).

4 O que é que, relativamente à ATSI, o EAB não consegue representar? Porquê? Justifique.

Grupo II – Middleware e Integração de Sistemas (2 + 2 + 2 valores)

5 Compare o middleware baseado em mensagens com o middleware baseado em RPC no desenvolvimento de aplicações segundo várias arquitecturas: centralizada (interface no cliente, lógica e dados no servidor), cliente/servidor (interface e lógica no cliente, dados no servidor) e "3-tier" (separação entre a interface, lógica e dados em 3 partes distintas).

6 Explique quais são as principais dificuldades encontradas pelas empresas que desejam trocar encomendas em formato electrónico, mostre como se poderia implementar uma solução sem recorrer a nenhuma ferramenta, e finalmente exemplifique como é que um produto de middleware 4o poderia ajudar nessa tarefa.

7 Assumindo que um aplicação com interface Web tem claramente uma arquitectura centralizada com middleware normalizado (HTTP e HTML)

4


73 DE 96

discuta em termos de middleware a possível evolução futura da Web na direcção cliente/servidor e "3-tier". Não se esqueça de comparar estas novas arquitecturas da Web em termos de robustez, fiabilidade e escalabilidade.

Grupo III– Análise de um caso (3 + 2 valores)

8 Considere dois bancos, B1 e B2.

O banco B1 tem centenas de agências espalhadas por todo o país. Tem uma informática centralizada num mainframe onde residem todas as contas dos clientes do banco. A sede do banco, onde reside o mainframe, está ligada a cada agência por uma linha dedicada. Cada agência (assim como a sede) tem uma rede local que interliga todos os PCs da agência. Não existe comunicações entre as agências.

O banco B2 tem agências apenas nas principais cidades, e tem uma informática descentralizada. Cada agência tem um sistema de médio porte onde residem as contas da própria agência e uma rede local com PCs. O sistemas de médio porte são iguais e todas as agências. Cada sistema está ligado por linhas dedicad5as a outros três sistemas (de outras três agências), de tal forma que existe um certo grau de redundância nas comunicações entre duas qualquer duas agências.

A informática de ambos os bancos têm apenas as aplicações estritamente necessárias ao funcionamento do dia-a-dia de cada banco, e podemos considerar três tipos de aplicações:

• as que fazem as transacções de movimentos de contas (que no caso do banco B1 executam no mainframe e no caso de B2 executam no sistema de médio porte existente em cada agência);

• as que se executam nos PCs e permitem lançar transações nas primeiras, por exemplo as que os operadores do balcão usam para fazer o lançamento de cheques e movimentos em numerário nas contas.

• as que se executam nos PCs e são autónomas relativamente às contas, por exemplo as de simulação de crédito, registo de documentos, etc.

Considere que se pretende integrar a informática dos dois bancos, no sentido em que os clientes podem ir às agências de qualquer dos bancos indistintamente. Considere ainda que se pretende incluir na informática “integrada” sistemas de análise de padrões de utilização das contas e cartões de crédito de forma a se definir uma estratégia de marketing e campanhas de produtos comuns.

5


74 DE 96

8.1 Apresente uma arquitectura para a informática integrada. Como forma de justificar as decisões tomadas, indique as características dos dados e das transações que residem em cada sistema/aplicação apresentadas. Indique também que tipo de middleware deveria ser usado na sua interligação.

8.2 Apresente um conjunto de iniciativas (projectos ou acções) cuja realização considera fundamental para que a integração seja possível. Por outras palavras, para que os bancos possam passar da situação actual para a preconizada no 8.1.


75 DE 96

Exame de ATSI

Julho 2001

O exame tem uma duração de 90 minutos. As respostas devem ser sucintas e claras.

A nota do exame vale 20% da nota final. A nota mínima do exame é 8 valores

Cada pergunta vale 4 valores..

1. Explique as principais diferenças de âmbito entre as funcionalidades de um sistema de procurement e um de sourcing. ? Qual o impacto que estas diferenças têm ao nível da necessidade de integração de sistemas dos compradores e fornecedores?

2. Considere o Framework de Zachman. Admita que uma empresa vai iniciar um reengenharia de processos de negócio. Indique as colunas do Framework de Zachman que mais alterações deverão sofrer. Indique também as as que, expectavelmente menos alterações deverão sofrer ?

3. Explique as razões que tornam o processo de desenvolvimento de uma Data warehouse diferente do processo de desenvolvimento de um sistema de informação tradicional ?

4. Explique, de forma genérica, a relação entre os sistemas B2C (lojas web) e CRM. Explique a razão pela qual os fabricantes de ERPs já integram soluções de CRM como mais um módulo do ERP sendo a integração dos módulos B2C mais distantes.

5. Explique o que é e como se “faz” uma arquitectura aplicacional . Indique o impacto das soluções existente no mercado na arquitectura aplicacional e como se resolve os eventuais conflitos.

FIM


76 DE 96

ATSI

1º Exame – 1 Julho 2002

Notas: O Exame é individual e sem consulta. Pretende-se respostas sucintas. A informação não relevante para um resposta só contribui para a sua desvalorização.

1 (2v) A constante evolução e mudança das organizações, dos processos de negócio e da tecnologia são uma das principais dificuldades na gestão e planeamento da função informática. Indique as etapas de um projecto de ATSI e, justificando, a contribuição de cada uma das etapas na gestão destas evoluções.

2 (2v) Indique as células do framework de Zachmam cujo preenchimento corresponde ao desenvolvimento de uma ATSI, e as que correspondem o desenvolvimento de um Sistema de Informação.

3 Considere dois bancos, B1 e B2. O banco B1 tem centenas de agências espalhadas por todo o país. Tem uma informática centralizada num mainframe onde residem todas as contas dos clientes do banco. A sede do banco, onde reside o mainframe, está ligada a cada agência por uma linha dedicada. Cada agência (assim como a sede) tem uma rede local que interliga todos os PCs da agência. Não existe comunicações entre as agências. O banco B2 tem agências apenas nas principais cidades, e tem uma informática descentralizada. Cada agência tem um sistema de médio porte onde residem as contas da própria agência e uma rede local com PCs. O sistemas de médio porte são iguais e todas as agências. Cada sistema está ligado por linhas dedicadas a outros três sistemas (de outras três agências), de tal forma que existe um certo grau de redundância nas comunicações entre duas qualquer duas agências.

A informática de ambos os bancos têm apenas as aplicações estritamente necessárias ao funcionamento do dia-a-dia de cada banco, e podemos considerar três tipos de aplicações: (i) as que fazem as transacções de movimentos de contas (que no caso do banco B1 executam no mainframe e no caso de B2 executam no sistema de médio porte existente em cada agência); (ii) as que se executam nos PCs e permitem lançar transações nas anteriores, por exemplo as que os operadores do balcão usam para fazer o lançamento de cheques e movimentos em numerário nas contas; (iii) as que se executam nos PCs e são autónomas relativamente às contas, por exemplo as de simulação de crédito, registo de documentos, etc. Considere que se pretende integrar a informática dos dois bancos, no sentido em que os clientes podem ir às agências de qualquer dos bancos indistintamente.

3.1 (4v) Apresente uma arquitectura de aplicações e tecnológica para a informática integrada dos dois bancos. Como forma de justificar as decisões tomadas, indique as características dos dados e das transações que residem em cada sistema/aplicação apresentadas. Indique também que tipo de middleware deveria ser usado na sua interligação.

3.2 (2v) Indique as iniciativas (projectos ou acções) cuja realização considera fundamental para a integração das duas informáticas seja possível.


77 DE 96

3.3 (2v) Considere agora que se pretende construir um data mart para a a análise de padrões de utilização dos cartões de crédito de forma a se definir uma estratégia de marketing e campanhas de produtos comuns. Indique os componentes que seria necessário implementar, a sua função e as etapas necessárias à sua implementação.

4 Considere uma empresa industrial, por exemplo de fabrico de cimento, na qual existe um ERP como o único sistema operacional, um solução de CRM e outra de Procurement.

4.1 (2v) Indique 3 exemplos de processos de negócio que devem ser suportados por cada sistema.

4.2 (2v) Indique 3 exemplos de entidades informacionais que devem existir em cada um destes sistemas.

5 (2v) Indique os principais funções de um monitor transaccional. Justifique a razão pela qual essa função não pode ser feita pelo sistema operativos.

6 (2v) Indique a arquitectura típica de uma solução de CRM. Qual a diferença entre o CRM analítico e o operacional ?


78 DE 96

ATSI


Notas: O Exame é individual e sem consulta. Pretende-se respostas sucintas. A informação não relevante para um resposta só contribui para a sua desvalorização. A duração é de 90 minutos.

1 (3v) Explique o que significa o “alinhamento” entre os sistemas de informação e as entidades informacionais. Indique que instrumentos/ferramentas tem para evidenciar o alinhamento (ou não alinhamento) referido no ponto anterior, e não outros alinhamentos.

2 (2v) Responda á pergunta 1, mas considerando agora o alinhamento entre os processos de negócio e as entidades informacionais.

3 (3v) Indique e explique as etapas necessárias a assegurar o alinhamento entre processos de negócio, entidades informacionais e sistemas de informação, e a forma de evidenciar o alinhamento.

4 (3v) Explique a arquitectura X/Open para suporte a transacções distribuías, indicando os principais componentes e a sua função.

5 (3v) Indique o que são as arquitecturas escaláveis e com alta disponibilidade, bem como as condições ou pressupostos que o software deverá cumprir para possibilitar a escalabilidade ou alta disponibilidade. Discuta as vantagens e desvantagens das arquitecturas escaláveis e com alta disponibilidade perante a existências de máquinas que por si próprias já são escaláveis e com alta disponibilidade.

6 (3v) Explique a diferença em termos de segurança entre uma arquitectura a 2 níveis e a 3 níveis.

7 (3v) Apresente as principais razões para que os dados históricos sejam mantidos em sistemas (máquinas) diferentes dos dados operacionais.


79 DE 96

ATSI



1 (2v) O objectivo da disciplina de ATSI é “Dotar os alunos do conhecimento necessário à elaboração de Arquitectura de Sistemas de Informação Empresariais”. Que conhecimento é esse ? (Não precisa de dizer toda a matéria da disciplina!!! Indique apenas as grandes áreas desse conhecimento!!).

2 (3v) Indique as implicações que normalmente resultam de se pensar na Arquitectura de Aplicações antes de se pensar na Arquitectura de Informação. Em que condições é indiferente a ordem com que ambas as arquitecturas são pensadas?

3 (3v) Dê um exemplo de um caso de desalinhamento entre: (i) Arquitectura Processo de Negócio e Aplicações; (ii) Arquitectura Processo de Negócio e Arquitectura de Informação e; (iii) Arquitectura de Informação e Arquitectura de Aplicações

4 (2v) Resuma as principais vantagens em usar uma Base de Dados como uma Interface de publicação/subscrição para troca de dados públicos entre as aplicações de uma organização. Dê dois exemplos onde é preferível ligações directas “on-line” entre as aplicações.

5 (4v) Considere uma empresa de aluguer de automóveis, na qual os Processos de Negócio PN1 “entrega de veículo” e PN2 “recepção de veículo” podem dar-se em qualquer agência da empresa (existem agências em todas as cidades e pode haver várias na mesma cidade). Admita que: (i) ambos os processos fazem “update” à entidade “veículo”; (ii) existe uma aplicação que suporta o PN1 e outra que suporta o PN2; (iii) ambas as aplicações assumem que gerem a “entidade veículo” (como se fosse informação privada) e desconhecem a existência da outra.

Admita que cada aplicação disponibiliza uma API que permite ler/escrever a entidade E1, e que existe disponível um middleware de mensagens. Indique a forma de integrar ambas as aplicações assegurando o funcionamento de ambos os processos PN1 e PN2. Qual a situação particular nestes PN que permite uma solução bastante simples ?

6 (4v) Considere que um Processo de Negócio (PN1) termina após a modificação do estado de uma entidade (E1 de X para Y) . Considere que existem dois Processos de Negócio (PN2 e PN3) que consultam a mesma entidade E1. Considere a entidade E1 é gerida pela aplicação


80 DE 96

que suporte PN1 e PN3, e que PN2 é suportado por outra aplicação que precisa de aceder aos estado de E1. Para cada um dos seguintes cenários, Indique qual os requisitos do middleware a usar na integração das duas aplicações:

• A) Após PN1 terminar, PN2 e PN3 devem ver a entidade E1 com o valor de Y, embora possa haver um atraso de tempo em que ainda vêm o valor X. Não existe sincronismo entre entre PN2 e PN3.

• B) Após PN1 terminar, PN2 e PN3 vêm logo (e apenas) a entidade E1 com o Y.

7 (1v) Indique as áreas funcionais podemos encontrar numa solução de CRM operacional. E na de CRM analítico ?

8 (1v) Indique as áreas funcionais abrangidas por uma solução de “procurement” ?


81 DE 96

ATSI



9 (4v) Indique as principais diferenças entre as características da informação gerida nos sistemas operacionais e nos sistemas de Data Warehouse, nomeadamente no que toca aos seguintes aspectos: modelos de representação; padrões computacionais de acesso à informação ; tipo de informação que se pode obter pela sua análise.

10 (4v) Explique os objectivos de uma solução de CRM analítica, descrevendo os objectivos do três Datamarts típicos destas soluções e dando exemplos das questões que se pretendem obter resposta com cada um deles.

11 (3v) Indique de forma muito sucinta as etapas de realização de uma Arquitectura de Sistemas de Informação. Em que etapa e de que forma se considera a estratégia da organização ?

12 (3v) Indique as células do framework de Zachman cujo preenchimento corresponde a cada uma das etapas realização de uma Arquitectura de Sistemas de Informação.

13 (3v) Explique a que nível de detalhe é necessário caracterizar (definir) os Processos de Negócio durante a realização de uma Arquitectura de Sistemas de Informação.

14 (3v) Explique as consequências de ter um alto nível de agregação das entidades Informacionais na matriz de CRUD, e dê exemplos de como estas podem ser resolvidas.


82 DE 96

Anexo III- Exemplo de um Trabalho

Neste anexo, Iremos apenas apresentar o trabalho que será aplicado à próxima edição da disciplina, nomeadamente no 1º semestre de 2003/2004 aos alunos do 4º ano da LEIC-Tagus.


83 DE 96


84 DE 96

Grupo F&T

Caso de Estudo

Arquitectura Tecnológica dos Sistemas de Informação 2003/2004


85 DE 96

1 -Introdução Nos últimos anos o Grupo Francisca & Torres (F&T), tem desenvolvido algumas iniciativas com o objectivo comum de introduzir melhorias na organização e sistematiza-las de modo a dar maior consistência a toda a lógica de funcionamento da empresa.

Como corolário deste esforço, surgem assim vários sinais dos resultados obtidos nomeadamente com o aumento sustentado do volume de negócios e a expansão da sua rede de lojas.

O Grupo F&T nos últimos anos tem perseguido os seguintes objectivos:

§ Diferenciar-se dos concorrentes pela focalização no cliente e no serviço

prestado; § Atingir sempre, e se possível exceder, as expectativas dos Clientes; § Ser reconhecida como líder no negócio dos móveis e decoração.

Tendo sido pioneira em muitas das iniciativas tomadas, também agora o Grupo F&T procura consolidar essa imagem de inovação e liderança ao equacionar a redefinição do seu sistema informático orientado para a melhoria da eficácia e eficiência da sua cadeia de abastecimento.

Apresenta-se em seguida uma análise ao estado actual do Grupo.

2- Caracterização do Grupo F&T

O Grupo Francisca & Torres (F&T) é constituído por um conjunto de sete (7) empresas independentes, juridicamente autónomas e distribuídas geograficamente por todo o território Português, operando no negócio do retalho de “Móveis e Decoração” com mais de 30 000 artigos diferentes.

Conta actualmente com cerca de 1200 colaboradores e com uma frota de 170 viaturas de transporte e distribuição.

Existem empresas com e sem armazéns de distribuição adstritos às lojas, estando o Grupo F&T organizado da seguinte forma:


86 DE 96

Empresa Armazém Loja Armazém adstrito à Loja

F&T SA Meleças

Madeira Madeira Madeira

Açores Açores A Açores

F&T 2 Vila Real Vila Real Vila Real

Aveiro Aveiro Aveiro

Barreiro Barreiro Barreiro

Faro/Olhão Faro/Olhão Faro/Olhão

F&T 3 Alverca

Bobadela Alverca

Torres Vedras Alverca

F&T 4 Rio de Mouro Rio de Mouro Rio de Mouro

Viseu Viseu Viseu

Meleças Meleças

F&T 5 Almirante Reis Meleças

Açores B Açores

F&T 6 Fundão Fundão Fundão

Odivelas Alverca

F&T 7 Restelo Meleças

Os seus principais fornecedores são indústrias de fabricação de mobiliário e produtos de decoração nacionais e internacionais (Espanha, Brasil, Itália) que fornecem de acordo com contratos/acordos previamente estabelecidos com a Administração do Grupo F&T.

2.1 - Estrutura Organizacional A estrutura organizacional do Grupo F&T pode ser representada da seguinte forma:


87 DE 96

A estrutura organizacional de cada uma das empresas do grupo pode ser representada da seguinte forma:

A Administração composta pelos sócios tendo como responsabilidade toda a gestão operacional e económico-financeira do negócio do grupo.

A Direcção Financeira tem como funções e responsabilidade toda a gestão da contabilidade e tesouraria das diversas empresas do grupo bem como a consolidação das contas do grupo. Conta com doze (12) colaboradores para além do seu responsável.

A Secção de Pessoal gere toda a contratação e processamento de salários de todos os colaboradores das empresas do grupo, à excepção dos responsáveis das lojas recrutados e seleccionados pela própria Administração. Conta actualmente com quatro (4) colaboradores para além do seu responsável.

Administração

Financeira Pessoal Sistema Informação Armazéns Lojas

Loja 1

Loja N


88 DE 96

A Gestão do Sistema de Informação é responsável por toda a gestão e manutenção do sistema de informação. Conta actualmente apenas com um colaborador.

Os Aprovisionamentos e a Gestão de Stocks estão estruturados em dois níveis:

1- Armazém Central (Meleças) é responsável pela gestão de toda a cadeia de abastecimento do grupo de empresas e pelas compras de artigos internacionais;

2- Os diferentes armazéns das diversas lojas gerem o seu próprio stock e têm delegação de autoridade para procederam a compras de reposição de artigos nacionais. Têm como responsabilidade garantir que as mercadorias recepcionadas, armazenadas e entregues estão nas devidas condições por forma a satisfazer continuamente os clientes e evitar reclamações e devoluções. Têm também a responsabilidade pelo recebimento do último pagamento (40% do valor do artigo).

A Função Comercial (Vendas) tem como funções e responsabilidade a orçamentação, a venda, o recebimento, o registo da informação associada às vendas e às encomendas e o envio diário e mensal de toda a informação financeira e comercial para a Direcção Financeira do grupo F&T.

Não existem estabelecidas formalmente as funções “marketing”, “após-venda”, “qualidade” e “planeamento e controlo de gestão” sendo na maioria das situações desempenhadas pela própria Administração do grupo F&T.

2.2 Caracterização do Modelo de Negócio

Considerando o “Modelo de Negócio” como o conjunto dos processos de negócio e de suporte e os recursos necessários para gerar riqueza aos accionistas e fornecer produtos e prestar serviços aos clientes de acordo com as suas necessidades e expectativas, podem identificar-se o seguinte conjunto de processos e sub-processos:

Processos de Negócio

• Recepção de Mercadorias;

• Armazenamento;

• Vendas;

• Expedição;

• Distribuição;

• Após-Venda.

Processos de Suporte ao Negócio

• Gestão Financeira;


89 DE 96

• Contabilidade;

• Tesouraria;

• Gestão do Imobilizado;

• Aprovisionamentos;

• Gestão de Recursos Humanos;

• Recrutamento e Selecção;

• Processamento de Salários.

A caracterização dos processos encontra-se no anexo A.

Após análise dos processos identificados e caracterizados podemos representar o Modelo de Negócio do Grupo F&T da seguinte forma:

Ao centro são representados os processos de negócio e o fluxo de informação entre os sistemas de apoio à decisão – Gestão da Cadeia de Abastecimento, Gestão das Vendas, Controlo de Gestão e Gestão de Recursos Humanos.

São também representados no modelo, os principais intervenientes no negócio – Clientes, Accionistas, Colaboradores e Fornecedores – e a sua articulação com os sistemas de informação.

Recepção Armazenamento Vendas Expedição Distribuição Após-Venda

Gestão de Vendas e Mkt.

Gestão da Cadeia de Abastecimento (Aprov., Logística e Feed Back Cliente)

Ges

tão

de R

ecur

sos

Hum

anos

Con

trolo

de

Ges

tão

(Fin

ance

iro, Q

ualid

ade)

Col

abor

ador

es

Acc

ioni

stas

Clientes

Fornecedores


90 DE 96

Estes sistemas, responsáveis por recolherem e disponibilizarem informação, constituem a forma como a Administração poderá no futuro medir e controlar o desempenho do negócio, quer ao nível operacional quer ao nível estratégico, alinhando-o com uma política e estratégia sustentada em factos e medidas.

2.3 Caracterização dos Sistemas de Informação

Os Sistemas de Informação considerados estão esquematizados no diagrama que se apresenta em baixo. Estão também representados os fluxos de informação existentes entre os sistemas considerados:

Gestão de Tesouraria

Gestão de Pessoal

Gestão de Lojas e Armazéns

Módulo de Loja Módulo de Armazém

Gestão deResponsabilidades

Contabilidade

Sistema de Gestão de Pessoal

Actualmente, e desde Janeiro de 1996, a F&T trabalha com um sistema de Gestão de Pessoal da Infologia, em QuickBasic.

Este sistema é operado centralmente por 5 utilizadores do Departamento de Recursos Humanos.

O sistema disponibiliza as seguintes funcionalidades:

• Gestão do ficheiro de pessoal de cada uma das empresas

• Processamento de Salários


91 DE 96

• Gestão da Conta Corrente de cada empregado

• Registo de períodos de férias (com a limitação de só possibilitar a marcação de 2 períodos anuais)

• Registo de Faltas

• Registo de Horas Extraordinárias

Face à informação recolhida no sistema é possível extrair os seguintes outputs

• Mapas para a segurança social

• Mapas de IRS – Pagamentos mensais e declarações anuais.

• Quadros pessoal

• Modelo 10

• Mapa para bancos

• Mapa para cheques

• Mapa de horas extras

• Mapa absentismo

Com base no Mapa de Cheques existe um processamento que Batch que :

• imprime cheques (para situações em que o pagamento ao empregado não é efectuado por transferência bancária);

• cria ficheiro para integração dos dados referentes de pagamentos a empregados na tesouraria;

• cria um ficheiro para bancos com a indicação das transferências por NIB.

Sistema de Contabilidade

O sistema contabilístico, da Astrolábia, é uma aplicação centralizada em CLIPPER com DBASE que corre em emulação NT do UNIX.

Actualmente existem 8 utilizadores cuja função é a de verificação e registo de lançamentos contabilísticos, 3 na gestão de fornecedores nacionais e 2 na gestão de fornecedores internacionais. Todos os utilizadores deste sistema fazem-no por acesso local.

A contabilidade está organizada por empresas.

Só existe interligação com o Sistema de Tesouraria a nível de terceiros. No entanto, existe necessidade de repetir lançamentos nos sistemas Contabilístico e de Terceiros.

Existe necessidade de tratamento da informação existente o que é feito em Excel ou Lotus com base em balancetes extraídos do sistema de informação.

Sistema de Gestão de Responsabilidades


92 DE 96

O sistema de Responsabilidade consiste numa aplicação desenvolvida em ACCESS pela própria F&T, tendo por finalidade a gestão de Letras, empréstimos e outras obrigações financeiras da F&T.

Mensalmente são extraídos desta aplicação os dados necessários à tesouraria, processo também ele desenvolvido pela equipa de sistemas de informação da F&T.

Sistema de Gestão de Tesouraria

O Sistema de Tesouraria foi desenvolvido internamente em COBOL, assim como a sua ligação ao sistema contabilístico por transferência de ficheiros. Existem actualmente 5 funcionários da F&T adstritos à área de Tesouraria.

Foi desenvolvido um mecanismo de interface entre os sistemas de Contabilidade e de Tesouraria. No entanto, este interface não está a ser utilizado, sendo feita a repetição sistemática de lançamentos nos dois sistemas aplicacionais.

Sistema de Gestão de Lojas e Armazéns

O Sistema aplicacional de Gestão de Loja e Armazéns foi desenvolvido pela F&T em Cobol.

O sistema está replicado em cada servidor de loja e/ou armazém F&T, sendo o acesso aos seus dados, residentes em ficheiros indexados, local.

O sistema residente no armazém de Meleças funciona como receptor e distribuidor de ficheiros de dados, assentado na seguinte rede de distribuição:

Fig.2 Representação da Rede dos Sistemas de Distribuição

Vila Real

Vila Real

Meleças

ResteloAlmirante Reis

Meleças

Açores

AB

Madeira

Madeira

Rio de Mouro

Rio Mouro

Viseu

Viseu

Fundão

Fundão

Faro/Olhão

Olhão

Barreiro

Barreiro

Aveiro

Aveiro

Alverca

BobadelaTorres Vedras

Odivelas


93 DE 96

Periodicamente, são gerados localmente ficheiros (por comparação de ficheiros) com movimentações de stocks de armazém/loja. Estes ficheiros são enviados para o servidor de Meleças que os distribui pelos restantes servidores onde reside o sistema de gestão de lojas e armazéns. No final do dia, são criados novos ficheiros, tendo por base a situação do dia anterior e as alterações efectuadas no decorrer do dia, e distribuídos por cada site.

O mecanismo indicado permite que cada loja/armazém tenha em cada momento tanto a sua posição “quase real “ dos stocks a nível de toda a F&T.

A transferência de ficheiros entre os diferentes locais onde reside o sistema aplicacional é baseada em ligações RDIS.

Os servidores são UNIX sendo o acesso dos clientes feitos por emulação de janelas UNIX em ambientes Windows ou MSDOS.

A aplicação é composta por dois módulos aplicacionais : um destinado ao processamento das vendas, utilizado nas lojas, e um segundo destinado ao processamento da gestão de stocks, compras, requisições, distribuição e facturação, utilizado nos armazéns.

O módulo de gestão de loja contempla como funcionalidade principais, as seguintes: • Criar/alterar/eliminar Orçamento • Processar vendas a dinheiro • Criar/alterar/eliminar Notas de Encomenda • Criar/alterar/eliminar Notas de Crédito • Emitir Recibos • Receber Pagamentos (funções de caixa) • Gerir Cliente (locais)

Repositório de Dados

O repositório de dados consiste em conjuntos de ficheiros indexados de COBOL. Cada um desses ficheiros está replicado por todo o sistema. Essa replicação é periódica, ou seja, de tanto em tanto tempo os dados são passados para os outros sistemas, mantendo uma imagem supostamente fidedigna do que se passa a nível nacional.

Existem vários ficheiros de dados, de entre os quais os mais relevantes são:

§ Utilizadores

§ Produtos

§ Fornecedores

§ Clientes


94 DE 96

§ Notas de encomenda

§ Recibos

§ Stocks de produtos

3- Alguns Problemas

1. Inexistência de informação estruturada sobre os Clientes.

§ Existem registos de clientes com alguns dos seus dados (nº contribuinte,

nome, morada, etc.).

§ Não é fácil nem automático determinar o que o cliente já comprou, que informação recebeu em casa, que informação/orçamento solicitou numa loja ou mesmo que reclamação ou insatisfação de uma forma geral manifestou a qualquer colaborador da F&T;

§ Não existe a possibilidade do Cliente aceder ou recolher informação sobre a F&T e os seus produtos/serviços através da internet.

2. Inexistência de informação estruturada sobre os Fornecedores.

§ Existem registos de fornecedores com alguns dos seus dados (nº contribuinte,

nome, morada, etc.);

§ Não existe um controlo efectivo dos produtos fornecidos pelos fornecedores, de forma a prevenir devoluções ou insatisfações causadas por produtos defeituosos ou incompletos;

3. Identificação dos Produtos ineficaz.

§ A identificação dos produtos é realizada através de um sistema de codificação

(catalogação de produto e nº de série de produto) que não contempla a identificação dos seus componentes, originando um deficiente controlo (análise e tratamento) de componentes defeituosos;

§ Inexistência de um sistema de rastreabilidade que possa rapidamente determinar quais os clientes que receberam determinados produtos vindos de determinados fornecedores. Estes sistemas permitem repor rapidamente produtos defeituosos que foram detectados à posterior (após a venda);

4. Ineficiente informação sobre os Colaboradores.

§ Para além da informação para gerir contratos de trabalho e processar

vencimentos não existe qualquer outro tipo de informação registada sobre os colaboradores nomeadamente sobre:

§ Responsabilidades e funções;


95 DE 96

§ Desempenho, experiência, produtividade e conhecimento;

§ Criatividade e inovação;

§ Motivação e satisfação.

5. Ineficiente informação sobre o aprovisionamento e distribuição.

§ Não é fácil nem automático gerir as encomendas relativamente a prazos de

entrega;

§ Existe o conceito de “central de compras” mas que só é efectivo para compras internacionais e primeiras encomendas. As restantes encomendas/compras são realizadas directamente aos fornecedores pelas diversas lojas;

§ A informação relativamente às existências em cada um dos stocks (exposição, loja e armazém) não é completamente fiável e actualizada originando muitas ocorrências de faltas (compromissos que o sistema não consegue entregar);

§ Não existe informação sobre tempos de montagem nem tempos e percursos de distribuição.

6. Infra-Estrutura Tecnológica “caótica”

7. Deficiente/inexistente integração de sistemas/funções

§ Lojas e Armazéns;

§ Contabilidade e Tesouraria e Pessoal;

8. Estratégia, Organização e Processos

§ Não existe informação sobre quem faz o quê;

§ Não existe informação que permita controlar e medir o desempenho do que se faz;

§ Não existe informação estruturada sobre os concorrentes;

§ Inexistência de Informação estruturada para controlo e planeamento de gestão, nomeadamente objectivos e indicadores estratégicos e operacionais;

§ Sistema de comunicação interna ineficiente e moroso (baseada em correio interno tradicional e manual não fazendo uso de correio electrónico nem workflow);

§ Não existe informação registada no sistema que permite analisar e tratar as reclamações de forma estruturada;

§ O processo de marketing e publicidade é realizado de forma empírica não sustentado em análises estruturadas de mercado.

9. Ineficiente Sistema de Informação


96 DE 96

§ Sistemas saturados e obsoletos que não permitem automatizar/optimizar

processos de trabalho;

§ Ineficiente controlo de acessos e confidencialidade.

4- Macro Processos de Negócio F&T

A descrição dos Macro Processos de Negócio não está incluída neste relatório pela sua dimensão

arquitectura tecnológica de sistemas de informação ... · arquitectura de sistemas de...

Documents