[Resolvido] 10 lições-chave que todo CIO precisa conhecer sobre s

[Motta 645]

10 lições-chave que todo CIO precisa conhecer sobre atualização de sistemas ERP

 

 

Quinta-feira, 12/07/2012 às 09h00, por Samuel Gonsales

 

Se há um processo que tira o sono de muitos CIOs e equipes encarregadas pelo ERP nas mais diversas organizações é o paradigma em torno das atualizações de sistemas ERPs.

 

O que os CIOs esperam de atualizações do ERP é que elas sejam situações de tranquilidade, mas comumente não é isso o que acontece, e esse cenário precisa ser muito bem analisado para que se possa ter uma boa noção dos potenciais problemas que podem ocorrer em decorrência de uma atualização mal sucedida.

 

Este artigo tem o intuito de fornecer algumas preciosas lições sobre melhores práticas de mercado para atualizações bem sucedidas de seus sistemas ERP.

 

 

Lição #1 – Conheça os reais motivadores e a relevância da atualização

É muito comum clientes de sistemas ERP realizarem atualizações sem conhecer os reais motivadores de tal atualização. Alguns o fazem por mero desconhecimento, outros o fazem porque acham coerente estar com o release mais atual e não há nenhum problema nisso, mas a recomendação antes de atualizar é sempre considerar mais um fator: qual a relevância da atualização?

 

Se o CIO observar, por exemplo, que uma determinada atualização dá a cobertura de um novo processo de negócio, ou atende a uma nova obrigação fiscal/legal, com certeza encontrou relevância para a atualização.

 

É fundamental, também, que o CIO, ou equipe encarregada pelo ERP, comunique em sua organização os benefícios que serão alcançados com a atualização, de forma que os usuários do ERP entendam a relevância e os motivadores e apoiem a equipe do ERP durante os processos necessários para que a atualização seja bem sucedida.

 

Melhores práticas de mercado indicam, ainda, que não se deve proceder com a atualização se o CIO e a equipe encarregada pelo ERP não encontrarem o verdadeiro valor da atualização.

 

Lição #2 – Conheça detalhadamente os processos de negócio de sua empresa que são cobertos pelo ERP

O CIO, ou a equipe encarregada pelo ERP na organização, deve conhecer detalhadamente os processos de negócio que são cobertos pelo ERP, pois essa ação determinará os testes que precisarão ser realizados para garantir o êxito da atualização. Devem conhecer também quem são os usuários-chave que terão a missão de ajudar nos testes da nova versão.

 

O que comumente ocorre é que há diversos processos de negócio que não são formalmente conhecidos, processos que são utilizados pouquíssimas vezes e, vez por outra, após uma determinada atualização, é necessário usar esse processo, e nessa hora a equipe descobre que em decorrência da atualização esse processo sofreu mudanças ou depende de uma nova parametrização, ou depende de um novo treinamento, ou não está funcionando corretamente.

 

Melhores práticas de mercado indicam que, diante desse cenário comum, é preciso que CIO e equipe encarregada pelo ERP na organização criem uma rotina formal que esteja bem detalhada e documentada de todos os processos de negócio, sejam eles processos corriqueiros ou esporádicos, que são cobertos pelo ERP de forma que, ao receber uma nova atualização do ERP, se possa verificar que processos de negócio vão requerer atenção especial para garantir sucesso na atualização.

 

Quando a ação de manter formalmente o conhecimento de seus processos não se aplicar à sua organização, CIO e equipe encarregada pelo ERP devem assumir maiores riscos na atualização e que eventualmente algum processo desconhecido ou pouco utilizado poderá não funcionar adequadamente em decorrência de uma atualização.

 

A atenção deve ser redobrada quando seu ERP tem algum tipo de integração com outros sistemas, pois o processo de integração pode ser afetado por atualizações no ERP e também por alterações no outro sistema que está integrado ao ERP. É fundamental conhecer detalhadamente os processos para poder ter essa visão holística.

 

Lição #3 – Exija que seu fornecedor informe detalhadamente alterações do ERP que deram origem à atualização

Na lição #1, aprendemos que os motivadores e a relevância da atualização precisam ser verificados, contudo essa lição só se aplica quando seu fornecedor informa detalhadamente que alterações deram origem à essa atualização.

 

Infelizmente é comum encontrarmos fornecedores de ERP que lançam atualizações que não têm todos os detalhes das mudanças e das alterações que estão sendo entregues, e essa situação é absolutamente preocupante, pois sem saber exatamente o que foi alterado é impossível garantir que uma atualização seja aplicada sem maiores dores de cabeça para o CIO e equipe encarregada pelo ERP na organização.

 

