Gestão de Projetos de SI v01 - galpenergia.com · Um Projeto de SI pode ter um ou mais Unidades Organizativas (UO) do Grupo Galp que usufruem do resultado e benefícios do Projeto

Gestão de Projetos de Sistemas de Informação

V01 Pág 2/22


Índice

OBJETO E ÂMBITO DE APLICAÇÃO 4

1.1 Objeto 4

CICLO DE VIDA DE UM PROJETO DE SI 4

2.1 Preparação do Projeto de SI 4

2.2 Execução do Projeto de SI 5

2.2.1 Set-up 5

2.2.2 Desenho 5

2.2.3 Implementação 6

2.2.4 FormaçãoeTestes 6

2.2.5 Go-Live&Suporte 6

2.3 Gates 7

GESTÃO DO PROJETO DE SI 8

3.1 Gestão do Âmbito do Projeto 8

3.2 Gestão do Orçamento do Projeto 9

3.3 Gestão do Calendário do Projeto 9

3.4 Gestão de Issues e Riscos do Projeto 9

3.5 Gestão da Comunicação do Projeto 10

3.6 Estrutura Organizativa de um Projeto de SI 10

PRINCIPAIS ENTREGÁVEIS 15

PASSAGENS ENTRE AMBIENTES E CEP 16

5.1 Enquadramento 17

5.2 Releases 17

5.3 Organização 18

V01 Pág 3/22


5.4 Minor Releases, Emergency Releases e CEPs Extraordinários 19

MATRIZ DE RESPONSABILIDADES 19

6.1 Projetos de SI – Etapas da Fase de Execução 19

6.2 Projetos de SI – Disciplinas transversais gestão de projeto 21

V01 Pág 4/22


Objeto e âmbito de aplicação

1.1 Objeto

O presente documento tem por objeto a formalização de regras e procedimentos associados à Gestão de Projetos de Sistemas de Informação (Projetos de SI) e a definição dos responsáveis pela execução das atividades inerentes. Neste documento, Projetos de SI são projetos de execução nos domínios dos Sistemas de Informação, que incorporam um conjunto de atividades interligadas que convergem para um resultado único (solução, protótipo, estudo), possuindo objetivos e âmbitos bem definidos, orçamento próprio, equipa temporária de trabalho, responsáveis claramente identificados e eventos de início/fim definidos temporalmente. Um Projeto de SI pode ter um ou mais Unidades Organizativas (UO) do Grupo Galp que usufruem do resultado e benefícios do Projeto de SI, e um ou mais fornecedores, isto é, as entidades que concebem e produzem o resultado do Projeto de SI.

Ciclo de vida de um Projeto de SI

O ciclo de vida de um Projeto de SI é constituído por duas macro etapas - Preparação e Execução, as quais se subdividem em várias etapas, apresentadas na Figura 1 - Ciclo de vida de um Projeto de SI.

Figura 1 - Ciclo de vida de um Projeto de SI

2.1 Preparação do Projeto de SI

Nesta fase, integralmente executada de forma interna, é definido o âmbito do Projeto de SI, documentados os seus requisitos, e executada a consulta a fornecedores para aquisição dos serviços e/ou produtos integrantes do Projeto de SI. Com a aprovação do Projeto de SI, do seu orçamento, da proposta do fornecedor (que será o fornecedor Integrador) mais bem classificado e da assinatura de um contrato (quando necessário),

Execução

Projeto

Implementação Formação e Testes

Go-Live & Suporte

Preparação Desenho Set-up

V01 Pág 5/22


pode dar-se início à fase de execução do Projeto de SI, conforme o calendário proposto e acordado com o Integrador e demais fornecedores de serviços contratados.

2.2 Execução do Projeto de SI

A Execução de um Projeto de SI é dividida em 5 diferentes etapas. No entanto, poderão existir projetos que terminem após a execução de uma determinada etapa (por exemplo, um projeto de SI que se limite à etapa de Desenho) ou, ao serem realizados seguindo metodologias alternativas (tipo Agile), tenham etapas específicas aqui não referidas, ou ainda que repetem as etapas definidas em vários ciclos de execução (com várias entradas em produção, por exemplo). 2.2.1 Set-up

Esta etapa tem como objetivo assegurar todas as condições necessárias ao início do Projeto de SI, no que diz respeito à mobilização dos recursos, preparação das condições logísticas e tecnológicas, e alinhamento de todos os intervenientes com os objetivos e âmbito do Projeto de SI. Nesta fase é definido e aprovado o calendário do Projeto de SI por todos os stakeholders com participação ativa no Projeto de SI. A etapa de Set-up pode ter início antes do final da etapa de Preparação do Projeto de SI. No entanto, nenhum trabalho de execução, nomeadamente compromissos com custos, terá início antes da aprovação definitiva do Projeto de SI. 2.2.2 Desenho

Esta etapa tem como objetivo conceber o produto final do Projeto de SI, do ponto de vista funcional e técnico, e obter a aceitação das Unidades Organizativas da Galp, clientes internos do Projeto de SI, de forma a prosseguir com as etapas subsequentes de construção e implementação do produto final. A etapa de desenho tem início imediatamente a seguir ao set-up do Projeto de SI, desde que existam as condições necessárias à realização do mesmo. Alguns projetos pontuais podem ter como produto final o resultado da etapa de “desenho” por terem como objetivo apenas a análise e conceção de uma solução, especificação detalhada de requisitos, ou obter informação com base num estudo. O resultado da etapa de desenho consiste num conjunto de documentos, todos eles normalizados pela Direção de Sistemas de Informação (DSI), que necessita ser aprovado pela Gestão do Projeto, ouvindo as UO utilizadoras finais da solução. É recomendável que o desenho funcional e técnico de alto nível estejam aprovados pela UO e pela DSI, respetivamente, antes do início da etapa de implementação.

