Porque os Projetos SAP Falham.  Parte II

Pessoal vamos para parte II aonde teremos um guia comentado sobre aquilo que tira o sono de todos os envolvidos em um projeto SAP, porque os projetos falham, atrasam, não se concluem.

Segue um guia rápido de alguns processos básicos com base no ASAP da SAP comentando que no meu entender e um importante exemplo prático do que temos que seguir para diminuir o risco nos projetos desta maneira iremos evitar ou diminuir a recorrência de erros no gerenciamento de seus projetos e evitar que eles falhem. Saía da cadeira, vá a campo, se envolva no projeto, espero que ajude.

Fase 1- Planejamento:


  • Falha no planejamento do projeto: essa talvez seja a fase mais crítica  e importante de um projeto e o momento que temos que ter calma, efetuar todos os questionamentos sobre o projeto e nossa equipe, deixar claro o data inicial e final junto com o escopo fechado do projeto, temos que construir e entender o timeline do projeto.

Os Gerentes de projeto  não podem ter preguiça de escrever, efetuar bons controles, detalhamento no cronograma, timeline.



Fase 2 –  Business Blueprint –  BBP


  • Processos críticos do negócio em definição e ainda não definidos: quase uma consequência do mau planejamento. Não podemos definir durante o projeto, caso isso aconteça, a empresa terá de fazer mudanças no sistema depois de estar pronto ou até mesmo não utilizar o que foi implementado.


  • Falha em detalhar os processos com o negócio e seus usuários: caso os consultores e o GP não conheça exatamente a rotina das pessoas que vão, de fato, utilizar o sistema, fatalmente executarão algo que não e esperado pelo cliente do projeto.


  • Falta de envolvimento dos usuários (KeyUsers)  ou consultores internos do cliente: Uma determinadas empresa, após desenvolver um novo processo no SAP em um projeto de Coletores, começou a ter problemas com a qualidade dos dados, tudo isso ocorreu porque, descobriu que os operadores do pátio eram responsáveis pela coleta dos dados no pátio da companhia,  e não conseguiam digitar corretamente nos computadores de mão por usarem um  (EPI) obrigatório Luva. Este pequeno detalhe acabava comprometendo todo o processo.


  • Informar e comprometer os patrocinadores do projeto e usuários: tudo tem de estar escrito e assinado. Todos os envolvidos no projeto precisam ter consciência do que está no papel e o que será feito, saber que é isso que será realizado, informando os impactos e processos, nada mais ou menos.


  • Iniciar o Projeto  antes de definir o escopo: nada acontece antes que o cronograma e os recursos estejam bem definidos e formalmente aprovados pelo cliente.


  • Modificações do  escopo do projeto: Gestão de áreas, estratégias e cenários econômicos mudam, mas não é possível modificar o projeto a cada novidade de mercado por este motivo temos que  manter sempre o foco no escopo definido e acordado entre as partes.



Fase 3 – Realização / Execução.


  • Não execução de testes unitários e integrados: Sabemos que uma média de vinte por cento a trinta por cento do tempo total do  projeto deve estar reservado para os testes unitários e integrados. E eles só são válidos se forem devidamente documentados, evidenciados e assinados.
  • Não planejamento ou falta de treinamento dos usuários: É muito comum cometermos o erro reduzir o tempo e custo do projeto cortando o treinamento dos usuários. É necessário ter um plano de treinamento, que serve, também, para avaliar o conhecimento dos usuários e indiretamente efetuar um QA no projeto.
  • Não saneamento e definição das cargas de dados mestres no SAP: O sistema SAP gera mudanças culturais na empresa. Muitas vezes, os funcionários estão acostumados a usar diversos sistemas legados, cada um referente a uma determinada época. Por isso é preciso definir o alcance do novo sistema. Falta de dados mestre também é um problema. Se um usuário diz que precisa trabalhar com determinada informação, ela deve estar saneada e muito clara e muitas vezes não significa, necessariamente, que ela exista.



Fase 4 – Preparação Final.


  • Não planejamento e divulgação do plano de cut over: O GoLive deve estar muito claro quando irá acontecer a entrada da nova configuração ou do próprio SAP , e temos que informar quando irá ocorrer o  desligamento de antigo, isso deve estar definido e o processo planejado com as áreas impactadas.
  • É impossível fazer isso sem causar impacto. Este plano tem de ser discutido já na fase de planejamento do projeto com todos que estão envolvidos com o projeto e este acompanhamento deve ocorres durante todo o projeto.



Fase 5 – GoLive e Suporte.

Não planejar o suporte pôs GoLive: Após o GoLive e muito comum após estar tudo funcionando, termos uma não preparação ou não foi executada a passagem de conhecimento para quem, irá executar o suporte ou o time de suporte está mal dimensionado. Outros problemas são a falta de documentação clara sobre o que foi configurado, ausência de BBP, EF, ET, documentação de treinamento e falhas no entendimento das responsabilidades dos envolvidos.


Testes executados pôs GoLive: Temos muitos projetos que para cumprir prazos de entrega e sacrificam o testes, os GP’s optam por executar os testes após o GoLive, mas temos sempre que entender que os  testes devem ser feitos durante a fase de testes. Testar quando o usuário está precisando da ferramenta ira nos trazer muitos problemas para o cliente.



               Best Regard’s


                    Gilberto Disessa Junior


To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply