Metodologia de GP para implementação de pacotes de softwares

Metodologia de gestão de projetos para implementação de pacotes de softwares gestão comercial

O objetivo desse post não é o enquadramento científico, sim a partir de uma experiência pratica citar uma metodologia que pode ser considerada como base na utilização de projetos de tecnologia da informação voltados a implantação de soluções de software.

Em setembro de 2013 participei da implantação de um pacote de software comercial voltado para gerenciamento de ativos, uma plataforma EAM. Minha função era atuar como gestor estratégico do projeto, buscando o alinhamento de qual metodologia iriamos utilizar, sim porque o cliente que adquiriu a solução por força contratou exigiu que utilizássemos a metodologia ASAP, então iniciou-se o meu primeiro contato com processos diferentes de todos aqueles com os quais já havia trabalhado.

O que é o ASAP?

A SAP é a maior empresa do mundo que vende softwares comerciais, líder global de mercado em soluções de negócios colaborativos e multiempresas, possui uma metodologia própria de implantação dos seus sistemas, o método ASAP, Acceletated SAP, um modelo que endereça diversas práticas de engenharia de software e gestão de projetos, utiliza conceitos do CMMI, MPS.BR e PMBOK Guide, claro que longe desses em maturidade e reconhecidos no mercado, mas ajuda na implementação de projetos com grande eficácia.

A metodologia ASAP apresenta 5 pilares ou 5 fases comuns na implementação de projetos de software que passam desde a definição do escopo, especificação funcional, design, construção, testes, validação e instalação no ambiente de produção, as fases tem a missão de manter o projeto o mais controlável possível.

Vamos conhecer cada fase:

1ª – PROJECT PREPARATION – ASAP

Na primeira fase são executados os processos que visam a definição do escopo do projeto com o detalhamento e a elaboração das estimativas, a estratégia de execução e controle do projeto é definida, o alinhamento com todos os usuários é feito através de reuniões de entendimento. Finaliza essa fase com a realização do Kick-Off do projeto.

Objetivos e definições desse processo:

• Definição dos Key-Users (Usuários Chave)
• Definição do escopo de implementação.
• Definição da estratégia de implementação.
• Definição da organização e padrão de documentos.
• Definição do cronograma da implementação.
• Treinamento da equipe de projeto quanto ao método de implantação.

2ª –  “BUSINESS BLUEPRINT” – MODELO DOS PROCESSOS DE NEGÓCIO

Chega o momento em que os analistas funcionais devem levantar e detalhar os requisitos do negócio, seus processos manuais e automatizados, visão dos sistemas já existentes, bases de dados (principais bancos de dados), entendimento de todos os impactos da tecnologia frente a operação.

Tudo será documentado e consolidado em um modelo chamado “Business BluePrint”, que irá endereçar assuntos como:

a)    Levantamento do(s) processo(s) de negócio.

b)    Plano de gestão do projeto.

c)    Mudanças organizacionais (estratégia e tratamento)

d)    Plano de treinamentos (usuários chaves, demais usuários)

e)    Definições da configuração do ambiente tecnológico para desenvolvimento.

f)     Definições dos novos processos de negócio.

g)    Plano de qualidade (requisitos, itens de validação, indicadores).

O plano de gestão do projeto deverá descrever outros importantes planos, como: plano de gerenciamento de riscos, plano de gerenciamento de recursos humanos, orçamento, cronograma, plano de gerenciamento de comunicação).

Objetivos e definições desse processo:

• Definição do documento denominado “Business BluePrint”.
• Definição da estrutura organizacional da empresa;.
• Desenho dos processos.
• Revisão dos processos de negócio.
• Documentação do escopo/desenho dos processos.
• Treinamento da equipe de projeto nos processos abordados.

3ª – “REALIZATION” – REALIZAÇÃO

Nessa fase a documentação do projeto e do modelo de negócios está definida, são resultados da fase anterior, a equipe de projeto tem os insumos básicos para iniciar os trabalhos em 2 passos:

a)    Os consultores com base na documentação criam os protótipos.

b)    Os usuários finais iniciam a verificação dos protótipos apontando os ajustes necessários já com a configuração em detalhes.

Objetivos e definições desse processo:

• Execução do “Business BluePrint”.
• Parametrização do sistema e da estrutura organizacional;
• Desenvolvimento e Customização dos processos baseados no “Business Blueprint“.
• Criação dos perfis de autorização;
• Testes integrados em ambiente de homologação.

4ª  –  “FINAL PREPARATION” – PREPARAÇÃO FINAL 