V01 Pág 6/22


2.2.3 Implementação

Esta etapa tem como objetivo construir as diversas componentes da solução, assegurando que são devidamente documentadas todas as respetivas especificações técnicas detalhadas. As peças construídas têm de cumprir todos os requisitos técnicos da solução, designadamente de qualidade e compliance (tal como a qualidade do código fonte). 2.2.4 Formação e Testes

Esta etapa tem como objetivo preparar todas as condições necessárias ao arranque da utilização da solução, incluindo a finalização dos materiais de comunicação e de suporte ao utilizador final. Inclui a formação tanto dos intervenientes nos testes de aceitação como a formação dos utilizadores finais. O integrador deverá assegurar, antes da formação dos utilizadores, que o sistema está disponível com qualidade, demonstrando as evidências correspondentes. Os testes a realizar podem ser de diversas naturezas (testes de carga, testes de performance, testes de integração, testes funcionais e testes de aceitação) que requerem um planeamento prévio, a gerar na fase de Desenho. Estão envolvidos no planeamento e realização dos testes, para além do fornecedor da solução, intervenientes das UO, da DSI e Outsourcers. A responsabilidade pela realização dos testes de aceitação é das UO utilizadoras finais da solução, que a poderá delegar num terceiro, interno ou externo à Galp. A confirmação dos resultados dos testes de aceitação pela Gestão de Projeto, tanto do ponto de vista funcional como técnico, determina a disponibilidade da solução para entrada em produção. 2.2.5 Go-Live & Suporte

Com a finalização da etapa anterior, a solução é transportada para um novo ambiente – ambiente de produção –, destino final da solução para ser disponibilizada aos utilizadores finais. Os processos definidos para aprovação e execução das promoções da solução aos ambientes de qualidade e produção têm de ser devidamente planeados e executados pelo integrador e outsourcers, sob coordenação do primeiro. Determina o início da utilização da solução pelos utilizadores finais e o suporte a essa utilização. Nesta etapa é fundamental ainda existir a passagem de conhecimento necessário e suficiente para que a aplicação possa, a partir de uma determinada data, passar a estar sob a responsabilidade do Outsourcer de Manutenção Aplicacional. O envolvimento do outsourcer na solução a implementar

V01 Pág 7/22


poderá, e na maioria dos casos deverá, iniciar-se logo nas etapas iniciais da execução do Projeto de SI. Deve incluir a aprovação do modelo operativo/governance da solução, em produção, a aplicar após aceitação do Projeto de SI. Durante esta etapa são realizadas as atividades de handover para as equipas de outsourcing da Galp, em particular (mas não exclusivamente) para as equipas de Manutenção Aplicacional e de Infra estruturas, formalizadas inicialmente com a Aceitação Provisória e posteriormente com a Aceitação Definitiva do Projeto de SI, que determina o encerramento do mesmo:

• A Aceitação Provisória estabelece a resolução de todas as ocorrências críticas e o início de uma fase com maior intervenção dos Outsourcers;

• A Aceitação Definitiva define a transferência da responsabilidade de suporte e manutenção da solução, do fornecedor do Projeto de SI para as equipas de outsourcing. A partir desta data, a garantia de Projeto de SI, dada pelo fornecedor, deve ser ativada.

2.3 Gates

Cada Gate define as condições que devem ser verificadas para se iniciar a etapa seguinte. São descritas nos documentos detalhados de cada Etapa. A verificação dessas condições não significa que a etapa esteja totalmente finalizada, mas sim que se pode iniciar a etapa seguinte. As etapas não são rigorosamente sequenciais. Uma etapa pode iniciar-se antes de terminar completamente a etapa anterior. No entanto não pode iniciar-se se não estiverem reunidas as condições definidas na Gate respetiva. Etapa Gate …

Exec

ução

XI Desenho

XI1 Set-up G4 OK Arranque de execução

XI2 Análise e desenho G5 OK Desenho Preliminar G6 OK Desenho Final G7 OK Implementação

XII Implementação G8 OK Passagem a Qualidade Isolada G9 OK Passagem a Qualidade Consolidada

XIII Formação e Testes G10 Ok Passagem a UATs (testes de aceitação) G11 OK Passagem a Produção

XIV Go-Live e Suporte G12 OK Exploração (fecho técnico) XV Exploração G13 Projeto Concluído

Tabela 1 - Gates da Execução de um Projeto de SI

V01 Pág 8/22


Gestão do Projeto de SI

A gestão de um Projeto de SI inclui a coordenação de todo o ciclo do Projeto e é partilhada pela UO cliente do Projeto de SI, pela DSI e pelo fornecedor principal do Projeto de SI (“Integrador”). O papel dos vários gestores é definido no Capítulo 3.6. A gestão de Projetos de SI inclui um conjunto de disciplinas transversais a todo o ciclo com o propósito de assegurar o cumprimento dos objetivos do Projeto de SI em termos de:

• Âmbito • Orçamento • Calendário • Issues e Riscos • Comunicação

3.1 Gestão do Âmbito do Projeto

Nesta disciplina, todas as eventuais alterações ao âmbito do Projeto de SI estabelecido na etapa de Preparação do Projeto de SI são analisadas e verificadas pela Direção de Projeto, assegurando a manutenção dos limites de atuação definidos, como sejam, entre outros:

• UO impactadas • Nº de utilizadores, geografias e locais onde o Projeto de SI terá impacto • Processos de negócio a analisar e rever • Requisitos funcionais a cobrir • Requisitos técnicos a cobrir • Aplicações a alterar e a construir • Plataformas e ferramentas a utilizar

Uma alteração de âmbito, a menos que seja algo de pequena abrangência, determina quase sempre alterações no calendário e orçamento do Projeto de SI. As alterações podem ser identificadas por qualquer das partes envolvidas e, tanto as alterações propostas como aquelas que forem aprovadas, devem ser adequadamente documentadas e comunicadas a todas as partes interessadas. Alterações ao âmbito, nomeadamente com impacto em custos e/ou calendário, devem ser aprovadas pelo Comité Diretivo do Projeto de SI. Uma vez aceites as alterações, o plano e orçamento do Projeto de SI devem ser revistos em conformidade, bem como a documentação aplicável.

V01 Pág 9/22


Em função do impacto das alterações de âmbito do Projeto de SI aprovadas pelo Comité Diretivo, a DSI avalia a necessidade de reaprovação do Projeto de SI nos termos descritos nesta norma.

3.2 Gestão do Orçamento do Projeto

Esta disciplina de gestão de projeto é essencialmente interna à DSI e à Galp. O gestor do projeto da DSI deve assegurar que, a cada momento, mas em particular de forma mensal, se informa a Direção de Projeto de toda e qualquer alteração ao plano financeiro do Projeto de SI. Caso exista uma alteração ao plano financeiro e tendo em conta os dispêndios realizados e os dispêndios previstos até ao final do Projeto de SI, será avaliada a necessidade de aquisições complementares de serviços, o que implicará sempre a reaprovação do Projeto de SI.

3.3 Gestão do Calendário do Projeto

A Gestão do Calendário é uma das principais atividades da gestão de Projetos de SI e tem como objetivo principal garantir que o Projeto de SI é executado dentro dos prazos previstos. Fazem parte desta disciplina a atribuição, priorização e monitorização das tarefas do Projeto de SI com o objetivo de o terminar no prazo definido. O gestor de projeto do Integrador deverá assegurar a criação e manutenção do plano detalhado do Projeto de SI, devendo este calendário ser gerido de acordo com os seguintes princípios:

• O calendário de Projeto de SI aprovado inicialmente deve ser definido como baseline; • Qualquer alteração à baseline em vigor deve ser aprovada pelo Comité Diretivo do Projeto de

SI; • Os relatórios de status do Projeto de SI devem sempre apresentar a comparação entre a

baseline em vigor e o calendário atual. 3.4 Gestão de Issues e Riscos do Projeto

Os riscos com potencial impacto relevante no Projeto de SI devem ser formalmente identificados, sendo de realçar, em particular, as principais ameaças e potenciais consequências, assim como as medidas de prevenção (controlos preventivos) e as medidas de recuperação (controlos reativos). A identificação de riscos começa no início do Projeto de SI. Um risco deriva normalmente da identificação de um ponto em aberto, problema, incidente, dúvida não esclarecida, algo de inesperado ou a prever, que tenha probabilidade relevante de impacto nos prazos, orçamento ou qualidade do Projeto de SI.

V01 Pág 10/22


Ao longo do ciclo do Projeto de SI deve existir uma gestão de issues e riscos, com base nos seguintes princípios:

• No início do Projeto de SI é definido o principal gestor dos issues e riscos do Projeto de SI, responsável por manter um registo regular com identificação de todos os riscos e pontos em aberto com impacto no Projeto de SI.

• Qualquer interveniente no Projeto de SI pode identificar issues que devem ser imediatamente registados, devendo acompanhar a sua resolução.

• Em todas as reuniões de progresso do Projeto de SI, deve ser feito um acompanhamento dos pontos em aberto e riscos do Projeto de SI.

• Nas reuniões de Comité Diretivo devem ser apresentados os principais riscos do Projeto de SI, acompanhados das respetivas medidas e planos de mitigação ou de contingência.

O grau de formalização da gestão de issues e riscos do Projeto SI depende da dimensão e/ou complexidade do projeto.

3.5 Gestão da Comunicação do Projeto

A Gestão da Comunicação é uma função sempre presente ao longo de todo o Projeto de SI. No início do Projeto de SI, o responsável por esta função tem como foco garantir que são envolvidos os stakeholders mais relevantes, assegurando o seu alinhamento em relação aos resultados a obter. No decorrer do Projeto de SI, a Comunicação contribui para gerir expetativas e assegurar que o âmbito e solução estão sempre alinhados com as necessidades de cada stakeholder. No início do Projeto de SI devem ser estabelecidas as ações regulares e formais de comunicação necessárias à gestão operacional do Projeto de SI, sendo obrigatório, no decorrer do projeto, a publicação de um relatório de progresso. Para além da comunicação com as áreas diretamente envolvidas na execução do Projeto de SI, devem ser planeadas as ações de comunicação cujo alvo são todos os impactados pela solução final do Projeto de SI (ex: utilizadores finais, colaboradores Galp, clientes ou parceiros).

3.6 Estrutura Organizativa de um Projeto de SI