Outro infortúnio é quando há documentação pertinente às mudanças entregues na atualização, mas a qualidade das informações é precária e não envolve todos os temas e processos tangenciais necessários. Muito do que é gerado de documentação pelos fornecedores de ERP trata das características técnicas, e não dos processos de negócio afetados na organização, e é preciso um exercício por parte do CIO e da equipe encarregada pelo ERP na tradução dessas informações precárias para o seu dia-a-dia.

 

Dessa forma, é preciso que, como clientes, as organizações exijam de seus fornecedores a transparência de identificar claramente as mudanças e, em caso de haver uma mudança não comunicada que cause problemas após uma atualização, os clientes devem procurar o fornecedor do ERP para que este melhore seus processos de forma a garantir que isso não volte a acontecer no futuro. Se a situação for recorrente, o CIO e a equipe encarregada pelo ERP devem reportar a questão ao board para que sejam tomadas as providências cabíveis.

 

É fundamental, ainda, que seu fornecedor de ERP tenha um recurso de auditoria da atualização, que permita claramente evidenciar todas as mudanças que ocorreram ao longo do tempo, pois se no futuro sua empresa precisar rever o que foi alterado nas últimas 4 ou 5 atualizações terá essas informações facilmente.

 

Lição #4 – Mantenha um ambiente para homologação das atualizações

Inicialmente esse parece um investimento desnecessário, mas no longo prazo ter ou não ter um ambiente para homologação da atualização pode ser um grande fator de sucesso.

 

Imagine uma empresa de varejo com mais de uma centena de lojas espalhadas pelo país, utilizando um ERP para gerir toda a companhia. Durante uma determinada atualização, a empresa não faz testes pertinentes à compatibilidade da nova versão com suas impressoras fiscais e utiliza um simulador para aferir que as operações do ponto de venda (PDV) estão OK.

 

Ao implantar a nova versão em ambiente de produção, todas as impressoras fiscais deixam de funcionar. Todas as operações de venda da organização falham e certamente para o board a responsabilidade pelos prejuízos resultantes da atualização devem ser alocados no centro de custos da TI, pois houve a decisão de colocar em produção uma atualização que impedia a empresa de vender.

 

Dessa forma, a sugestão é que se tenha um ambiente de homologação das atualizações com as mesmas características da operação, de forma que seja possível simular todo e qualquer processo de negócio da organização que é coberto pelo ERP.

 

Lição #5 – Crie um plano de homologação das atualizações que envolva todas as áreas de negócio que utilizam o ERP

Há um erro clássico nas organizações de sinalizar que o ERP é de responsabilidade exclusiva do departamento de TI, pois a TI, embora suporte o ERP como um de seus serviços prestados aos usuários das organizações, não domina todos os processos de negócio que são cobertos pelo ERP e, por esse motivo, não tem condições de sozinha testar todos os processos, validar os benefícios entregues em novas versões se eles são aderentes ao negócio e, ainda, garantir que todo o escopo do ERP utilizado na organização está atendido na nova versão.

 

Dessa forma, melhores práticas de mercado sinalizam que sempre que houver uma nova atualização do ERP, o CIO e as equipes encarregadas pelo ERP nas organizações devem convocar usuários-chave para que, com base nos conhecimentos específicos dos processos de negócio da companhia e munidos das informações que o fornecedor do ERP enviou informando as mudanças que ocorreram no ERP, seja criado um plano de homologação das atualizações.

 

Uma vez que o plano esteja montado, as tarefas são distribuídas a cada usuário-chave, de forma que ele esteja encarregado de verificar as mudanças que ocorreram no ERP que impactam seu dia-a-dia e também de discutir com sua equipe eventuais melhorias que possam ser implementadas.

 

Ao final dos testes de cada área, deve-se fazer um teste integrado (piloto) das operações conjuntas para determinar todos os impactos e ganhos.

 

Se sua organização não dispõe de um plano de homologação, certamente os riscos decorrentes da atualização serão maiores e devem ser comunicados internamente, de forma que não haja expectativas diferentes.

 

Lição #6 – Conheça os custos envolvidos na atualização

Os custos envolvidos na atualização de versões de ERP são os mais diversos possíveis, por isso é importante que o CIO e as equipes encarregadas pelo ERP nas organizações conheçam muito bem como seus fornecedores aplicam esses custos.

 

Os custos também não ficam muito explícitos quando da contratação do ERP e dificilmente as organizações se atentam para esse custo no momento da adoção da ferramenta. Contudo, é preciso ter ciência de que numa atualização do ERP sua organização sempre terá investimentos significativos.

 