O objetivo desta fase é analisar e preparar o projeto para o Go Live, a validação dos testes integrados e os indicadores do nível de maturidade de sucesso dos cases validados em homologação irão determinar como a implantação em produção deverá ser feita.

Objetivos e definições desse processo:

• Plano de entrada em produção.
• Teste da carga de dados/Volume de dados.
• Treinamento dos usuários finais;

5ª – “GO LIVE” – ENTRADA EM PRODUÇÃO

O propósito desta fase é a entrada em produção do sistema, passagem para o ambiente de produção da solução validada. O plano desenhado na etapa anterior é amplo, determina de acordo com o volume de dados em quantas etapas a implantação será executada, também quais os procedimentos de regressão.

Objetivos e definições desse processo:

• Ajustes técnicos (Hardware, Sistema Operacional, Rede de Dados).
• Instalação
• Validação com usuários chave.
• Operação assistida (período à definir)
• Suporte aos usuários
• Pós implantação – Lições aprendidas.

Essa metodologia deve ser utilizada com suporte do Guia de Melhores Práticas de Gestão de Projetos – PMBOK 5ª edição – 2013, os planos de projeto encontrarão referências para mitigar qualquer dúvida em sua elaboração.

O levantamento de requisitos, um dos principais fatores de insucesso em projetos deverá ser feito com procedimentos padrão de mercado, encontraremos suporte no CMMi ou MPS.br, a atividade de gerência de requisitos tem por objetivo mapear os requisitos identificados na fase inicial de um projeto e rastreá-los até os artefatos finais, permitindo a validação da consistência entre os mesmos e as requisições originalmente vindas dos solicitantes.

Os processos de extração de requisitos representam o elo de ligação entre as áreas de planejamento do projeto, solução técnica e gerência de mudança.

Podemos visualizar o ciclo de vida de um projeto em ASAP.

A figura acima atrás um modelo do ASAP de um projeto SAP com a linha do tempo clara e definida, pontos importantes como a assinatura do contrato e o kick-off estão claramente descritos demonstrando a atenção que deve ser dada.

O que me deixou muito satisfeito na participação desse projeto utilizando o ASAP foi a perspectiva que a metodologia me deu sobre como seria a empresa após a implantação, o TO-BE, existe uma preocupação quanto a mudança e seus impactos, a adaptação de todos os envolvidos.

Outras experiência não me deram a mesma ideia, sim a forte necessidade de entender como é o processo agora, importante também, mas tira minha visão do objetivo do projeto, do que meu cliente espera no final, algo que deve estar claro para a equipe do projeto.

Ainda não tive a oportunidade de utilizar o ASAP integrado a outras metodologias, como o Prince2 ou SCRUM, mas não vejo dificuldade ou impossibilidade, o ASAP seria um dos estágios no Prince2, o SCRUM poderia ser utilizado como framework pelas equipes de desenvolvedores dentro do ASAP.

Acredito que os projetos de implementação de software, não somente projetos SAP, podem utilizar o ASAP como metodologia, projetos de pequeno e médio porte por exemplo. Essa metodologia com pequenas adequações poderá ser utilizada em qualquer empresa.  Um escritório de projetos que está em fase de consolidação e amadurecimento, buscando implantar padrões que serão utilizados por quem vai gerir projetos, encontrará no ASAP uma metodologia consolidada no mercado.

Não posso deixar de reforçar a necessidade de tratar riscos e comunicação dentro da metodologia, são temas que embora não descritos de forma clara devem ser analisados e geridos durante todo o ciclo de vida do projeto.

Quero agradecer a oportunidade de compartilhar, fiquem livres para comentar, acrescentar, vejo uma oportunidade de evolução sobre o tema, estou disponível para aprender mais um pouco.

Abraço a todos,

Sobre o Colunista: Marco Antonio da Silva, Profissional com 20 anos de experiência no desenvolvendo soluções de tecnologia da informação e processos para empresas de grande e médio porte nacionais em internacionais do segmento: financeiro, telecom, agro indústria, automobilístico e prestação de serviços. Gerente de projetos, instrutor e pesquisador de modelos de negócios inovadores, graduado em processamento de dados, pós-graduado em análise de sistemas e mba em gestão estratégica de tecnologia da informação, certificado PMP, CSM, Prince2 Practitioner, COBIT e MCTS, atualmente desenvolve soluções customizadas para medição de desempenho de projetos e portfólio, assim como alinhamento estratégico operacional.

E-mail de contato: spmarcoantonio@gmail.com

Se você tem comentários, sugestões ou alguma dúvida que gostaria de esclarecer, aproveite o espaço a seguir.