A Figura 2 - Estrutura Organizativa de um Projeto de SI define a estrutura organizativa indicativa para um Projeto de SI, a qual pode ser ajustada de acordo com a natureza e dimensão do Projeto de SI.

V01 Pág 11/22


Figura 2 - Estrutura Organizativa de um Projeto de SI

Não estão representados na Estrutura Organizativa do Projeto de SI os responsáveis hierárquicos dos intervenientes, os quais podem ser chamados a intervir para desbloquear situações de impasse na tomada de decisões.

As principais responsabilidades dos perfis intervenientes num Projeto de SI são:

Sponsor (ou Promotor): É o “dono do projeto”, É responsável pelos recursos financeiros do projeto. Nomeia o Gestor de Projeto pelo Negócio. Toma decisões de negócio, ou de caráter transversal, sob proposta do Comité Diretivo e/ou dos Gestores de Projeto. Aprova o âmbito do Projeto de SI e alterações ao mesmo, de acordo com os objetivos da UO.

Comité Diretivo (ou “Steering Committee”): Constitui a autoridade máxima no Projeto de SI. Reúne-se com a Gestão de Projeto periodicamente. Pode ser chamado a intervir pelos Gestores de Projeto, em conjunto ou individualmente, para desbloquear obstáculos ou decidir sobre questões não resolvidas ao nível da Gestão de Projeto. Deve ser constituído por: Sponsor, o Diretor da DSI ou um ou mais responsáveis de área/equipa da DSI, um ou mais Diretores das UO e/ou um ou mais Diretores do Integrador.

Gestão de Projeto: Equipa que gere o Projeto de SI, sob coordenação do Gestor de Projeto – Negócio. Reúne-se periodicamente (preferencialmente todas as semanas). Deve ser nomeada formalmente e constituída pelos gestores de projeto (Negócio, DSI, Integrador) e pelos Diretores ou responsáveis de área/equipas das UO. Decide sobre todas as questões operacionais de Projeto de SI,

V01 Pág 12/22


incluindo âmbito, calendário, orçamento, issues e riscos, sob proposta dos vários gestores de projeto, conforme a sua área de responsabilidade. Reporta ao Comité Diretivo, ou à Direção de Projeto, se existir.

Direção de Projeto – Seja porque a equipa de Diretores de Negócio é composta por muitos elementos, seja porque os Key Users podem/devem participar nas atividades de gestão de projeto, ou por outra razão que assim o justifique, pode ser acordado entre a DSI e as UO a criação de uma camada intermédia de gestão do projeto, na qual quer o Comité Diretivo quer a Gestão de Projeto delegam o todo ou parte das suas responsabilidades.

Gestor de Projeto - Negócio: Gere toda a participação da UO nas atividades para as quais é requisitada e assegura o cumprimento das atividades que lhes são atribuídas. Verifica se as funcionalidades implementadas estão de acordo com os requisitos estabelecidos. Assegura a aprovação da solução e documentos. Toma decisões sobre questões de negócio. Reporta ao Comité Diretivo questões que necessitem de aprovação pelo mesmo.

Gestor de Projeto - Integrador: Gere todas as atividades de Projeto de SI relacionadas com os produtos a entregar, definidos no âmbito, liderando a respetiva equipa. É responsável por definir e controlar o calendário de Projeto de SI, com a concordância dos outros Gestores de Projeto. Assegura o cumprimento da metodologia estabelecida e acordada com a Galp. Faz o reporte do estado do Projeto de SI nas reuniões de Gestão e Steering Committee. Coordena a comunicação com as equipas da Galp envolvidas nas atividades técnicas e funcionais.

Figura 3 - Estrutura Organizativa de um Projeto de SI com 3 níveis de gestão

Gestor de Projeto - DSI: Gere o calendário de atividades da fase de Preparação e mobiliza a participação dos restantes intervenientes. Assegura que as regras e práticas da Galp de gestão de projetos e de entrega da solução são seguidas por todos os intervenientes. Mobiliza a disponibilização de recursos logísticos. Mobiliza a participação dos intervenientes necessários em cada momento, para que se cumpram os objetivos do Projeto de SI. Desbloqueia situações de impasse recorrendo, sempre que necessário, à intervenção e decisão dos responsáveis adequados. Assegura o controlo dos issues

V01 Pág 13/22


e riscos e mobiliza a sua resolução, reportando a quem pode decidir. Gere o orçamento acordado para o Projeto de SI identificando potenciais desvios.

Key Users: Participam com o conhecimento das necessidades do negócio em todas as atividades requisitadas pela Gestão de Projeto (reuniões de análise, testes de aceitação, formação, recolha de informação e dados, etc.).

Integrador – Fornecedor(es) de Serviços de Sistemas de Informação ao qual foram contratados os serviços definidos na fase de Preparação, excluindo os que integram o projeto por intermédio dos contratos de outsourcing. Na existência de mais que um Integrador, apenas a um se atribuirá a responsabilidade de gestão transversal do Projeto de SI.

Equipa Integrador: Desenvolve as atividades planeadas de acordo com o calendário acordado e sob orientação do Gestor de Projeto - Integrador.

