A implementação de um ERP é sempre um projeto de alta complexidade tendo em vista sua abrangência e impactos na organização. Desde que a SAP comunicou ao mercado que o ERP SAP ECC 6.0 será descontinuado e em conclusão terá sua evolução interrompida a partir de 2025, as empresas que possuem este sistema estão considerando um projeto de evolução de versão no plano estratégico de TI para os próximos 3-5 anos.
Já liderei muitos projetos como este e gostaria de dividir esta experiência em 7 frentes. Como o assunto é abrangente, vou dividir em 3 artigos. E ao final, vamos deixar o link para a continuação da matéria.
Neste material, vou abordar 2 dois assuntos: Time de projeto e Escopo e Desenvolvimento.
Time de Projeto
É lugar comum dizer que a implementação de um ERP demanda dedicação exclusiva de profissionais da organização. E para que o escopo seja definido corretamente, geralmente é necessário o envolvimento dos melhores profissionais, aqueles que são referência no desempenho de suas funções, especialistas no processo de negócio em que atuam. Eis o primeiro desafio: eles não estão disponíveis, pois normalmente são indispensáveis para executar a rotina diária da empresa e acabam tendo uma dedicação parcial no projeto, ou como costumo brincar: estão full time nos dois lugares. Mas, como resolver isso?
Novamente, o lugar-comum é dizer que a alta-direção da empresa deve garantir a disponibilidade destes profissionais. Na verdade, só vi isso acontecer uma vez, onde o CEO patrocinou isso às custas de muita pressão dos gestores das áreas e de ter que lidar com alguma perda na qualidade das entregas do dia-a-dia.
Também já vi a empresa contratar antecipadamente profissionais nas áreas de negócio que passaram a aprender e executar as operações do dia-a-dia para liberar aqueles recursos escolhidos para se dedicarem ao projeto. É uma ótima saída, mas pouco escolhida em função dos altos custos envolvidos e de gerar uma insegurança naqueles que estão sendo deslocados para o projeto ao verem seu posto original ocupado temporariamente por outro profissional.
Outra solução interessante
É o embarque antecipado de especialistas da consultoria implementadora com o objetivo de realizar uma imersão nas áreas e aprender os processos, as especificidades, a linguagem e o dia-a-dia da operação da empresa. Esta abordagem tem a vantagem então de trazer a cultura da empresa para dentro da consultoria e isso ajuda muito na qualidade do desenho de processos e gap analysis da fase de exploração. Esta opção não isenta portanto a organização de ter os profissionais envolvidos e responsáveis pelo desenho de processos e definições do projeto, mas reduz muito o risco e dependência exclusiva do conhecimento dos profissionais da organização.
Da parte da consultoria implementadora os cuidados são em aportar time com conhecimento e experiência de SAP S/4HANA, seja para os consultores funcionais quanto desenvolvedores SAP ABAP. Como se trata de um novo produto, houveram mudanças significativas em vários módulos e na forma de resolver limitações da versão anterior. A linguagem ABAP e a modelagem de dados também evoluiu. Os profissionais implementadores precisam do conhecimento de SAP S/4HANA para então aproveitar ao máximo a nova tecnologia.
Escopo e Desenvolvimento
A experimentação e prototipação são os diferenciais na metodologia SAP Activate para a fase de exploração. A SAP disponibiliza então durante a fase de Discovery, um ambiente cloud “trial” para que os profissionais da organização possam fazer uma imersão nos processos standard e se ambientarem com as telas e sequência de operações. Na fase de Prepare, é disponibilizado o ambiente de aprendizado que habilita os usuários a percorrerem trilhas de aprendizado dos módulos.
Em relação ao escopo,
O objetivo é terminar a fase de Explore tendo mapeado todas as necessidades de desenvolvimento e configurações específicas que irão compor o product backlog, resultantes do processo de gap analysis. O instrumento para isso são os workshops que discutem cada item de escopo de cada processo de negócio em dois ciclos “A” e “B”.
No ciclo “A”,
Os workshops têm por objetivo apresentar a solução standard SAP para cada item contemplado no escopo de um processo de negócio através de prototipação e avaliar a necessidade de adequações com os representantes das áreas de negócio.
No ciclo “B”,
Os workshops servem para apresentar como ficou a solução final, quais os gaps de desenvolvimento e configuração estão previstos e compõem o product backlog. Depois dos workshops, a lista de gaps é classificada e organizada em sprints de desenvolvimento.
Quais são os cuidados recomendados nesta etapa da implementação do ERP SAP S4HANA?
Planejar bem o tempo necessário para a preparação e prototipação dos scope-items, realização das apresentações dos processos e mapeamento de gaps.
É muito comum o planejamento dos workshops subestimar o tempo necessário para a preparação dos protótipos e isso pode fazer com que a sessão do workshop não alcance o objetivo de transmitir aos representantes de negócio como funcionaria aquele processo no SAP.
Também é comum fazer um planejamento linear para todos os processos (exemplo: 2 horas de demonstração, 2 horas de discussão, 1 hora para registro dos gaps). Isso não funciona bem, porque existem processos simples, que demandam menos tempo e outros mais complexos que exigirão 5 horas de discussão e ainda podem depender de algumas decisões executivas para definir ou não a necessidade de um desenvolvimento específico.
A recomendação aqui é classificar antecipadamente portanto os processos de negócio pela criticidade e planejar tempo e esforço diferente, até mesmo prevendo várias sessões em dias alternados para aqueles processos que podem depender de decisões executivas. Lembra da recomendação anterior de provocar uma imersão antecipada dos consultores no dia-a-dia da organização? Ajuda muito nesse ponto por antecipar os processos críticos.
Garantir a participação nos workshops das pessoas da organização que conhecem os detalhes da operação e que tenham poder de decisão para mudar o processo. Sabe qual é o ponto aqui? Normalmente são pessoas diferentes.
É um engano convidar somente os gestores com poder de decisão sobre mudanças em processos de negócios, porque normalmente falta a estes profissionais o conhecimento dos detalhes da operação, de como são tratados os casos de exceção, as dificuldades enfrentadas no dia-a-dia.
Da mesma forma
É um erro convidar somente o profissional especialista nas operações, mas que não têm poder para decidir sobre realizar uma mudança de processo na empresa para evitar um desenvolvimento específico. O ideal é ter a participação então dos dois profissionais, especialistas e tomadores de decisão.
O problema com isso é a alocação dos recursos que ficam dedicados nas várias sessões de workshop por várias semanas. O desafio é dessa forma montar uma agenda que comporte a disponibilidade, e nesse caso a pressa é inimiga mortal da qualidade dos resultados desta fase.
Manter o controle de “Open Points” e das decisões ou medidas concordadas para solucioná-los.
Ao longo dos workshops, os processos de negócio executados no SAP são apresentados e surgem muitas dúvidas sobre a aderência destes processos às necessidades da empresa.
Os consultores
Tentam entender dessa forma as especificidades da empresa e endereçá-las com um processo standard ou com a menor exigência de desenvolvimento possível e ao mesmo tempo a empresa tenta entender o processo proposto pelo ERP e avalia se é possível mudar então o processo vigente para aquele proposto.
É importante
Que todas as dúvidas ou verificações a serem realizadas pelos consultores e pela organização sejam então registrados em uma ferramenta e que na medida em que forem discutidos sejam documentadas as alternativas de solução apresentadas e a decisão final.
Também devem ser guardados os documentos que suportaram a decisão, como planilhas, atas de reunião, dentre outros. Esse histórico é fundamental nas fases futuras do projeto ou até mesmo depois dele.
Reservar um prazo entre os workshops “A” e “B” para que os “Open Points” sejam solucionados e os consultores façam a atualização dos documentos de processo e preparem a apresentação dos workshops “B”
É muito comum planejar a realização dos workshops “B” na sequência do workshop “A”.
Dessa forma
É bem provável que os consultores tenham dificuldade de ter toda a documentação atualizada para as sessões do workshop “B” e que a empresa ainda tenha “open points” pendentes de solução.
Também é nessa fase que é feita uma primeira rodada de “Delta Scope Prioritization”, que classifica os gaps levantados em indispensáveis (Must), necessários (Should), possíveis (Could) e desejáveis (Would). A recomendação é fazer um planejamento que deixe alguns dias entre os ciclos de workshop para acomodar todas estas atividades e que os workshops do ciclo “B” não sejam realizados se houverem “open points” não resolvidos.
Fazer uma revisão final da classificação dos gaps que compõem o “Product Backlog”.
Essa lista impacta no prazo e no custo da implementação porque a partir da lista de gaps e do esforço de cada um é projetado o número de horas de implementação e por consequência no prazo e custo do projeto. A recomendação é que a empresa seja capaz de avaliar se os gaps levantados e o esforço de implementação estão compatíveis com o orçamento e prazo planejado no projeto. Havendo diferenças, deve ser tomada uma decisão que passa pelo replanejamento do projeto ou pela revisão da lista de gaps, procurando reduzi-los ou priorizá-los a fim de acomodar o planejamento inicial.
Controlar o progresso das Sprints de desenvolvimento realizado pelos times.
Dentro do tema escopo e desenvolvimento, esta etapa faz parte da fase de “Realize” da metodologia SAP Activate.
Os times
estão empenhados na codificação e configuração dos vários gaps e nessa etapa é importante controlar o progresso dos times através das cerimônias e instrumentos da metodologia ágil: Sprint planning, Daily meetings, Sprint preview e sprint retrospective, além do controle visual dos quadros Kanban. A metodologia ágil possibilita o replanejamento de itens não entregues em uma sprint para a próxima, mas deve-se estar atento para evitar que todo o atraso não se acumule na última sprint.
Usar o Fiori e o SAP GUI onde forem melhor aplicados.
O SAP S/4HANA traz muitas das funcionalidades disponíveis em aplicações SAP Fiori, um front-end web com usabilidade e design moderno e que é acessível em várias plataformas (inclusive pelo celular) pelo fato de ser web e exigir somente um navegador instalado.
Minha experiência com o SAP Fiori
Me fez concluir que ele é ótimo para consultas, análises de dados ou operações de entrada de dados de volume reduzido. As funções que exigem entrada de dados massiva, continuam sendo mais produtivas se realizadas no SAP GUI. Funções que então exigem visualização de um maior número de informações na mesma tela também são favorecidas pela praticidade do SAP GUI.
Além disso,
o SAP Fiori é ainda um produto em evolução e apesar de já estar bem completo no que diz respeito aos módulos mais usados, nem todas as transações existentes no SAP GUI já possuem um equivalente no SAP Fiori, por isso, tenha o cuidado de avaliar a disponibilidade e usabilidade de apps Fiori em relação ao uso do SAP GUI.
Na continuação desse artigo, vou falar sobre os desafios na implementação de SAP S/4HANA, além disso, abordarei as frentes de Integração, Saneamento e Migração de Dados e Change Management.
Por Daniel Arruda
Diretor de TI com mais de 25 anos de experiência.
Foi responsável por inúmeras implementações de ERP SAP ao longo de sua carreira.
+ sobre Daniel Arruda