Outra questão que precisa ser desmistificada é a frequência das atualizações, pois, conhecendo os custos envolvidos e também essa frequência, é possível planejar os investimentos no curto prazo e até mesmo considerar esses valores no orçamento anual de TI.

 

Além da frequência das atualizações, é preciso ter ciência do suporte que é prestado pelo fornecedor do ERP, pois, em muitos casos, os fornecedores descontinuam determinadas versões de seus produtos, o que força a organização a atualizar o ERP mesmo a contragosto.

 

Para se ter uma idéia da vastidão de diferentes custos envolvidos, podemos citar:

 

Custos com consultores especialistas em atualizações específicas;

Custos com deslocamentos;

Custos adicionais para fazer a atualização fora do horário de expediente;

Custos com treinamentos decorrentes de novas funcionalidades liberadas nas atualizações;

Custos com mão-de-obra específica para compatibilização das bases de dados;

Custos com aquisições de hardware e outros softwares decorrentes de atualizações (novo sistema operacional, mais memória, mais unidades de armazenamento, nova versão do banco de dados etc.);

Custos internos com pessoal para realização de testes (tempo dedicado para os testes, horas extras etc.).

Esses são só alguns exemplos, mas seria possível ampliar a lista significativamente.

 

Lição #7 – Conheça os tipos de atualizações disponibilizados por seu fornecedor ERP

Alguns fornecedores de ERP têm políticas de atualização e até mesmo tipos de atualização de seus produtos muito bem definidos e estruturados.

 

Para citar um exemplo, um grande player nacional de ERP dispõe de pelo menos três tipos de atualizações do seu produto.

 

O primeiro tipo trata de atualizações bem pontuais, em que o fornecedor de ERP trata de um problema especificamente. É frequentemente utilizada para a correção de um bug, por exemplo. Esse tipo de atualização é tão simples que pode ser aplicada pela própria equipe encarregada pelo ERP na organização. Pode ser liberada e implementada semanalmente.

 

O segundo tipo trata de atualizações mais abrangentes e uniformes, em que são criados pacotes de correções e novas funcionalidades, semelhante a um Service Pack do seu Windows. O nível de criticidade é moderado e não exige ações de terceiros. Pode ser liberada e implementada a cada bimestre.

 

O terceiro tipo é bem mais consistente, altera características do banco de dados, implementa novos módulos e recursos, semelhante à troca de uma versão do Windows (por exemplo, da versão XP para a 7). Exige compatibilização da base de dados e conhecimentos técnicos mais avançados, quando se faz necessário envolver o fornecedor ou um terceiro por ele autorizado/homologado. Pode ser liberada semestralmente, anualmente ou até a cada dois anos.

 

Obviamente que o player que destacamos acima tem clientes de todos os tamanhos, inclusive clientes onde não há muitas janelas de atualização disponíveis e aqueles que esperam respostas rápidas, especialmente para a correção de bugs. Existem, no entanto, sistemas ERP bem mais simples e menores, e esses fornecedores não têm toda a estrutura e arquitetura citada acima, portanto suas atualizações são bem amadoras.

 

Existe, contudo, uma tendência de mercado que busca criar tipos de atualizações mais simples que não dependam tanto do fornecedor e que possam ser realizadas com sucesso pelo CIO e equipe encarregada pelo ERP na organização.

 

Como estamos falando cada dia mais em ERP na nuvem e SaaS, essa tendência de criar atualizações mais simples está se acentuando a cada dia.

 

Lição #8 – Não implante novas funcionalidades disponibilizadas nas atualizações sem o acompanhamento do fornecedor para garantir aderência aos processos de negócio

Muitos clientes de ERP tentam sempre adotar ao máximo as novas funcionalidades que são disponibilizadas pelo fornecedor. Com essa atitude, esses clientes estão sempre muito alinhados com as novidades recém-lançadas pelo fornecedor, o que é muito bom para os negócios se a implementação das novas funcionalidades ocorrer da forma correta.

 

É preciso, contudo, que os clientes de ERP estejam cientes dos impactos demandados pela implementação de novas funcionalidades e módulos em relação a funcionalidades e módulos que já estavam funcionando anteriormente. É como ouvir algum cliente pedir ao fornecedor que sejam habilitadas determinadas funcionalidades, ainda que essas funcionalidades não tenham sido corretamente entendidas, testadas e homologadas em relação à sua aderência aos processos de negócio adotados pela organização.

 

Quando isso ocorre, é bem comum depois de um determinado tempo o cliente descobrir que ao habilitar determinada funcionalidade ele deixou de ter acesso a outras funcionalidades, uma vez que tratava-se de funcionalidades excludentes.

 

Como exemplo, podemos citar uma empresa que não tinha integração bancária para pagamentos (Pagfor, Sispag etc,) e com a nova funcionalidade disponibilizada pelo fornecedor do ERP deseja implementá-la. Ao fazer a implementação sem o devido acompanhamento e homologação do fornecedor, o CIO e a equipe encarregada pelo ERP na organização não testam todos os cenários e implementam a nova funcionalidade em ambiente de produção. Depois de um tempo, um dos usuários do financeiro percebe que um relatório gerencial que é emitido quinzenalmente não está mais funcionando como antes e, ao contatar o fornecedor do ERP, descobre-se que esse relatório deixa de funcionar para títulos que são pagos através da integração bancária. Esse é um exemplo bem comum.

 

Para evitar esse tipo de ocorrência e minimizar o estresse decorrente dela, é fundamental a participação do fornecedor do ERP sempre que houver a implementação de novas funcionalidades.

 

Lição #9 – Tenha atenção redobrada aos impactos da atualização sobre eventuais customizações

No passado, sempre que uma organização fazia uma customização no ERP, havia uma dúvida gigantesca se essa customização poderia ser aproveitada quando fosse necessário atualizar o ERP.

 

Essa preocupação dos clientes levou os fornecedores a criarem novas e consistentes formas de atualizar o ERP, minimizando grande parte dos impactos dessa atualização sobre as customizações do produto.

 

No passado, se falava em reconstruir toda a customização do zero, refazer 100% do que foi customizado, mas recentemente os fornecedores criam condições em que não há mais essa necessidade e em grande parte basta recompilar as customizações para que elas voltem a funcionar normalmente.

 

Em alguns casos, a customização é impactada, por exemplo, pela alteração do formato ou tamanho de um campo da base de dados que é utilizado na customização, mas mesmo nesse cenário o impacto tornou-se pequeno, pois basta um pequeno ajuste na customização e tudo voltará ao normal.

 

O que não podemos perder de vista é que o core do ERP não contempla as customizações nativamente e, portanto, precisamos ter uma atenção redobrada para não perder de vista que os testes em ambiente de homologação precisam obrigatoriamente passar pelas customizações de forma a evitar que em ambiente de produção algo saia do controle.

 

Atenção redobrada também se seu ERP incorpora as customizações dentro do próprio ERP, sem uma camada específica para isso, pois nesse caso as chances de ocorrerem problemas são maiores, especialmente porque vários clientes do fornecedor fazem as mais diversas customizações nos mesmos módulos e funcionalidades, e a chance de uma customização de um cliente invalidar a customização de outro é grande; em alguns casos de pequenos fornecedores ERP, essa situação é bem frequente.

 

Fique atento também para os fornecedores que sempre enviam suas atualizações parametrizadas para o default do ERP, pois, nesses casos, uma customização que você fez no passado pode vir a ser desabilitada.

 

Lição #10 – Defina uma janela para a atualização em ambiente de produção que impacte minimamente seus processos de negócio

Essa é uma árdua tarefa para o CIO e a equipe encarregada pelo ERP, pois deve-se encontrar uma janela de atualização com vistas a minimizar consideravelmente o tempo de parada do ERP na organização.

 

Algumas organizações, contudo, têm operação 24 horas, 7 dias por semana, e para esses casos encontrar uma janela de atualização é quase impossível.

 

Se sua empresa depender de seu fornecedor para que a atualização do ERP seja executada, você precisa ficar atento aos horários disponíveis para as atualizações, pois há fornecedores que só realizam atualizações durante o horário comercial, o que causará impactos em sua organização.

 

Outra questão importante que o CIO e a equipe encarregada pelo ERP na organização precisam saber para definir a melhor janela para a atualização é quanto tempo tal atualização demandará. É possível, inclusive, que essa informação seja aferida com o acompanhamento detalhado da atualização do ambiente de homologação, mas deve-se ficar alerta e se possível manter um tempo extra para eventualidades não programadas, pois imprevistos podem acontecer.

 

É preciso ficar especialmente atento aos impactos das atualizações sobre os processos de negócio, pois há dias em que não é possível paralisar determinadas atividades do negócio, como por exemplo períodos mensais de fechamentos, períodos em que a empresa está divulgando promoções na mídia, períodos em que processos vitais, tais como vendas ou produção, serão muito impactados, e conhecer detalhadamente essas informações pode ser fundamental para o sucesso ou o fracasso da atualização de seu ERP.

 

Fonte : Imasters