Arquitetura e Standards da DSI: Quando solicitado, emite pareceres na etapa de elaboração do programa de consulta e avaliação de propostas. Nos projetos de maior dimensão, participa na etapa de elaboração do programa de consulta e na avaliação de propostas no que respeita à definição e avaliação dos requisitos de arquitetura, em especial ao nível das aplicações/funcionalidades e dos dados/informação. Assegura que a solução técnica está de acordo com os princípios de arquitetura de SI definidos. Valida e aprova a documentação técnica, com suporte dos Outsourcers e área de aplicações, sempre que necessário. Alerta a Gestão de Projeto para situações de inconformidade detetadas. Disponibiliza informação/documentação sobre os sistemas existentes quando solicitada pelo Projeto de SI. É responsável pela elaboração e manutenção das melhores práticas ao nível de arquitetura empresarial.

Cibersegurança da DSI: Participa na etapa de elaboração do programa de consulta e avaliação de propostas no que diz respeito aos requisitos de segurança. Participa na validação do desenho da solução no que diz respeito a requisitos de segurança de informação, dados e privacidade.

Gestão da Procura e de Portfolio SI da DSI: Conduz o processo de aprovação do orçamento inicial do Projeto de SI, bem como das eventuais alterações de orçamento necessárias ao longo do Projeto de SI, bem como monitoriza o cumprimento desse orçamento e do calendário do Projeto de SI ao longo do mesmo.

Gestão de Contratos da DSI: Envolvido em situações de projetos que deem origem a novos contratos (manutenção, licenciamento, infraestruturas ou outros serviços). Apoia, em conjunto com o gestor de serviços correspondente (área de Aplicações ou de Infraestruturas), o gestor de projeto na negociação dos contratos necessários para suportar os novos serviços, para que estes estejam concluídos antes do início da fase de exploração.

V01 Pág 14/22


Infraestrutura da DSI: Participa na avaliação de propostas de Integradores no que diz respeito às necessidades de infraestrutura, apoiando se necessário na negociação dos contratos para suportar novos serviços através do gestor de serviço correspondente. Assegura a disponibilidade da infraestrutura de suporte ao Projeto de SI e soluções a implementar. Decide ou participa na decisão sobre questões de infraestrutura reportadas pela Gestão do Projeto. Desbloqueia situações sobre a prestação dos serviços dos Outsourcers no âmbito do Projeto de SI. Participa na avaliação das condições para handover do Projeto e, caso necessário, participa, através do gestor de serviço designado, nas fases críticas do Projeto de SI para um handover com sucesso. Operações da DSI: Assegura o cumprimento das normas de gestão de acessos atribuídas às equipas de projeto. Valida os procedimentos de gestão de acessos às novas soluções produzidas num Projeto de SI. Participa na avaliação das condições para handover do Projeto de SI. Aplicações da DSI: Participa na avaliação de propostas de fornecedores de serviços de manutenção aplicacional, apoiando se necessário na negociação dos contratos de suporte aos novos serviços através do gestor de serviço correspondente. Desbloqueia situações sobre a prestação do serviço dos Outsourcers no âmbito do Projeto de SI. Participa na avaliação das condições para handover do Projeto e, se necessário, participa, através do gestor de serviço designado, nas fases críticas do Projeto de SI para um handover com sucesso. Lidera o processo de aquisição de serviços adicionais que possam resultar do Projeto de SI, no âmbito dos respetivos contratos. DCC: Direção de Compras e Contratos da Galp. Representa o Comprador. Assegura a comunicação entre a DSI, os Integradores e/ou outros fornecedores durante o processo de consulta e avaliação de propostas. Gere a avaliação económica de propostas. Assegura o processo de aquisição de serviços adicionais ao Integrador do Projeto de SI, em função de alterações de âmbito. DAJG: Direção de Assuntos Jurídicos e Governance. Assegura o processo de elaboração e negociação do contrato de suporte à prestação dos serviços de fornecedores externos.

Outsourcers – Fornecedores de Serviços de Sistemas de Informação ao qual foram contratados diversos serviços de gestão continuada de recursos de SI/TI, que necessitam ser utilizados em sede de Projeto de SI.

Focal Point Outsourcer: Assegura a resposta do Outsourcer aos pedidos solicitados pelo Projeto de SI, dentro do calendário acordado e nos termos do contrato de prestação de serviços estabelecido. Assegura a disponibilidade de sistemas de suporte ao Projeto de SI. Alerta a Gestão de Projeto para todas as situações que possam provocar impacto no Projeto de SI ou na solução em desenvolvimento. Assegura a validação das condições de passagem da solução a ambiente de qualidade e produção. Valida a documentação técnica do Projeto de SI. Disponibiliza informação sobre as aplicações/sistemas sempre que solicitado. Participa nas sessões de passagem de conhecimento e em reuniões de gestão.

V01 Pág 15/22


Equipa do Outsourcer: Desenvolve as atividades contratadas decorrentes do Projeto de SI, de acordo com o plano e calendário acordados e sob orientação do Focal Point do Outsourcer.

Principais Entregáveis

A Figura 4 - Principais Entregáveis da Execução de um Projeto de SI, representa os principais documentos gerados e geridos por um Projeto de SI.

Figura 4 - Principais Entregáveis da Execução de um Projeto de SI

Para a maior parte deles está definido um template, que deverá ser utilizado pelos vários elementos da equipa de projeto, para os criar e publicar. A lista dos principais templates, utilizáveis na fase de execução de um Projeto de SI, é a seguinte:

Etapa do Projeto Nome

Gestão do Calendário PMOT000 [cód projeto] Plano de Projeto n.a. PMOT001 Template Word n.a. PMOT002 Template PPT n.a. PMOT003 Template Excel

V01 Pág 16/22


Etapa do Projeto Nome

Gestão da Comunicação PMOT004 [cód projeto] Ata [nome da reunião] AAMMDD Gestão da Comunicação PMOT005 [cód projeto] Ponto de Situação AAMMDD Gestão da Comunicação PMOT006 [cód projeto] Reunião de Kick-Off Gestão da Comunicação PMOT007 [cód projeto] Stakeholders e Responsabilidades Gestão do Orçamento PMOT008 Controlo Orçamental Projetos Gestão da Comunicação PMOT009 [cód projeto] Plano de Comunicação Gestão de Recursos PMOT010 [cód projeto] Estimativa [Outsourcer] Gestão de Recursos PMOT011 [Outsourcer] Relatório Mensal Horas vAAMM Gestão de Recursos PMOT012 Horas Recurso Externo [Iniciais Nome] Gestão de Recursos PMOT013 [fornecedor] Horas de AQ Gestão de Recursos PMOT014 AQ_OrdemEncomenda_PXXXXnn_v01 Gestão de Recursos PMOT015 [cód projeto] Plano Viagens Gestão de Issues e Riscos PMOT021 [cód projeto] Issues e Riscos Go-Live e Suporte PMOT090 [cód projeto] Aceitação de Projeto Go-Live e Suporte PMOT091 [cód projeto] Inquérito de satisfação Gestão do Calendário PMOT100 [cód projeto] Plano de Preparação

Tabela 2 - Lista de templates

Passagens entre ambientes e CEP

A partir da etapa de Implementação, o Projeto de SI terá de assegurar que a solução construída passa por um conjunto de estádios (de validação) diferentes até que esta seja disponibilizada na sua versão final no ambiente produtivo. Nesse processo, a solução deverá passar por ambientes intermédios, cada um com a sua finalidade (diversos tipos de testes, avaliação de qualidade, formação, e outras ações dependentes do tipo de projeto, tecnologia e solução).

O processo de gestão da passagem das aplicações (ou suas componentes) entre ambientes, no âmbito de Projetos de Sistemas de Informação na Galp, é definido por um conjunto de passos formais, cujas regras e os procedimentos de planeamento, aprovação e coordenação são sistematizados num documento específico, e sumarizadas neste capítulo.

Este processo, pelo seu impacto e risco associado, pelo número de pessoas e entidades que envolvem, e pelas interações necessárias, requer um nível elevado de formalismo, coordenação e controlo, e podem ocorrer a partir do final da etapa de implementação, até ao fim do projeto. Em Projetos de SI que sejam realizados seguindo metodologias alternativas (tipo Agile), os processos e formalismos aqui referidos podem ter características diferentes, sejam estes tarefas,

V01 Pág 17/22


responsabilidades, ambientes, equipas, validações ou avaliações, mas terão de ser definidos e aprovados como exceção, seja em fase de Preparação do Projeto de SI (logo desde a etapa de consulta ao mercado), seja no início da Execução do Projeto de SI, na sua etapa de Setup.

5.1 Enquadramento

As promoções entre ambientes podem ter várias designações, todas válidas, sendo todas sinónimas entre si. Destacam-se as seguintes: Passagem a Qualidade / Passagem a Produção, Entrada em Qualidade / Entrada em Produção, Deploy a Qualidade / Deploy a Produção, Transporte a Qualidade / Transporte a Produção (mais utilizados nas passagens de componentes do sistema SAP). Os procedimentos estabelecidos para as passagens a qualidade ou produção têm como objetivo garantir que:

• Todas as passagens são solicitadas através dos canais próprios e devidamente programadas; • Todas as passagens são prévia e devidamente comunicadas às entidades relevantes; • A resolução de eventuais conflitos é decidida de forma central, minimizando o risco e

maximizando a defesa do interesse da Galp; • Existiu a aprovação necessária para as passagens; • As equipas asseguram antecipadamente a adequada capacidade para resposta às solicitações

de passagens; • As novas funcionalidades não impactarão o normal funcionamento dos sistemas em produção

ou dos projetos em curso; • Cada passagem fica registada num “Log” centralizado.

5.2 Releases

Uma Release é um conjunto de objetos / alterações resultantes de um ou mais projetos, que deverão ser passados simultaneamente entre ambientes. Uma Project Release é uma release com objetos apenas resultantes de um único projeto. Também são conhecidos como deploy, transporte ou “passagem para qualidade” ou “passagem para produção”, sendo estes termos utilizados como sinónimos neste documento. As releases/passagens/deploys/transportes podem ser classificadas em 3 tipos: Major Project Release (MjPR) – passagem de componentes novas de uma solução desenvolvida por um projeto. Um projeto pode ter mais do que uma Major Project Release, caso se considere que correspondem a grupos de funcionalidades relativamente independentes entre si.

• As Major Project Release são planeadas no início do projeto, podendo ser replaneadas ao longo do mesmo.

V01 Pág 18/22


Minor Project Release (MnPR) - passagem que corrige ou introduz pequenos ajustes numa solução já existente no ambiente destino. Corresponde a um ajuste a uma MjPR anterior. Normalmente inclui apenas correções de erros mas pode incluir ajustes a funcionalidades sem impacto em termos de estrutura da solução.

• É expetativa que estas situações de correção não levem à criação de novos objetos técnicos. Quando estes tenham de ser gerados, a respetiva justificação deve ser explicitamente referida nos documentos criados e validados. O impacto desses novos objetos não representa a criação de uma nova funcionalidade;

• A complexidade e o tempo da execução deve ser inferior à execução do deploy original; • Por cada Major Project Release, consideram-se planeada e aprovada uma sequência de Minor

