Embed Size (px)
Citation preview
UNIVERSIDADE SÃO FRANCISCO Engenharia de Computação
BRUNNO ALVES FERREIRA JEFERSON ANDRÉ PUGAS TIAGO DE OLIVEIRA LEME
PLANO DE PROJETO UTILIZANDO A METODOLOGIA PMBOK
PARA MIGRAÇÃO DE VERSÃO DO ERP PROTHEUS
Itatiba 2013
BRUNNO ALVES FERREIRA – R.A. 002200800159 JEFERSON ANDRÉ PUGAS – R.A. 002200500179 TIAGO DE OLIVEIRA LEME – R.A. 002200800166
PLANO DE PROJETO UTILIZANDO A METODOLOGIA PMBOK
PARA MIGRAÇÃO DE VERSÃO DO ERP PROTHEUS
Monografia apresentada ao Curso de Engenharia de Computação da Universidade São Francisco, como requisito parcial para obtenção do título de Bacharel em Engenharia de Computação.
Orientador: Prof.ª Vânia Franciscon Vieira
Itatiba 2013
As nossas famílias e amigos.
AGRADECIMENTOS
Agradecemos, as nossas famílias, por tudo.
Aos nossos amigos e colegas, pelo incentivo e pelo apoio constante.
A Professora Vânia F. Vieira, pela paciência na orientação e incentivo que
tornaram possível a conclusão deste trabalho de conclusão de curso.
RESUMO
O ERP é uma plataforma de software que foi desenvolvida com o objetivo de
unificar diversos setores de uma empresa, possibilitando a automação e
armazenamento de todas as regras de negócio. Com as evoluções apresentadas nos
processos envolvidos com o ERP e com a evolução da arquitetura de T.I. a aplicação
ERP e seus componentes precisam se adequar às atualizações que o mercado sofre
periodicamente. Para o planejamento e realização dessas adequações foi utilizado o
PMBOK, um conjunto de práticas que permite gerenciar projetos de diferentes áreas,
inclusive a migração de versão do sistema Protheus. Utilizando os conceitos do
PMBOK foi criado um plano de projeto para o auxilio na migração de versão do ERP
Protheus.
Palavras-chave: PMBOK. Protheus. Enterprise Resource Planning. Gerencia de Projetos.
ABSTRACT
The ERP is a software platform that has been developed with the goal of unifying
various departments of a company, enabling the automation and storage of all
business information. With the evolution presented in the processes involved with the
ERP and the IT architecture evolution, the ERP application and its components need
to comply with the updates that the market suffers periodically. For planning and
carrying out these adjustments it has been created the PMBOK, a set of practices that
enables to manage projects from different areas, including Protheus system version
migration. Using the concepts of PMBOK a project plan has been created to aid in the
ERP Protheus version migration.
Key words: PMBOK. Protheus. Enterprise Resource Planning. Project Management.
LISTA DE ILUSTRAÇÕES
Figura 1 – Tela de Instalação Protheus ............................................................ 33
Figura 2 – Parâmetro Inicialização do Sistema ................................................. 37
Figura 3 – Introdução ao Migrador de versão ................................................... 37
Figura 4 – Tela de login para inicialização do migrador .................................... 38
Figura 5 – Escolha da versão para qual será atualizado o sistema. ................. 39
Figura 6 – Escolha do diretório raiz do sistema. ............................................... 39
Figura 7 – Configuração do processo de atualização. ...................................... 40
Figura 8 – Empresas e tarefas que serão executadas no migrador. ................ 41
LISTA DE TABELAS
Tabela 1 – Subdiretórios x Descrição. .............................................................. 30
LISTA DE ABREVIATURAS E SIGLAS
ERP – Enterprise Resourse Planning (Planejamento dos Recusros da
Empresa)
MRP I – Material Requirement Planning (Planejamento das Necessidades do
Material)
MRP II – Manufacturing Resources Planning (Planejamento dos Recursos de
Manufatura)
PMBOK – Project Management Body of Knowledge (Conjunto
de Conhecimentos em Gerenciamento de Projetos)
PGP – Plano de Gerenciamento de Projeto
PMI – Project Management Institute (Instituto de Gestão de Projetos)
PMQ – Project Management Quarterly (Gestão de Projeto Trimestral)
SUMÁRIO
1. INTRODUÇÃO ............................................................................................................. 12
2. OBJETIVO ................................................................................................................... 14
3. METODOLOGIA .......................................................................................................... 15
4. GERENCIAMENTO DE PROJETOS ........................................................................... 16
5. PROJECT MANAGEMENT INSTITUTE (PMI) ............................................................ 17
5.1 A Guide to the Project Management Body of Knowledge (PMBOK) ................ 17
5.2 Project Management Professional (PMP) ......................................................... 23
5.3 Plano de projeto ................................................................................................ 24
5.4 Escopo do Projeto ............................................................................................. 24
5.5 Gestão de tempo .............................................................................................. 25
5.6 Gestão de riscos ............................................................................................... 26
6. ELABORAÇÃO DO PLANO DE PROJETO ................................................................ 27
6.1 Escopo do projeto ............................................................................................. 27
6.2 Gerenciamento do Tempo ................................................................................ 28
6.2.1. Definição e Sequenciamento das atividades ................................................ 29
6.2.2. Preparação do ambiente a ser migrado ....................................................... 31
6.2.3. Instalação da nova versão ........................................................................... 32
6.2.4. Atualização da nova versão ......................................................................... 33
6.2.5. Preparando o Ambiente a ser migrado ......................................................... 35
6.2.6. Executando o atualizador de versão (MP710TO110) ................................... 36
6.3 Gerenciamento de recursos humanos do projeto ............................................. 42
6.4 Gerenciamento de custos do projeto ................................................................ 42
6.5 Gerenciamento de qualidade do projeto ........................................................... 43
6.6 Gerenciamento de riscos do projeto ................................................................. 44
6.6.1. Definição dos riscos ..................................................................................... 45
6.6.2. Identificação os riscos .................................................................................. 45
7. CONCLUSÃO .............................................................................................................. 46
8. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................ 47
12
1. INTRODUÇÃO
O termo Enterprise Resources Planning ou Planejamento dos Recursos da
Empresa - começou a ser utilizado no Brasil em meados da década de 90 quando as
empresas estrangeiras começaram a se estabelecer no nosso país. A origem desta
sigla tem uma trilha bastante curiosa. Há de se lembrar de que uma das primeiras
grandes aplicações comerciais, ainda na época dos mainframes, em 1960, foi um
sistema denominado MRP I – Material Requirement Planning, e que basicamente
calcula a necessidade de compra de matérias-primas e produção de componentes a
partir de previsão de vendas e de uma situação de estoque. Isto, em grandes fábricas,
com grandes quantidades de produtos acabados, inúmeros níveis de componentes,
cada um formado por matérias-primas utilizadas muitas vezes em quantidades
diferentes, é um calculo bastante trabalhoso. (Haberkorn, Ernesto, 2003)
Se por um lado o MRP informa o que deve ser produzido e comprado, por outro
ele não diz como. E como quem dá a missão deve fornecer os meios, surgiram a
seguir, já na década de 70, os sistemas MRP II. A sigla é mera coincidência, daí a
diferenciação pelo ordinal I e II. MRP II significa Manufacturing Resources Planning,
traduzindo Planejamento dos Recursos de Manufatura. Através do MRP II é possível
saber quem vai produzir, quando e com quais recursos, ou seja, a fábrica é alocada
minuto a minuto, operação a operação de acordo com um calendário pré-definido e
um conjunto de recursos disponíveis. (Haberkorn, Ernesto, 2003).
Com as evoluções apresentadas nos processos envolvidos com o ERP
(obrigações fiscais, leis trabalhistas) e com a evolução da arquitetura de T.I. (Sistema
Operacional, Banco de Dados) a aplicação ERP e seus componentes precisam se
adequar a essas atualizações que o mercado sofre periodicamente. Por exemplo, com
a evolução da arquitetura dos sistemas operacionais de 32 para 64 bits, as aplicações
ERP necessitam ser adequadas para que possam operar de forma otimizada nessa
nova plataforma. Outro ponto importante é o ciclo de vida do suporte que o fabricante
oferece para cada versão do ERP, ou seja, em determinado ponto o fabricante para
de oferecer suporte à determinada versão da aplicação, ou seja, em um caso de
indisponibilidade aonde todos os processos de correção documentos não são
suficientes para efetuar a correção do erro, o analista responsável pela aplicação não
13
pode mais recorrer ao fabricante solicitando um novo procedimento e/ou patch de
correção, esse mesmo conceito é aplicado para a infraestrutura que suporta aplicação
(sistema operacional, banco de dados, hardware, etc.). Nesses casos de falha a
empresa responsável apenas informa o cliente que a aplicação não é mais suportada
e também sugere as versões que a aplicação pode ser migrada, caso a aplicação seja
migrada e o erro persista o fornecedor toma uma ação de correção. Com a falta de
suporte do fabricante, os períodos de downtime podem ser mais constantes visto que
comparado com a versão suportada, a versão em backlevel não possui nenhum
atualização de correção (patches, workarounds, atualizações de registros, etc.).
Para que sejam evitados estes tipos de problemas e conduzir uma implantação
eficiente que atenda os requisitos do cliente com qualidade, deve-se ter uma equipe
de implantação com conhecimentos aprofundados em técnicas de gestão de projeto,
a fim de focar a atenção aos pontos mais críticos no processo de implantação para
obter sucesso. Tendo como base estas premissas, torna-se então viável a utilização
dos conceitos do PMBOK para gerenciar este tipo de projeto. A metodologia PMBOK
consiste de ferramentas que ajudam a entrega do produto mais ágil e de acordo com
os padrões especificados pelo cliente em questão, mantendo como foco principal o
controle dos riscos e melhoria contínua da qualidade do produto, atendendo aos
padrões do Instituto de Gerenciamento de Projetos (PMI) e utilizando de boas práticas
para que sejam apresentadas melhorias desde a ideia até a fase de apresentação e
avaliação de resultados.
Os fatores abordados nas práticas de gestão de projetos são interdependentes,
ou seja, qualquer fator que seja alterado no plano de projeto provavelmente resultará
na alteração dos demais recursos do mesmo, ocasionando na melhoria ou total
desequilíbrio na execução do projeto. Além de todos estes conceitos, o gerente do
projeto deve analisar e gerenciar toda e qualquer influência que agentes internos e
externos possam gerar para que seja efetivamente garantido um resultado de
sucesso.
14
2. OBJETIVO
O objetivo do presente trabalho de conclusão de curso é apresentar um plano
de projeto de migração de versão do ERP Protheus, utilizando das práticas contidas
no PMBOK, mostrando a eficácia da implantação de uma solução previamente
planejada com etapas definidas e que possui como principal característica a
possibilidade de gerenciar de forma eficaz escopo, tempo, risco, qualidade e
comunicação entre as partes envolvidas.
15
3. METODOLOGIA
Foi desenvolvida a documentação baseada em conteúdos bibliográficos
criando um plano de gerenciamento de projeto dentro dos conceitos abordados pelo
PMBOK.
O escopo do projeto envolve a descrição da situação geradora do projeto e os
objetivos específicos, apresentando quais são as dificuldades inicias e quais as
necessidades pertinentes ao plano de projeto. O escopo aborda também quais os
resultados esperados com a implantação de um possível projeto e qual será o alvo da
implantação da solução que será definida na conclusão do plano de projeto.
Os riscos estarão presentes em todas as áreas do projeto, desde um problema
com variação dos prazos a problemas com quaisquer partes envolvidas no mesmo. A
avaliação destes riscos torna-se uma tarefa de suma importância, pois qualquer
variação que não tenha sido prevista pode levar o projeto a tornar-se inviável. Melhor
do que definir os riscos, é poder analisá-los e classificá-los para que o planejamento
de resposta seja feito de maneira eficaz, garantindo que as surpresas durante a
execução do projeto sejam as menores possíveis.
Foi elaborado um levantamento dos procedimentos e requisitos que abrangem
a migração do sistema. Dentre os requisitos, foram levados em conta as configurações
de hardware dos equipamentos envolvidos, os softwares que serão utilizados no
processo e na execução do sistema e a qualificação técnica dos profissionais que irão
executar a migração.
Baseado nos procedimentos e requisitos foi elaborado um documento que
contempla o detalhamento da execução da migração do Protheus. Neste documento
são abordadas as etapas básicas de como deverá ser executada a migração, bem
como os troubleshootings para os erros já documentados pelo desenvolvedor da
aplicação.
16
4. GERENCIAMENTO DE PROJETOS
A área chave de pesquisa deste projeto foi o gerenciamento de projetos. Essa
pesquisa envolveu os mais variados autores e teve como principal referência as
práticas contidas no guia de gerenciamento de projetos, o PMBOK. O benefício da
especialização desta área de pesquisa é estar a par com os desenvolvimentos mais
recentes no campo de projetos, o que leva a ter um trabalho de pesquisa mais
relevante e focalizado, balanceando integração e continuidade ao longo do projeto de
migração do ERP Protheus.
O gerenciamento de projetos é um empreendimento integrado, e requer que
cada processo de projeto ou produto seja alinhado e conectado de forma apropriada
com os outros processos para facilitar a coordenação. As ações adotadas durante um
processo em geral afetam esse e outros processos relacionados. (PROJECT
MANAGEMENT INSTITUTE, 2008, p. 39)
À medida que mais informações ou características do projeto são coletadas e
entendidas, pode ser necessário um planejamento adicional. Mudanças significativas
ocorridas ao longo do ciclo de vida do projeto acionam uma necessidade de revisitar
um ou mais dos processos de planejamento e possivelmente, alguns dos processos
de iniciação. Este detalhamento progressivo do plano de gerenciamento do projeto
com frequência é denominado “planejamento por ondas sucessivas”, indicando que o
planejamento e a documentação são processos iterativos e contínuos. (PROJECT
MANAGEMENT INSTITUTE, 2008, p.46)
17
5. PROJECT MANAGEMENT INSTITUTE (PMI)
O Project Management Institute conhecido como PMI, foi fundado na
Pensilvânia, por cinco voluntários no ano de 1969, que ao final da década de 70 já
contavam com mais de 2.000 associados pelo mundo (PMISP, 2013).
As publicações referentes ao órgão PMI eram conhecidas mundialmente e os
serviços e programas começaram a ser procurados com maior frequência,
necessitando assim, da criação de um código de Ética que regulamentava o instituto,
e o PMQ Special Report on Ethics Standards and Accreditation, um primeiro modelo
de padrão de gerenciamento de projetos (PMISP, 2013).
Nos anos 90, de acordo com o site do PMISP (2013), o número de associações
ultrapassava a marca de 8.500 e crescia cerca de 20% ao ano. Para atender a
crescente demanda, foi publicada então, inclusive através da internet a A Guide to the
Project Management Body of Knowledge (PMBOK) uma norma que engloba todas as
áreas de gerenciamento de projetos.
Com uma série de serviços, programas e certificações o PMI atualmente faz
parte de 185 países com mais de 500.000 associados em diversos setores industriais.
É reconhecida como a principal associação profissional em gerenciamento de projetos
e se preocupa com a prática, fazendo do PMBOK um guia profissional a ser seguido
mundialmente tendo em vista à padronização em gerenciamento de projetos (PMISP,
2013).
5.1 A Guide to the Project Management Body of Knowledge
(PMBOK)
De acordo com MAXIMIANO (2002) um projeto consiste em uma gama de
atividades com uma sequencia temporal programada, isto é, com começo, meio e fim,
cuja finalidade é atender um objetivo predeterminado. É um empreendimento bem
definido que consome recursos e opera sob pressão de prazos, custos e
qualidade (KERZNER, 2010).
18
O objetivo de um projeto é criar um produto, serviço ou resultado exclusivo de
uma demanda, sendo assim, cada projeto é singular, mesmo que contenham
características semelhantes e/ou elementos repetidos. Um projeto só é concluído
quando o objetivo for alcançado ou quando se constatar que não há possibilidades de
concluí-lo, ou mesmo quando não houver mais a necessidade do mesmo (PMBOK,
2008).
Kerzner (2010) ressalta que para atender as necessidades e a alta
competitividade do mercado de modo mais ágil e com o menor risco de fracasso, os
executivos perceberam a importância de gerenciar e estruturar os projetos de maneira
mais detalhada e eficaz, investido em formação e conhecimento e, garantindo assim,
melhores resultados para a empresa.
Partindo do pressuposto de que o processo de gerenciamento de projetos
consiste em governar etapas ao longo de seu ciclo de vida da melhor maneira possível
a partir de uma estrutura predeterminada, adequando ao contexto mais amplo do
programa ou da instituição patrocinadora, o Guia do Conhecimento em
Gerenciamento de Projetos PMBOK é um método de acompanhamento sistemático
visando à garantia de sucesso de um determinado projeto (PROJECT MANAGEMENT
INSTITUTE, 2008).
O PMBOK é uma norma reconhecida para a profissão de gerenciamento de
projetos, cujo principal objetivo é fornecer uma visão geral dos conhecimentos em
gerenciamento de projetos, com a aplicação correta das habilidades, ferramentas e
técnicas, controlando custos e prazos mantendo a competitividade e aumentando as
chances de sucesso (VALLE et al., 2007).
Para isso o PMI considera o PMBOK como uma metodologia de referência
básica de gerenciamento de projetos para seus programas de desenvolvimento
profissional e certificações (PROJECT MANAGEMENT INSTITUTE, 2008).
Para o guia PMBOK (2008) gerenciar um projeto é aplicar técnicas, habilidades,
conhecimentos e ferramentas necessárias com a finalidade de atender os requisitos,
passando por um total de 42 processos essencialmente alocados em cinco grupos:
iniciação, planejamento, execução, monitoramento e controle e encerramento.
19
De acordo com VARGAS (2005):
A Fase de definição consiste fase inicial do projeto, cujas características das
fases do projeto são moldadas de acordo com a definição da missão e do
objetivo.
A segunda Fase de planejamento requer o planejamento estratégico de
abordagem do projeto, detalhando tudo o que será realizado.
A Fase de execução é a materialização do que foi planejado. Geralmente
os erros ficam evidentes nesta etapa.
O controle acontece em paralelo à execução do projeto, tendo como
objetivo acompanhar e propor ações corretivas e preventivas no menor
tempo possível.
A Fase de finalização ocorre através da avaliação da execução dos
trabalhos por meio de auditoria interna ou externa.
Estas características são conhecidas como ciclo de vida do projeto, que
conforme aponta VARGAS (2005) dependem da natureza do projeto, partindo de uma
ideia até a execução. Vale ressaltar que cada fase define a natureza dos trabalhos
que deverão ser realizados e quais os principais envolvidos.
Há três tipos básicos de relações entre as diversas fases de um projeto. A
Relação Sequencial é aquela que uma fase começa somente quando a anterior estiver
totalmente concluída. Esta fase diminui as incertezas, porém pode eliminar as opções
de redução do cronograma, por exemplo. Já a Relação Sobreposta tem inicio antes
da fase anterior estar terminada, através de uma técnica chamada paralelismo. O
prazo pode ser reduzido com esta fase, porém, há maior probabilidade de retrabalhos,
se a fase anterior não for bem executada. A terceira relação é denominada de Relação
Interativa, na qual o planejamento da fase posterior é feito apenas na medida em que
os trabalhos da fase atual forem avançando. Durante todo ciclo de vida de um projeto
mais de uma relação entre as fases podem ser aplicadas (PROJECT MANAGEMENT
INSTITUTE, 2008).
Segundo MAXIMIANO (2002) recomenda-se seu uso por se tratar de uma
ferramenta completa para o gerenciamento de projeto. Embasado nos conceitos do
PMBOK (2008) para a qualidade do gerenciamento de projetos, existem nove áreas
20
de conhecimento para cada processo de gerenciamento um determinado projeto. São
elas:
ÁREA 1 – Gerenciamento de integração:
Na integração do projeto são inclusos os processos para identificação,
definição, combinação, unificação e coordenação das atividades dos grupos de
gerenciamento. No processo de integração, são inclusas características como, a
unificação, consolidação, articulação e ações integradoras, que são essenciais para o
término do projeto com sucesso, atendendo aos requisitos.
ÁREA 2 – Gerenciamento do escopo do projeto:
Nesta área, o gerenciamento do escopo inclui os passos necessários para
assegurar que o projeto possua todo o trabalho necessário para terminá-lo com
sucesso. O gerenciamento e as ferramentas variam de acordo com a área de
aplicação e normalmente são definidos como parte do ciclo de vida do projeto.
ÁREA 3 – Gerenciamento de tempo do projeto:
Esta etapa é fundamental para o término pontual do projeto, a partir de um
cronograma, que o guia PMBOK abrange também os dados e cálculos que produzem
o próprio cronograma, referindo-se ao mecanismo de agendamento preenchido com
os dados do projeto.
ÁREA 4 – Gerenciamento de custos do projeto:
Gerenciar custos envolve estimativas, orçamentos e controles de custos a fim de
que o projeto termine dentro do orçamento aprovado. Preocupa-se principalmente
com os custos dos recursos necessários para o projeto.
ÁREA 5 – Gerenciamento de qualidade do projeto:
A área de gerenciamento da qualidade abrange os processos e as atividades
da organização executora que determinam as políticas de qualidade, os objetivos e
as responsabilidades por meio de políticas de qualidade e procedimentos com
atividades de melhoria contínua de processos. O gerenciamento da qualidade se
21
aplica ao gerenciamento do projeto e ao produto, pois as medidas e técnicas de
qualidade específica do produto são resultantes do projeto.
ÁREA 6 – Gerenciamento de recursos humanos do projeto:
Gerenciar recursos humanos inclui os processos que organizam a equipe do
projeto. A equipe consiste nas pessoas com papéis e responsabilidades designadas
para a conclusão. É importante o envolvimento e a participação de todos os membros,
assim como a interação entre eles.
ÁREA 7 – Gerenciamento das comunicações do projeto:
Assegura que as informações sejam geradas, coletadas, distribuídas,
armazenadas, recuperadas e organizadas de maneira oportuna e apropriadas. A
comunicação pode ser interna (em todos os níveis da organização) ou externa à
organização. Deve ser eficaz e abranger diferentes níveis de conhecimento e diversas
perspectivas.
ÁREA 8 – Gerenciamento de riscos do projeto:
Fazem parte do Gerenciamento de riscos: planejamento, identificação, análise,
planejamento de respostas, monitoramento e controle de riscos. É uma tarefa
importante para o aumento da probabilidade de impactos positivos e para a redução
de impactos negativos no projeto. O risco do projeto é sempre futuro e incerto. A causa
pode estar associada a um requisito, uma premissa, uma restrição ou uma condição
que gerem futuros impactos, podendo ter uma ou mais causas. Devem ser
identificados e analisados, a fim de promover o planejamento de respostas, porém se
o risco já ocorreu pode ser considerado um problema.
ÁREA 9 – Gerenciamento de aquisições do projeto
Gerenciar aquisições significa incluir os processos necessários para compra de
novos produtos, serviços ou resultados externos à equipe do projeto. Devem
assegurar que todas as aquisições sejam necessárias para o desenvolvimento do
projeto e ao mesmo tempo sejam adequadas as politicas de aquisição da empresa.
22
Inclui-se no gerenciamento de aquisições contratos, compras, aspectos jurídicos e
disciplinas técnicas.
Utilizando-se destas nove áreas é possível criar e gerenciar um plano de projeto
de forma eficiente. Para gerenciar projetos, é necessária uma equipe integrada e do
exercício de diferentes funções visando à garantia de bom desempenho e qualidade
essenciais para os projetos. Segundo VALLE et al. (2007, p. 26) “a tarefa central do
gerenciamento de projetos sempre foi a combinação do trabalho de diferentes
pessoas para a execução de tarefas que seriam úteis para os clientes ou as
organizações”.
Para isso é necessário um gerente de projeto, que é a pessoa designada para
seguir os passos norteadores no desenvolvimento e cumprimento do projeto a fim de
atingir o objetivo inicialmente proposto (PMBOK, 2008).
De acordo com o PROJECT MANAGEMENT INSTITUTE (2008) o gerente e
sua equipe devem abordar e controlar cada processo com cuidado, este esforço é
conhecido como adequação. Para atingir todos os passos contidos no PMBOK, deve
haver um processo alinhado e conectado com outros processos de forma a facilitar a
coordenação. Gerenciar um projeto de forma bem sucedida requer gerenciar
ativamente estas interações para que se cumpra o esperado pelo patrocinador, pelo
cliente ou por outras partes interessadas.
Segundo o manual do PMI, os projetos não podem operar com um sistema
fechado. Para isso, são munidos de processos de gerenciamento, nos quais são
agrupados em cinco categorias conhecidas como grupos de processos, que são
distintos das fases do processo. O primeiro grupo consiste no grupo de processos de
iniciação, ou seja, define o novo projeto ou uma nova fase de um projeto existente. O
segundo é o grupo de processos de planejamento, ferramenta que opera para definir
o escopo, refinar os objetivos e desenvolver o curso de ação. O próximo grupo é o
grupo de execução, que consiste na execução do trabalho propriamente dita. O grupo
de monitoramento e controle acompanha, revisa e regula o processo e desempenho,
identificando se há a necessidade de mudanças. E, por fim, o grupo de processo de
encerramento finaliza as atividades de todos os outros grupos de processos. Estes
processos podem gerar informações que aprimoram o gerenciamento de projetos
23
futuros. São apresentados como elementos distintos, porém na prática eles se
sobrepõem e interagem entre si (PROJECT MANAGEMENT INSTITUTE, 2008).
As vantagens de gerenciar um projeto com qualidade podem ser inúmeras,
acarretando em resultados positivos respeitando qualidade, orçamentos de custos e
prazos. Conforme apontado por VARGAS (2005) o principal benefício do
gerenciamento de projetos é que este não se aplica somente aos projetos grandes,
podendo ser aplicados em empreendimentos de qualquer complexidade e em
qualquer área de negócios e sendo extremamente eficaz.
Contudo, o mesmo autor afirma que existem muitos fracassos decorrentes de
obstáculos naturais/externos e que não estão ao controle da organização. Podem ser
evitados ou minimizados a partir de um bom gerenciamento de riscos, porém muitos
fracassos também ocorrem das falhas gerenciais. O projeto pode ser cancelado por
diversos motivos, entre eles, fatores naturais, má liderança e gerenciamento, falta de
verbas, mau aproveitamento de tempo, não cumprimento de cronograma, entre
outros, causando um impacto negativo em diversas instâncias da empresa VARGAS
(2005).
5.2 Project Management Professional (PMP)
De acordo com o PMISP (2013) desde 1984 há a dedicação contínua no
desenvolvimento e manutenção de um rigoroso programa de Certificação, conhecido
como Project Management Professional (PMP).
O Project Management Professional é a certificação gerada pelo PMI aos
profissionais que cumprem todos os requisitos para a certificação, sendo a primeira
certificação a ser reconhecida pela International Organization for
Standardization (ISO) 9001. É um rigoroso programa mantido pelo PMI com o intuito
de garantir o avanço profissional em gerenciamento de projetos e reconhecimento
individuais para os portadores desta certificação (PMISP, 2013).
Para obter a Certificação PMP, o profissional deve comprovar experiência em
duas categorias passar no Exame de Certificação PMP e aderir ao Código de Conduta
24
Profissional (Code of Professional Conduct). O portador desta certificação tem um
grande prestigio no grupo de profissionais na comunidade de gerenciamento de
projetos e passa a seguir guia PMBOK para conhecimento e aperfeiçoamento na
profissão (PMISP, 2013).
Atualmente, diversas organizações estão interessadas em profissionais com a
Certificação PMP, focando o padrão de qualidade dos serviços oferecidos por este
tipo de profissional.
5.3 Plano de projeto
O planejamento de projeto é um processo continuo que não acaba com o inicio
da execução. É engano pensar que basta estabelecer um PGP (Plano de
Gerenciamento de Projeto) e implementá-lo. O plano precisa ser mantido atualizado
para refletir a execução do projeto e as mudanças autorizadas, pois até mesmo as
orientações básicas e os objetivos, que normalmente são validos por um tempo mais
longo, podem mudar durante o projeto. É muito importante que haja acordo entre os
envolvidos no projeto para que o PGP seja modificado. E, quando não se consegue
este acordo, é sempre melhor aceitar a situação e abandonar uma determinada
abordagem para um projeto, que implementá-la contra os fortes interesses das
principais partes interessadas. Não se deve acreditar que “tudo é possível”, pois o
planejamento implica em custos que precisam ser justificados pelos benefícios obtidos
da adaptação do PGP. (VIVACQUA; MACEDO; XAVIER, 2009, p. 31).
É importante ressaltar que a metodologia utilizada para gerenciamento de
projetos utilizada faz uso de tarefas definidas, ou seja, todo o processo de
gerenciamento é dividido em áreas menores. A primeira área do gerenciamento é o
Gerenciamento de escopo do projeto.
5.4 Escopo do Projeto
Segundo Vicacqua, Macedo e Xavier (2009, p. 138) o processo de aceitação
de escopo tem como objetivo obter o aceite formal do escopo do projeto pelas partes
envolvidas (steakholders). Isto exige uma revisão dos produtos e resultados dos
trabalhos para garantir que tudo foi completado correto e satisfatoriamente, com
25
correspondente aceite do cliente. Desta forma esse processo depende da aprovação,
pelo controle de qualidade, dos produtos e serviços gerados. A gestão do escopo é
representada pelos processos necessários para assegurar que o projeto comtemple
todo trabalho, e apenas o trabalho necessário para que a missão do projeto seja
atingida. Os processos são a iniciação, o planejamento do escopo, o detalhamento do
escopo, a verificação do escopo e o controle de mudanças do escopo. Deve ficar clara
a diferença entre o escopo do produto e escopo do projeto. O escopo do produto
determina as funções e características do serviço ou produto a ser produzido pelo
projeto. Já o escopo do projeto determina e quantifica o trabalho a ser executado para
gerarmos o produto ou serviço do projeto tal como delimitado no seu escopo.
(HABERKORN, 2003, p. 197)
5.5 Gestão de tempo
A gestão de tempo é representada pelos processos que efetivarão o
cumprimento dos prazos envolvidos. São eles a definição de atividades, o
sequenciamento das atividades, a estimativa da duração das atividades, o
desenvolvimento do cronograma e o controle do cronograma. A variação do tempo de
execução das tarefas ou entrega dos produtos ou subprodutos em um projeto é um
dos fatores de maior impacto nos custos e qualidade, assim como nas outras gestões.
É também inúmeras vezes causa de conflitos e renegociações. A gestão do tempo
pode ser definida como a perfeita sincronia de entrega dos produtos de fornecedores
internos para clientes internos do projeto. Portanto, a sincronia nos prazos de entrega
e recebimento é fundamental e crítica, e o sequenciamento das atividades, peça sem
a qual o quebra-cabeça do projeto não se completará. (HABERKORN, 2003, p. 199)
Os processos de gerenciamento do tempo do projeto e suas ferramentas e
técnicas associadas são documentados no plano de gerenciamento do cronograma.
O mesmo é contido no plano de gerenciamento do projeto ou é um plano auxiliar,
podendo ser formal ou informal, altamente detalhado ou generalizado, baseado nas
necessidades do projeto e deve incluir os limites de controle apropriados. (PROJECT
MANAGEMENT INSTITUTE, 2008, p. 113).
26
5.6 Gestão de riscos
A gestão de riscos é representada pelos processos que identificam e analisam
riscos, e criam um plano de resposta adequado a ocorrência de qualquer risco
previamente identificado. São eles a identificação dos riscos, a quantificação dos
riscos, o desenvolvimento das respostas aos riscos e o controle das respostas aos
riscos. O gerenciamento dos riscos consiste em mapear, analisar e avaliar riscos nas
tarefas do projeto que comprometam o sucesso do mesmo. Quando pensamos em
riscos, dois itens merecem destaque: a probabilidade da sua ocorrência e o reflexo
sobre o projeto em algum dos seus indicadores (tempo e custo, por exemplo) em
termos de prejuízos e benefícios. (HABERKORN, 2003, p. 211)
27
6. ELABORAÇÃO DO PLANO DE PROJETO
O planejamento de projetos requer conhecimentos, habilidades, ferramentas e
técnicas que possibilitem alcançar ou exceder as necessidades e as expectativas dos
seus empreendedores. A necessidade de planejamento é algo que a maioria dos
profissionais do mercado entendem do que se trata, no entanto, são poucos aqueles
que realmente planejam ou executam seus planos e atividades, ou seja, os que
organizam seus passos utilizando metodologia, pesquisa e bom senso no
planejamento. A metodologia de planejamento de projetos utilizada possui áreas de
conhecimento muito bem definidas.
Uma área de conhecimento é definida por seus requisitos de conhecimentos e
descrita em termos dos processos que a compõem, suas práticas, entradas, saídas,
ferramentas e técnicas. Existem nove áreas de conhecimento, são elas: Integração,
Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicações, Riscos e
Aquisições.
6.1 Escopo do projeto
Qualquer modificação que seja feita no sistema de uma empresa com uma
quantidade considerável de dados sem qualquer tipo de planejamento pode se tornar
muito arriscada, pois qualquer falha não prevista por uma equipe de planejamento
especializada pode causar grandes prejuízos às empresas que necessitam fazer a
migração de versão do Protheus. O objetivo deste projeto é evitar que quaisquer falhas
causem tal fracasso da migração.
Para que o projeto seja concluído com êxito, será necessário que alguns
requisitos sejam preenchidos a fim de atingir uma maior economia de recursos e
minimização de eventuais problemas que venham a ser causados por má
administração de recursos como gerenciamento de riscos e tempo. Todo o
planejamento tem como principal premissa cumprir com as expectativas do cliente
com uma chance muito maior de sucesso.
O projeto é um modelo standard para todos que tiverem a necessidade de
efetuar a migração de versão do Protheus, atendendo assim ao maior campo de
28
clientes possível. Após concluída esta etapa é iniciada a etapa de gerenciamento de
tempo do projeto.
6.2 Gerenciamento do Tempo
O Guia PMBOK determina o gerenciamento de tempo com uma área de
conhecimento específica, com processos que definem as atividades e criam um
cronograma para ser seguido e controlado. Não é possível estimar o tempo necessário
para a migração em um plano default, mas é possível definir quais os processos que
deverão ser concluídos, criando um cronograma de acordo com cada caso. O
cronograma macro tem como finalidade que todos os envolvidos no projeto saibam
quando cada etapa deverá ser iniciada e posteriormente concluída, de forma que as
atividades possam ser distribuídas de maneira adequada. O cronograma pode ser
elaborado em semanas, assim torna-se possível que todas as áreas fiquem cientes
de alguma pessoa necessária que esteja indisponível por qualquer motivo que impeça
sua dedicação ao projeto. O cronograma macro deverá também definir a data da
atualização da versão no ambiente oficial, ou seja, quando a empresa deixará de
utilizar o Protheus versão atual e passará a utilizar o Protheus na nova versão.
O cronograma macro deverá prever as seguintes fases:
Atualização de versão em ambiente de homologação:
Nesta fase a equipe técnica será responsável por converter o ambiente
do Protheus para a nova versão. Essa operação leva em torno de dois a três
dias para ser concluída, dependendo do tamanho da base de dados do cliente.
Período de homologação dos usuários:
Em cada setor da empresa ou modulo do sistema são definidos um ou
dois usuários para realizarem a validação das rotinas, esses usuários são
chamados de usuários-chave. Os usuários-chave terão acesso ao sistema de
homologação a fim de verificar se todas as rotinas utilizadas no Protheus
versão atual se comportam de forma esperada ao serem utilizadas no Protheus
na nova versão e documentarem quais rotinas foram validadas e qual o
resultado da validação, se a rotina se apresentou da forma esperada ou se a
29
rotina retornou algum erro, por exemplo. Caso a rotina tenha apresentado erro,
este é passado ao técnico que atua para solucionar o mesmo e retorna ao
usuário para que o ele possa validar novamente a rotina.
O tempo estimado para que os testes garantam que os problemas nas
rotinas possam ser resolvidos deverá ser de no mínimo três semanas, porém o
prazo não poderá ser muito extenso para não prejudicar as datas previstas pelo
cronograma.
Com todos os testes realizados pelos usuários e problemas
solucionados pelos técnicos já resolvidos, o sistema esta pronto para ser feita
a atualização em modo produção.
Atualização de versão em ambiente produção:
A atualização no ambiente produção deve ser cautelosa, a fim de evitar
que ela seja feita em períodos críticos como de fechamentos mensais ou
próximos à data de entregas de obrigações fiscais, por exemplo.
Por experiência em outras atualizações de versões já ocorridas
anteriormente e a atualização que foi feita em base homologação apenas um
final de semana é suficiente para fazer a migração em produção, porém pode
se estender de acordo com o tamanho da base de dados do cliente, então o
adequado seria planejar a utilização de recessos prolongados para migrar o
ambiente.
A primeira tarefa necessária para iniciar o planejamento é a definição e
sequenciamento das atividades.
6.2.1. Definição e Sequenciamento das atividades
O processo de migração de versão do Protheus é cirúrgico e exige muita
atenção em todos os passos envolvidos. Qualquer informação que seja perdida ou
danificada na atualização pode ter consequências ruins para o funcionamento da
empresa.
30
Antes de relatar como é o processo da migração do Protheus, é importante ter
em mente como é formada a estrutura de diretórios que compõe o corpo do sistema.
O diretório base da instalação padrão é chamado \TOTVS\Microsiga, sendo
definidos na instalação os subdiretórios, de acordo com a Tabela 1.
Tabela 1 – Subdiretórios x Descrição.
Subdiretório Descrição
\PROTHEUS_DATA Raiz do sistema
\APO Repositório de objetos (RPO)
\BIN\SMARTCLIENT Executáveis, bibliotecas e arquivos de
configuração (.INI) do sistema.
\BIN\SMARTCLIENT_ACTIVEX Destinado aos arquivos para acesso
via Web por meio do recurso
ACTIVEX.
\BIN\APPSERVER Executáveis, bibliotecas e arquivos de
configuração (.INI) do sistema.
\BIN\APPSERVER\ACE_9.99 Arquivos de configuração e bibliotecas
para acesso aos arquivos SX’s.
\BIN\TOOLS Onde são encontradas as ferramentas
para manutenção do sistema,
\CPROVA Destinado para gravação dos
lançamentos analíticos do ambiente
contábil.
\CRYSTAL Contem arquivos de bibliotecas e
relatórios modelos do Crystal Report.
\DATA Contém o Banco de Dados do
Protheus (Codebase, CTREE ou ADS)
\HANDHELD Arquivos da biblioteca para integração
com Palm-OS e Pocket PC.
31
\INCLUDE Contem as bibliotecas (.CH)
necessárias a execução e compilação
do AP7.
\MY PROJECT\SAMPLES\SOURCE Fontes cara exemplos de funções
ADVPL.
\SAMPLES\DOCUMENTS Arquivos modelos para integração com
o pacote Microsoft Office.
\SYSTEMLOAD Arquivos de carga do Dicionário de
Dados, Help’s do Protheus e
indicadores Nativos, usados somente
na instalação/migração do Protheus.
\SPOOL Destinado para gravação de relatórios
gerados em disco.
\SEMAFORO Arquivos de semaforização de
registros.
\SYSTEM Contém os arquivos de Customização,
Empresa, Usuários, Fiscais,
impressão e menus do sistema.
\SISCOMEX Contem os arquivos específicos para
uso dos ambientes de importação e
exportação.
\PROFILE Armazena o perfil de cada usuário.
Antes da migração são exigidos alguns requisitos e o ambiente deve ser
previamente preparado.
6.2.2. Preparação do ambiente a ser migrado
Antes de iniciar o processo de atualização devem ser levados em conta alguns
fatores importantes para a migração:
32
O espaço em disco livre deve ser de aproximadamente três vezes o tamanho
atual da pasta “System” somado ao tamanho do banco de dados. Ou seja, se a
database em questão estiver com 4,5 GB, e a pasta “System” estiver com 500MB,
então, o seu espaço em disco livre deverá ser de aproximadamente 15 GB. Isso se
faz necessário, pois o Protheus efetua backups de cada tabela no momento da
conversão delas.
Deve-se efetuar o backup do diretório \PROTHEUS_DATA e do Banco de Dados
e checar a duplicidade de registros:
I. Efetuar o download do portal o arquivo SX2.UNQ e colocá-lo na
\Systemload do ambiente a ser convertido.
II. Executar a rotina CHECKDUPL. A rotina CheckDupl verifica se
existem registros duplicados nas tabelas do sistema, removendo as
duplicidades e mantendo a integridade das tabelas no banco de
dados.
III. Ajustar os registros duplicados (caso exista)
Com a garantia de um backup da estrutura do Protheus devemos apagar todos
os arquivos de índices do diretório \PROTHEUS_DATA:
I. Efetuar uma busca pela extensão dos arquivos de índices: *.CDX ou *.IDX.
II. Em casos de base CTREE, são criadas pastas com o nome e extensão *.IDX,
exemplo: sc62990a.idx. As pastas deverão ser excluídas.
III. Apagar o conteúdo das pastas “ctreeint”. Normalmente são duas pastas, sendo
uma no PROTHEUS_DATA e a outra na SYSTEM.
IV. Apagar o índice do Arquivo de Empresas (arquivo SIGAMAT.IND). Apagar
todos os arquivos Temporários, Logs e de Backup’s:
V. Deve ser feita uma busca pela extensão *.LOG, *.TMP e *.DBF e apagar os
arquivos.
Após a preparação deste ambiente, a instalação da nova versão do software já
pode ser iniciada.
6.2.3. Instalação da nova versão
33
Com o instalador, Figura 1, da TOTVS deve-se realizar a instalação das
seguintes aplicações:
TOTVS Application Server;
TOTVS Smart Client;
TOTVS DBAccess.
Figura 1 – Tela de Instalação Protheus
6.2.4. Atualização da nova versão
O primeiro passo da atualização é efetuar o download dos pacotes mais recentes
no portal da Totvs:
RPO – Categoria: Repositório de Objetos;
BUILD – Categoria: Binário TOTVSTec;
UPDATE – Categoria: Update de Programas;
PATCH/LIB DE PROGRAMAS – Categoria: Path de Programas;
HELP – Categoria: Help de Campo/Pergunta;
MENUS – Categoria: Menu de módulo.
BRA.ZIP – Categoria: Dicionário de dados.
34
Com os arquivos disponíveis e prontos para serem utilizados devem ser
seguidos os passos para a realização da atualização:
RPO – Repositório de Objetos
Arquivos binários compilados, os quais contêm instruções de funcionamento,
como funções e aplicações de todos os módulos do ERP.
O arquivo baixado do portal deve substituir o que está presente no diretório
padrão de instalação: \TOTVS\Microsiga \Protheus11\apo.
O arquivo de deve ser renomeado de “13-07-05-bra-chi-eua-par-uru-tttp110.rpo”
para “tttp110.rpo”.
Build
Versão completa do sistema com seus executáveis, Dll’s e RPO completo. O
Build do sistema pode ser identificado através das seguintes opções “Ajuda” + “Sobre”,
dentro de qualquer módulo do sistema.
Ao descompactar o arquivo baixado existem três pastas que devem ser
substituídas, todos os seus arquivos em seus respectivos diretórios.
Appserver
Copiar todo o conteúdo de dentro da pasta e substituir no diretório
\TOTVS\Microsiga \Protheus11\bin\appserver. Dentro do diretório “appserver” existe
uma pasta chamada “ace_8.00”, todo o conteúdo dessa pasta deve ser
descompactado no diretório bin\appserver.
Smartclient
Copiar todo o conteúdo da pasta e substituí-lo no diretório \TOTVS\Microsiga
\Protheus11\bin\smartclient.
SmartclientActiveX
Copiar todo o conteúdo da pasta e substituí-lo no no diretório \TOTVS\Microsiga
\Protheus11\bin\smartclientActivex.
Update
35
Este arquivo contém todos os programas contidos no RPO que sofreram
alterações por motivos de atualização de rotinas, correções de problemas, etc.
Esse arquivo de extensão .upd deve ser aplicado no DevStudio e suas
alterações gravadas no RPO.
LIB de Programas
Arquivo que contem a biblioteca de funções dos programas. Esse arquivo deve
ser aplicado no DevStudio e suas alterações são gravadas no RPO.
Patch de Programas
Arquivo específico para cada rotina ou função que tem o intuito de corrigir
problemas pontuais ou atualizar rotinas especificas. Esse arquivo deve ser aplicado
no DevStudio e suas alterações são gravadas no RPO.
Help
Arquivo que contém os ajudas (helps) de campo e perguntas do sistema. Esse
arquivo deve ser descompactado na pasta \systemload\ substituindo os arquivos nela
existentes.
Menus
Contempla os arquivos de extensão .xnu. Esses arquivos são os menus de cada
modulo que devem ser substituídos na pasta \system\.
BRA.ZIP
Contém o arquivo SXBRA.TXT, que é o dicionário de dados padrão do Protheus.
O arquivo deve ser descompactado na pasta \systemload\ substituindo os arquivos
nela existentes.
6.2.5. Preparando o Ambiente a ser migrado
Para preparar o ambiente é necessário checar a duplicidade de registros na base de
dados. O responsável deverá efetuar o download do arquivo SX2.UNQ no portal da
Totvs e colocá-lo na pasta systemload do ambiente a ser convertido. Em seguida
deve-se executar a rotina “CheckDupl”. Essa rotina tem como objetivo localizar e
36
corrigir eventuais ocorrências de duplicidades na base de dados, de forma a manter e
viabilizar a utilização da integridade referencial. A rotina de migração de versão não
finaliza caso tenha registros duplicados, portanto e de extrema importância à
execução dessa rotina.
É necessário certificar-se de utilizar o arquivo SX2.UNQ mais recente, disponível
no Portal. Em casos de execução com o objetivo de migração de versão, utilize o
arquivo SX2.UNQ relativo à versão superior, para que seja adotada como parâmetro
as chaves únicas relativas às tabelas da versão a ser migrada.
Antes de executar a rotina de migração deve ser efetuados os seguintes passos:
Copiar o conteúdo do diretório SYSTEM (SIGAADV) e DATA (DADOSADV) do
sistema Protheus (Versão atual) para seus respectivos diretórios do sistema
Protheus (Nova versão);
Copiar o conteúdo da pasta PROFILE do sistema Protheus (Versão atual) para
sua respectiva pasta do sistema Protheus (Nova versão);
Verificar se o espaço disponível no servidor que hospeda a base de dados do
sistema Protheus (Nova versão) é 3x superior o tamanho da base de dados do
sistema Protheus (Versão atual).
Excluir os arquivos *.DBF/*.CDT da pasta SYSTEMLOAD;
Excluir os arquivos *.IDX da pasta SYSTEMLOAD;
Excluir os arquivos *.TSK da pasta APPSERVER do sistema;
Excluir os arquivos *.LOG e *.SPS da pasta SYSTEM.
Ao final da preparação do ambiente o responsável deverá executar o atualizador
de versão.
6.2.6. Executando o atualizador de versão (MP710TO110)
É necessário acessar o SmartCient da nova versão e no “Programa Inicial”,
digitar “MP710TO110” e clicar no botão “OK” para confirmar, conforme Figura 2.
37
Figura 2 – Parâmetro Inicialização do Sistema
Será apresentada uma janela com as orientações sobre o processo de atualização
(Figura 3):
Figura 3 – Introdução ao Migrador de versão
Ao clicar em “Avançar” será apresentada uma janela onde será informada a senha
do usuário Administrador do sistema (Figura 4). Somente o usuário administrador
possuirá permissão para executar essa função.
38
A opção “Simulação” deve estar selecionada para que seja feita uma simulação da
atualização e assim os erros que necessitam de correção sejam exibidos. Somente
após a correção destes erros a função de atualização poderá ser executada
novamente, só que desta vez sem selecionar a opção de simulação para que seja
feita em modo definitivo.
Figura 4 – Tela de login para inicialização do migrador
Ao informar a senha é apresenta uma nova janela onde deverá ser escolhida a
versão para qual será atualizado o sistema Protheus (Figura 5).
39
Figura 5 – Escolha da versão para qual será atualizado o sistema.
Com a versão selecionada, é apresentada uma nova janela informando em qual
diretório serão criadas as novas tabelas da nova versão e quais empresas
cadastradas no sistema sofrerão a atualização (Figura 6).
Figura 6 – Escolha do diretório raiz do sistema.
40
Ao clicar em “Avançar” será apresenta uma nova janela com as configurações
desejadas para a atualização (Figura 7). Com o processo sendo executado em modo
simulação, as opções devem ser marcadas conforme mostrado abaixo.
Figura 7 – Configuração do processo de atualização.
Ao clicar em avançar, serão exibidas as empresas que serão convertidas e as
tarefas que serão executadas para realizar a atualização:
Empresas envolvidas:
- 99/01 - TESTE/MATRIZ
Lista de Tarefas:
- Verificar integridade
- Atualização do SINDEX
- Atualização do SX1
- Atualização do SX2
- Atualização do SX3
- Atualização do SX4
- Atualização do SX5
- Atualização do SX6
41
- Atualização do SX7
- Atualização do SX9
- Atualização do SXA
- Atualização do SXB
- Atualização do SXD
- Atualização do SXG
- Atualização do SXQ
- Atualização do SXR
- Atualização do SXS
- Atualização do SXK
- Atualização das tabelas
- Atualização do Help de programa
- Atualização do Help de soluções
- Funções de compatibilização
- Finalizando atualização
Figura 8 – Empresas e tarefas que serão executadas no migrador.
42
Ao clicar em “Avançar”, conforme Figura 8, a conversão terá inicio.
O processo que a função migrador faz para migrar a versão do sistema varia de
acordo com o tamanho da base de dados do cliente. Em uma base de dados de
aproximadamente 10GB o migrador leva em torno de 2 a 3 horas para finalizar todo o
processo.
O gerenciamento de tempo é uma parte de grande importância para o projeto,
mas é dependente das demais etapas, nas quais o gerenciamento de recursos
humanos está incluso.
6.3 Gerenciamento de recursos humanos do projeto
Durante o projeto de atualização de versão do ERP Protheus são alocados
técnicos de diferentes áreas de atuação. A alocação desses técnicos pode variar de
acordo os módulos utilizados pela empresa no sistema. Por exemplo, se a empresa
utiliza algum modulo especifico como “Planejamento e Controle Orçamentário”, é
necessário alocar um técnico com conhecimentos no módulo para que ele auxilie na
validação após a migração no ambiente homologação. Os únicos técnicos fixos no
projeto, ou seja, aqueles que iniciam e terminam o projeto, são os que de fato fazem
o processo de atualização.
As alocações dos técnicos são feitas de acordo com o surgimento das
necessidades do projeto e podem variar conforme a estrutura do cliente. Se a
atualização do ERP for feita em uma empresa que não possui estrutura de T.I. são
alocados técnicos com conhecimento geral para que façam a validação das rotinas,
por exemplo.
Finalizados os procedimentos de gerenciamento de recursos humanos, deve-se
dar início ao gerenciamento de custos, que é uma área muito importante para
quantificar valores gastos no projeto.
6.4 Gerenciamento de custos do projeto
Segundo Vargas (2005) o custo é a quantidade de capital necessária para se
realizar uma atividade ou um projeto. O custo de uma atividade é calculado com a
43
soma dos custos de todos os recursos que envolvem essa atividade com os custos
que interferentes indiretamente nessas atividades (custo de supervisão).
O gerenciamento de custos do projeto consiste em controlar os custos de modo
que o mesmo não ultrapasse a estimativa definida na elaboração orçamento do
projeto. O gerenciamento do custo exige uma constante interação entre os processos
do projeto e preocupa-se principalmente com o custo dos recursos necessários para
completar as atividades do projeto. (PMBOK)
Uma variável que afeta também de forma direta os custos do projeto é o
gerenciamento de qualidade.
6.5 Gerenciamento de qualidade do projeto
Segundo o PMBOK (2008) O planejamento da qualidade deve ser realizado em
paralelo com os outros processos de planejamento do projeto, levando em conta que
modificações propostas para que os padrões de qualidade sejam atendidos podem
causar reajustes nas demais áreas do projeto, causando impactos positivos ou
negativos na finalização do mesmo. Garantir a qualidade é um procedimento de
auditoria de todos os requisitos de qualidade aplicados aos resultados encontrados
anteriormente a fim de garantir que os padrões de qualidade e suas definições de
operação sejam sempre adequados.
A garantia da qualidade deve ser fornecida a todos os envolvidos no plano de
projeto, ou seja, a equipe do projeto, a gerência, o cliente e quaisquer outras partes,
a fim de que o trabalho seja concluído. Segundo o PMI, gerenciar o projeto requer que
todos os processos sejam alinhados de maneira correta a fim de facilitar a
coordenação do mesmo. Mudanças significativas que ocorram ao longo do projeto
podem acionar a necessidade de possível revisão dos processos anteriores,
influenciando nos custos do projeto ou descumprimentos de metas, por esse motivo
as métricas de desempenho de trabalho devem ser bem definidas para que se
obtenham dados reais de custos e prazos a serem comparados com o que foi
previamente planejado.
Para a migração do sistema de acordo com o PMBOK (2008), a qualidade é
indispensável por estar diretamente envolvida com todas as demais áreas do projeto
com a finalidade de economizar em retrabalhos. O custo da qualidade envolve todos
44
os custos utilizados para prevenção de riscos ou descumprimentos dos requisitos
necessários para que o processo não fracasse. Por exemplo, para que os dados do
cliente não sejam comprometidos em uma migração é necessário garantir que ela seja
feita anteriormente em um ambiente de homologação com uma cópia da base do
cliente.
Este ambiente de homologação deverá ser auditado pela qualidade para
assegurar que os dados duplicados sejam eliminados e que nenhuma tabela tenha
sido comprometida com nomes de colunas ou tipos de dados inconsistentes. O custo
do processo já havia sido previsto de acordo com a instrução de trabalho, mas caso
esse ambiente de homologação não seja implementado por qualquer que seja o
motivo e ocorrerem falhas, é gerada uma não conformidade, o que consequentemente
causará problemas ao projeto. Os custos das falhas são em sua maioria reflexo do
mau gerenciamento da qualidade.
A fim de evitar estas falhas, se torna extremamente necessário que seja feito
um estudo dos riscos do projeto.
6.6 Gerenciamento de riscos do projeto
O Guia PMBOK define em uma área de conhecimentos específica o
gerenciamento dos riscos no projeto. Os riscos são mapeados através da identificação
dos mesmos. Os impactos no projeto são avaliados para determinar a prioridade de
cada um, as medidas a serem tomadas para cada risco são determinadas, sempre
monitorando os riscos. A cada novo risco identificado ao longo do projeto é tratado da
mesma forma.
Com a finalidade de gerenciar os riscos, deverão ser feitas reuniões periódicas
para a identificação e eventuais soluções destes riscos. Todos os envolvidos deverão
apresentar sugestões de riscos positivos e negativos que possam afetar o projeto em
seu andamento, atentando para particularidades de cada cliente. Em reuniões
posteriores os responsáveis pelo projeto deverão avaliar o gerenciamento e as
devidas alterações que foram feitas no projeto para que, de acordo com as mudanças
já propostas se tenha base se foram impostas melhorias ou foram causados novos
problemas com as decisões.
45
6.6.1. Definição dos riscos
Durante o processo de migração de versão do ERP Protheus existem diferentes
situações que podem ser consideradas de risco para o andamento e qualidade do
projeto.
Quando é realizada uma previa da migração em base de homologação são
levantados todos os possíveis erros que podem ocorrer em rotinas do sistema. Com
esses erros já mapeados, eles são utilizados para serem corrigidos posteriormente
após a migração em ambiente produção. Caso exista alguma rotina após a migração
não validada ou que apresentou problema e não foi corrigida, isso influenciará
diretamente na qualidade e sucessivamente no tempo de entrega do projeto. Esses
pontos são considerados riscos que podem influenciar diretamente no projeto.
6.6.2. Identificação os riscos
Identificar os riscos é detectar as áreas potenciais de risco, sendo que através
da eficácia desta identificação resultará a eficiência do gerenciamento de risco.
Segundo o PMBOK (2008), a fase de identificação de risco compreende a
determinação de quais riscos podem afetar o projeto e em documentar as suas
características.
No processo de validação das rotinas em base de homologação, são
identificados os riscos que podem influenciar diretamente o projeto. É necessária uma
atenção na validação desses processos, pois nele são identificados os riscos que
deverão ser tratados para que se chegue a uma solução e deixem de ser um risco ao
final do projeto.
46
7. CONCLUSÃO
Com o presente trabalho de conclusão de curso no qual foi abordado um projeto
e migração de versão do ERP Protheus baseados nos conceitos do PMBOK, podemos
concluir que com um planejamento, estruturação e boa execução do projeto podem-
se obter excelentes resultados ao final do trabalho. Este trabalho nos auxiliou a
entender ainda mais a importância de se planejar a execução de um projeto para obter
os resultados esperados ao final de sua conclusão, além de ter-nos permitido
desenvolver e aperfeiçoar competências de gerencia e execução de um projeto de
pequeno e médio porte.
47
8. REFERÊNCIAS BIBLIOGRÁFICAS
HABERKORN, Ernesto Mário. Gestão Empresarial com ERP. São Paulo: Microsiga, 2003.
HABERKORN, Ernesto Mário. Um Bate Papo sobre O Gestão Empresarial com ERP. São Paulo: Saraiva, 2007.
VIVACQUA, Flavio Ribeiro; MACEDO, Otualp Sarmento; XAVIER, Luiz Fernando da Silva; XAVIER, Carlos Magno da Silva. Metodologia de Gerenciamento de Projetos. 2 ed. Brasport, 2009.
Como fazer a migração para Protheus 11.5? Disponível em: < http://tdn.totvs.com/x/_QR3Ag >. Acesso em 24 de abr. de 2013.
PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Gerenciamento de Projetos. 4.ed. Pennsylvania: PMI, 2008.
KERZNER, Harold. Gestão de projetos: as melhores práticas. Porto Alegre: Bookman, 2010.
MAXIMIANO, Antonio César Amaru. Administração de projetos. São Paulo: Atlas, 2002.
PMBOK. Conjunto de Conhecimentos em Gerenciamento de Projetos. [Manual]. Global Standard. Campus Boulevnad: Newtown Square, 2008.
PROJECT MANAGEMENT INSTITUTE SÃO PAULO. Disponível em: < http://www.pmisp.org.br/>. Acesso em 17 de out. de 2013.
VALLE, André Bittencourt Do; SOARES, Carlos Alberto Pereira; MOREIRA, Itamar; FINOCCHIO JR., José; SILVA, Lincoln de Souza Firmino; VERGARA, Silvia Constant. Fundamentos do gerenciamento de projetos. Rio de Janeiro: FGV, 2007.
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos. Rio de Janeiro: Brasport, 2005.