Project Releases, uma em cada semana subsequente à data da MjPR. Emergency Project Release (EmPR) – passagem relacionada com a correção de funcionalidades ou execução de data repairs, que seja necessária realizar fora do plano estabelecido para as MjPR e MnPRs. Estas só devem ocorrer por razões inadiáveis e devidamente comprovadas de urgência.

5.3 Organização

Pré-CEP – conjunto de atividades com o objetivo de validar e confirmar que estão reunidas todas as condições técnicas (cumprimento de todos os critérios de passagem) para que seja efetuada a passagem de ambiente solicitada. Corresponde à avaliação da conformidade técnica da solução e das passagens em avaliação. Na preparação de uma Major Release, e como regra geral, o Pré-CEP formaliza-se com uma reunião em formato presencial ou remota (chamada de “Reunião de Pré-CEP”), antes do CEP da semana anterior ao deploy, tendo como objetivo passagens de ambientes na semana seguinte. Nas Minor Releases, passagens simples ou já muito debatidas previamente, pode ser omitida a necessidade de uma reunião específica, sendo as condições de passagem validadas nas reuniões de projeto e por email. Seja qual for o caso, deve existir uma Ata (em formato email) que expressa a validação dos vários intervenientes, e aprova tecnicamente o respetivo deploy. Os Pré-CEPs são agendados e coordenados pelo gestor de projeto do Integrador e nela participam obrigatoriamente os focal points dos outsourcers de Manutenção Aplicacional e de Infraestruturas/ Midrange, o focal point da equipa de Arquitetura e Standards da DSI e o Gestor de Projeto DSI, devendo todos aprovarem a respetiva release. CEP (Comité de Entradas em Produção): Órgão que se reúne semanalmente (à 6ª feira, salvo raras exceções), para apreciar os pedidos de passagem entre ambientes, apreciando de forma agregada o plano apresentado, considerando a disponibilidade de recursos, os potenciais conflitos e a

V01 Pág 19/22


elegibilidade face aos requisitos de aceitação de projetos. Corresponde à avaliação da conformidade de agenda e recursos para execução das releases. A reunião de CEP é agendada e coordenada pela equipa de Infraestruturas e Operações da DSI, assegura uma análise detalhada dos pedidos de passagens para a semana seguinte, e toma decisões sobre situações de conflito e prioridades, aprovando ou rejeitando as releases propostas.

5.4 Minor Releases, Emergency Releases e CEPs Extraordinários

Estão previstas exceções para as Minor Project Release (MnPR), que permitem expeditar o processo de validação e aprovação, em determinadas condições, em particular quando estas não incluam alterações na estrutura da solução. Uma Emergency Project Release (EmPR), pelo contrário, após reunida aprovação técnica através de um processo de Pré-CEP, tem de ser aprovada explicitamente (escrito / mail) pela Gestão de Projeto (pelo menos dos Gestor de Projeto do Negócio + Gestor de Projeto da DSI), justificando a urgência. Quando os erros e/ou impactos forem transversais ou comprovadamente graves, ou sob proposta de uma das áreas de Operações e Aplicações, considera-se que a EmPR está implicitamente aprovada. Nas restantes situações, a aprovação final é dada pelo diretor de 2ª linha da DSI responsável pelo projeto (Projetos Estruturais, Aplicações, Infraestruturas, Cibersegurança, Arquitetura). Passagens corretivas para Qualidade (p.ex. na plataforma SAP) podem ocorrer com maior frequência do que o agendamento semanal, desde que acordadas com os Outsourcers, não sendo necessário o processo de aprovação de uma EmPR. Os CEPs Extraordinários são reuniões ad hoc de CEP, executadas fora do período normal das mesmas, convocadas pelo Gestor de Projeto DSI. Tem o objetivo de validar e aprovar a execução de uma release (Major, Minor ou Emergency) que não tenha sido planeada / aprovada na reunião CEP regular anterior, e a execução do deploy deve ocorrer antes da reunião regular seguinte.

Matriz de Responsabilidades

6.1 Projetos de SI – Etapas da Fase de Execução

Atividades / Intervenientes Gestão

de Projeto1

DSI UN/UO2 Integra-dor

Outsour-cer

Set-up ER C E E • Definir equipa projeto e stakeholders -- ER C C C • Tratar logística e acessos projeto ER E C C E

V01 Pág 20/22



de Projeto1


Outsour-cer

• Elaborar plano de recursos HW, SW e outros C R C E C • Identificar interações, dependências e impactos R C C E C • Estabelecer plano de deliverables R C C E C • Estabelecer plano detalhado do projeto R C C E C • Preparar e realizar Kick-off (1º Steering) R C C E C • Definir plano de viagens E R C E C • Agendar datas preliminares de deploys R E C C C

Desenho R C C E C • Estudar os atuais processos, sistemas e

plataformas Galp, relevante para âmbito C C C ER C

• Estabelecer impactos e âmbito de intervenção R C C E • Elaborar desenho funcional C C R E • Elaborar desenho técnico (arquitetura

aplicacional) de alto nível C R C E

• Disponibilizar infraestrutura técnica de suporte C R C E E • Obter acessos a sistemas específicos R E C C E • Definir e planear testes a efetuar R C C E C • Aprovar Desenho ER C C C

Implementação R C C E C • Desenvolver a solução I I I ER I • Efetuar testes funcionais e técnicos I I I ER I • Elaborar documentação técnica de detalhe I C ER C • Preparar passagem a qualidade C C I ER E • Atualizar plano de testes R C C E C • Construir (alterar se já existir) o modelo

operativo da solução, a aplicar após go-live C C C ER C

Formação R C C E • Identificar formandos I I ER C • Planear formação (sessões e conteúdos) C C C ER • Envolver Centro de Formação DRH (opcional) ER E C I • Organizar logística da formação (salas e

equipamentos) ER E C C C

• Convocar formandos I I ER3 I • Preparar materiais de suporte, dados e casos

para formação C I C ER C

• Elaborar Manual de Utilizador C C R E • Realizar a formação I I C ER C • Obter avaliação da formação R C C E

Testes à Solução C C ER E C • Identificar participantes nos testes I I ER I • Planear testes de aceitação (sessões e tópicos) I C C ER C • Preparar casos de testes C I C ER C • Preparar dados de testes E I ER C • Organizar logística para testes (salas e

equipamentos) ER E C C C

• Realizar os testes de aceitação I C ER E C • Realizar os testes (outros testes) I I I ER C • Registar e publicar resultado dos testes C C C ER C • Preparar entrada em produção – aprovada em

CEP I C I ER E

• Consolidar e validar modelo operativo da solução, a aplicar após go-live e aceitação C C C ER C

Go-Live e Suporte pós Go-Live C C C ER C • Corrigir os issues em aberto do projeto I C C ER C

V01 Pág 21/22



de Projeto1


Outsour-cer

• Validar a solução para efeitos de aceitação funcional C C ER C C

• Passar conhecimento técnico (aplicacional, de exploração e suporte) I C I ER E

• Fechar e aprovar a documentação da solução funcional C C R E E

• Fechar e aprovar a documentação da solução técnica C R C E E

• Assegurar que todas as sources estão disponibilizadas nos repositórios finais (TFS e/ou outros)

I C I ER E

• Aprovar o modelo operativo da solução, a aplicar após go-live e aceitação C ER I C C

Fecho do Projeto C ER C C C • Assegurar a aceitação Provisória do Projeto

(Inicio do Período de Transição) C C I ER E

• Assegurar a Aceitação Definitiva ou handover do projeto – Fecho Técnico C C I ER E

• Assegurar e enquadrar contratualmente o suporte à exploração da solução I ER E

• Corrigir issues em aberto do projeto C C C ER C • Formalizar Aceitação Definitiva (ou Handover) C ER I C C

Tabela 3 - Matriz RECI - Fase de Execução de Projeto de SI

Legenda: E: Executante (principal executante da etapa) R: Responsável (responsável pelo resultado, decisor) C: Consultado (deve ser consultado durante a etapa) I: Informado (deve ser informado do resultado da etapa)

Nota1: Gestão de Projeto como referido no capítulo 3.6 deste documento.

Nota2: UO participantes no projeto.

Nota3: A convocação de formando é da responsabilidade da Direção de Pessoas, ou das UOs participantes no projeto.

6.2 Projetos de SI – Disciplinas transversais gestão de projeto


de Projeto1


Outsour-cer

Gestão do Âmbito do Projeto de SI R C C E • Identificar CRs C C C ER • Executar processo aprovação CRs ER C C C

Gestão do Orçamento do Projeto de SI ER4 C C C C • Identificar impactos ao orçamento projeto R E C C • Executar processo aprovação revisões ao

orçamento C ER C C

Gestão da Comunicação do Projeto de SI R C C E • Definir Estratégia (tática) de Comunicação R C C E • Planear Comunicação C C C ER • Executar ações de Comunicação C C C ER • Preparar reuniões periódicas C C C ER C • Elaborar documentos de suporte, e atas de

reunião R C C E

• Apresentação/condução reuniões (Steering) ER4 C C C

V01 Pág 22/22



de Projeto1


Outsour-cer

• Apresentação/condução reuniões (outras) C C C ER C Gestão do Calendário do Projeto de SI R C C E C

• Definição do primeiro baseline R C C E C • Atualizar semanalmente o calendário do projeto C C C ER C • Identificar impactos no calendário de projeto C C C ER C • Executar processo de aprovação de novo

baseline R E C C I

Gestão de Riscos do Projeto de SI R C C E C • Identificar os riscos e issues do projeto R C C E C • Efetuar a análise de riscos e issues R C C E C • Definir ações de mitigação R C C E C • Executar ações de mitigação R C C E C • Monitorizar e controlar R C C E C

Tabela 4 - Matriz RECI - Disciplinas transversais de Gestão de Projeto de SI




Nota3: A convocação de formando é da responsabilidade da Direção de Pessoas, ou das UOs participantes no projeto.

Nota4: responsabilidade é da Gestão de Projeto, mas sem a inclusão do Gestor de Projeto do Integrador.


de Projeto1


Outsour-cer

Passagens entre ambientes e CEP I C I ER E • Planear datas de passagens C R C E C • Efetuar pedido de passagem I C ER C • Avaliar condições de passagem – Pré-CEP C R C E C • Realizar CEP e comunicar resultado I ER I I E • Executar passagem I ER E • Validar passagem I I I ER C

Tabela 5 - Matriz RECI - Passagens entre ambientes e CEP




Documents

Gestão de Projetos de SI v01 - galpenergia.com · Um Projeto de SI pode ter um ou mais Unidades Organizativas (UO) do Grupo Galp que usufruem do resultado e benefícios do Projeto