Mostrando postagens com marcador ERP. Mostrar todas as postagens
Atolado no legado? Application Retirement é a solução
Abordagem ajuda a manter acesso aos dados críticos para o negócio.
Por Carlos Vidinha, consultor na Capgemini Consulting em Portugal
Um dos grandes desafios que os CIO enfrentam atualmente é o da expansão e complexidade do portfólio de aplicações sob a sua responsabilidade. Estamos perante décadas de crescimento descontrolado, incluindo as fusões e as aquisições de companhias, o crescimento do volume de dados e um vasto número de aplicações com integrações desenvolvidas sob medida.
Todos estes fatores resultaram em um legado de TI que acrescenta pouco valor ao negócio. Este legado inclui aplicações redundantes e outras com pouca ou nenhuma utilização, dados preservados durante anos sem critérios que os justifiquem, entre outras situações causadoras de entropia ao nível dos sistemas de informação corporativos.
A manutenção dessas aplicações consome a capacidade de intervenção das organizações ao nível tecnológico, de recursos financeiros e humanos. De acordo com o relatório Application Landscape de 2011, cerca de 2/3 dos CIO acreditam que uma parcela significativa das suas aplicações deve ser desativada, de forma a proporcionar uma melhor resposta aos desafios de negócio e tecnológicos, dos quais se destacam:
A. Desafios de negócio
Para dar resposta a estes desafios é necessária uma combinação de serviços com soluções de software, para a gestão de informação e a gestão e arquivo de dados, incluindo casos de uso e um roteiro tecnológico de implementação.
O Application Data Retirement é uma abordagem estruturada a esta problemática, que contempla a manutenção do arquivo de dados aplicacionais em um formato independente; a validação dos relatórios existentes perante o arquivo criado; a tomada de decisão de abandono de determinadas aplicações e de toda a sua infraestrutura/tecnologia; e a gestão da disponibilidade dos dados, entre outras soluções.
Os resultados da implementação desta abordagem traduzem-se na simplificação do portfólio aplicacional, contribuindo para a redução dos custos de manutenção, simplificando os projetos de investimento na evolução dos sistemas aplicacionais. Todas estas ações devem ser suportadas por um modelo comprovado de relacionamento que ajude o cliente a diagnosticar, com clareza, a sua situação atual, o que pretende alcançar, e a construir um percurso claro e mensurável para levar a cabo essa evolução.
Fonte: CIO Opinião
Por Carlos Vidinha, consultor na Capgemini Consulting em Portugal

Todos estes fatores resultaram em um legado de TI que acrescenta pouco valor ao negócio. Este legado inclui aplicações redundantes e outras com pouca ou nenhuma utilização, dados preservados durante anos sem critérios que os justifiquem, entre outras situações causadoras de entropia ao nível dos sistemas de informação corporativos.
A manutenção dessas aplicações consome a capacidade de intervenção das organizações ao nível tecnológico, de recursos financeiros e humanos. De acordo com o relatório Application Landscape de 2011, cerca de 2/3 dos CIO acreditam que uma parcela significativa das suas aplicações deve ser desativada, de forma a proporcionar uma melhor resposta aos desafios de negócio e tecnológicos, dos quais se destacam:
A. Desafios de negócio
- A proliferação de aplicações e o aumento do volume de dados dificultam a flexibilidade, a agilidade, a inovação e o crescimento do negócio;
- A necessidade de atualizar as aplicações para suportar o crescimento do negócio;
- A falta de planejamento e de conhecimento para a evolução aplicacional e a preservação dos dados.
- Os custos elevados de hardware (licenças, armazenamento de dados);
- A incapacidade para cumprir os Service Level Agreements (SLAs);
- O custo elevado dos encargos em Replication Communication Bandwidth;
- Os custos não justificáveis com a manutenção de aplicações somente para controle.
Para dar resposta a estes desafios é necessária uma combinação de serviços com soluções de software, para a gestão de informação e a gestão e arquivo de dados, incluindo casos de uso e um roteiro tecnológico de implementação.
O Application Data Retirement é uma abordagem estruturada a esta problemática, que contempla a manutenção do arquivo de dados aplicacionais em um formato independente; a validação dos relatórios existentes perante o arquivo criado; a tomada de decisão de abandono de determinadas aplicações e de toda a sua infraestrutura/tecnologia; e a gestão da disponibilidade dos dados, entre outras soluções.
Os resultados da implementação desta abordagem traduzem-se na simplificação do portfólio aplicacional, contribuindo para a redução dos custos de manutenção, simplificando os projetos de investimento na evolução dos sistemas aplicacionais. Todas estas ações devem ser suportadas por um modelo comprovado de relacionamento que ajude o cliente a diagnosticar, com clareza, a sua situação atual, o que pretende alcançar, e a construir um percurso claro e mensurável para levar a cabo essa evolução.
Fonte: CIO Opinião
10 lições-chave sobre atualização de sistemas ERP
Por Samuel Gonsales, diretor da Kayros IT Consultoria, especialista em modelos de gestão para empresas de moda e vestuário
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 as mesmas sejam situações de tranqüilidade, mas comumente não é isso 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.
Esse artigo tem o intuito de fornecer algumas preciosas lições aos leitores 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 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 apóiem 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 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 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 em 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 a 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 a tal atualização.
Infelizmente é comum encontrarmos fornecedores de ERP que lançam atualizações que não tem todos os detalhes das mudanças e alterações que estão sendo entregues e esta 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 que deveria. 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 equipe encarregada pelo ERP na tradução dessas informações precárias para o seu dia-a-dia.
Desta 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 equipe encarregada pelo ERP deve 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.
Desta 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
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 e 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 este 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 freqüência das atualizações, pois conhecendo os custos envolvidos e também a freqüência das atualizações é possível planejar os investimentos no curto prazo e até mesmo considerar esses valores no orçamento anual de TI.
Além da freqüência das atualizações é preciso ter ciência também 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:
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 3 tipos de atualizações do seu produto.
O primeiro tipo trata de atualizações bem pontuais, onde o fornecedor de ERP trata de um problema especificamente. É freqüentemente 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, onde 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 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, inclusive cliente 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 com mais simples está se acentuando a cada dia.
Lição #8 – Implante novas funcionalidades disponibilizadas nas atualizações somente com 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 e essa atitude é muito boa 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. É bem como, por exemplo, 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 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 stress 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 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 re-compilar as customizações para que estas 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 é maior, 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 e em alguns casos de pequenos fornecedores ERP essa situação é bem freqüente.
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 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 tem 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, portanto 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, contudo 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 fracasso da atualização de seu ERP.
Fonte: TI Inside
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 as mesmas sejam situações de tranqüilidade, mas comumente não é isso 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.
Esse artigo tem o intuito de fornecer algumas preciosas lições aos leitores 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 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 apóiem 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 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 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 em 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 a 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 a tal atualização.
Infelizmente é comum encontrarmos fornecedores de ERP que lançam atualizações que não tem todos os detalhes das mudanças e alterações que estão sendo entregues e esta 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 que deveria. 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 equipe encarregada pelo ERP na tradução dessas informações precárias para o seu dia-a-dia.
Desta 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 equipe encarregada pelo ERP deve 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.
Desta 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
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 e 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 este 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 freqüência das atualizações, pois conhecendo os custos envolvidos e também a freqüência das atualizações é possível planejar os investimentos no curto prazo e até mesmo considerar esses valores no orçamento anual de TI.
Além da freqüência das atualizações é preciso ter ciência também 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).
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 3 tipos de atualizações do seu produto.
O primeiro tipo trata de atualizações bem pontuais, onde o fornecedor de ERP trata de um problema especificamente. É freqüentemente 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, onde 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 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, inclusive cliente 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 com mais simples está se acentuando a cada dia.
Lição #8 – Implante novas funcionalidades disponibilizadas nas atualizações somente com 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 e essa atitude é muito boa 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. É bem como, por exemplo, 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 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 stress 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 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 re-compilar as customizações para que estas 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 é maior, 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 e em alguns casos de pequenos fornecedores ERP essa situação é bem freqüente.
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 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 tem 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, portanto 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, contudo 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 fracasso da atualização de seu ERP.
Fonte: TI Inside
Por que os projetos de ERP fracassam
Muitas vezes o fracasso de projetos tão complexos não tem nada a ver com questões técnicas, e sim com a cultura das organizações.
Grandes projetos, grandes problemas. Não importa a metodologia utilizada, a ferramenta escolhida e o tamanho da equipe. É comum, até demais, que implementações de sistemas de gestão (ERP) fracassem. Prazos são estourados, orçamentos vão muito além do limite e os resultados não correspondem às expectativas das áreas de negócios.
Apontar uma razão principal é difícil, mas existem alguns fatores comuns encontrados nas empresas que, fatalmente, levam ao mau resultado. Alguns pontos que fazem a diferença na hora de iniciar um projeto. É sempre bom tê-los em mente. Confira:
Falta de uma camada de gerenciamento de projetos: no mínimo, a empresas precisa conhecer as melhores práticas de gerenciamento descritas no PMBOK, principal publicação feita pelo PMI. Mas, qualquer metodologia serve, desde que esteja presente.
Falha no planejamento do projeto: essa talvez seja a fase mais crítica de um projeto. Segundo Moraes, as empresas não pode ter preguiça de escrever, fazer diagramas, relatórios, etc.
Processos críticos de negócios mal definidos: quase uma conseqüência do mau planejamento. Fatalmente, caso isso aconteça, a empresa terá de fazer mudanças no sistema depois de estar pronto.
Falha em detalhar os processos nas pontas: caso a empresa não conheça exatamente a rotina das pessoas que vão, de fato, utilizar o sistema, fatalmente fará algo inútil ou complicado demais.
Falta de envolvimento do pessoal das pontas: Moraes conta uma história curiosa. Determinada empresa, após implementar um novo ERP, começou a ter problemas com a qualidade dos dados. Após meses de investigação, descobriu que os operadores de empilhadeira, responsáveis pela coleta dos dados nos armazéns da companhia, não conseguiam digitar corretamente nos computadores de mão por usarem luvas. Este pequeno detalhe acabava comprometendo todo o processo.
Falha em preparar o sistema para agüentar os picos de utilização: nenhum sistema é utilizado com a mesma freqüência o tempo inteiro. É preciso saber o quanto ele agüenta e quanto terá de agüentar, quando for exigido em carga máxima.
Evangelizar os patrocinadores do projeto: tudo tem de estar escrito. “Se não está explicitamente indicado, está implicitamente excluído”, afirma Moraes. Todos os envolvidos no projeto precisam ter consciência do que está no papel e saber que é isso que será realizado, nada menos, nada mais.
Iniciar a implantação antes de definir o escopo: nada acontece antes que o cronograma e os recursos estejam bem definidos e formalmente aprovados.
Estouro do escopo: estratégias e cenários econômicos mudam, mas não é possível modificar o projeto a cada novidade de mercado. Por isso é fundamental ter um sistema bem definido de gerenciamento de mudanças.
Falhas de testes: de 20% a 40% do tempo total de projeto deve estar reservado para os testes. E eles só são válidos se forem devidamente documentados.
Falta de treinamento: é um erro reduzir o custo do projeto cortando o treinamento. É necessário ter um plano de treinamento, que serve, também, para avaliar o conhecimento dos usuários.
Falhas ao carregar os dados no sistema: um sistema ERP 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 também é um problema. Se um usuário diz que precisa trabalhar com determinada informação, não significa, necessariamente, que ela exista.
Falha no “cut over”: a data de inauguração do novo sistema, e desligamento de antigo, deve estar definida e o processo planejado. É impossível fazer isso sem causar impacto. Este plano tem de ser discutido já na fase de planejamento do projeto.
Falhas após o “go live”: depois de estar tudo funcionando, não é difícil se deparar com um time de suporte mal dimensionado. Outros problemas são a falta de documentação e falhas no entendimento das responsabilidades dos envolvidos.
Deixar os testes para depois do “go live”: testes devem ser feitos durante a fase de testes. Testar quando o usuário está precisando da ferramenta dará dor de cabeça, com absoluta certeza.
Fonte: CIO Gestão
Grandes projetos, grandes problemas. Não importa a metodologia utilizada, a ferramenta escolhida e o tamanho da equipe. É comum, até demais, que implementações de sistemas de gestão (ERP) fracassem. Prazos são estourados, orçamentos vão muito além do limite e os resultados não correspondem às expectativas das áreas de negócios.
Apontar uma razão principal é difícil, mas existem alguns fatores comuns encontrados nas empresas que, fatalmente, levam ao mau resultado. Alguns pontos que fazem a diferença na hora de iniciar um projeto. É sempre bom tê-los em mente. Confira:
Falta de uma camada de gerenciamento de projetos: no mínimo, a empresas precisa conhecer as melhores práticas de gerenciamento descritas no PMBOK, principal publicação feita pelo PMI. Mas, qualquer metodologia serve, desde que esteja presente.
Falha no planejamento do projeto: essa talvez seja a fase mais crítica de um projeto. Segundo Moraes, as empresas não pode ter preguiça de escrever, fazer diagramas, relatórios, etc.
Processos críticos de negócios mal definidos: quase uma conseqüência do mau planejamento. Fatalmente, caso isso aconteça, a empresa terá de fazer mudanças no sistema depois de estar pronto.
Falha em detalhar os processos nas pontas: caso a empresa não conheça exatamente a rotina das pessoas que vão, de fato, utilizar o sistema, fatalmente fará algo inútil ou complicado demais.
Falta de envolvimento do pessoal das pontas: Moraes conta uma história curiosa. Determinada empresa, após implementar um novo ERP, começou a ter problemas com a qualidade dos dados. Após meses de investigação, descobriu que os operadores de empilhadeira, responsáveis pela coleta dos dados nos armazéns da companhia, não conseguiam digitar corretamente nos computadores de mão por usarem luvas. Este pequeno detalhe acabava comprometendo todo o processo.
Falha em preparar o sistema para agüentar os picos de utilização: nenhum sistema é utilizado com a mesma freqüência o tempo inteiro. É preciso saber o quanto ele agüenta e quanto terá de agüentar, quando for exigido em carga máxima.
Evangelizar os patrocinadores do projeto: tudo tem de estar escrito. “Se não está explicitamente indicado, está implicitamente excluído”, afirma Moraes. Todos os envolvidos no projeto precisam ter consciência do que está no papel e saber que é isso que será realizado, nada menos, nada mais.
Iniciar a implantação antes de definir o escopo: nada acontece antes que o cronograma e os recursos estejam bem definidos e formalmente aprovados.
Estouro do escopo: estratégias e cenários econômicos mudam, mas não é possível modificar o projeto a cada novidade de mercado. Por isso é fundamental ter um sistema bem definido de gerenciamento de mudanças.
Falhas de testes: de 20% a 40% do tempo total de projeto deve estar reservado para os testes. E eles só são válidos se forem devidamente documentados.
Falta de treinamento: é um erro reduzir o custo do projeto cortando o treinamento. É necessário ter um plano de treinamento, que serve, também, para avaliar o conhecimento dos usuários.
Falhas ao carregar os dados no sistema: um sistema ERP 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 também é um problema. Se um usuário diz que precisa trabalhar com determinada informação, não significa, necessariamente, que ela exista.
Falha no “cut over”: a data de inauguração do novo sistema, e desligamento de antigo, deve estar definida e o processo planejado. É impossível fazer isso sem causar impacto. Este plano tem de ser discutido já na fase de planejamento do projeto.
Falhas após o “go live”: depois de estar tudo funcionando, não é difícil se deparar com um time de suporte mal dimensionado. Outros problemas são a falta de documentação e falhas no entendimento das responsabilidades dos envolvidos.
Deixar os testes para depois do “go live”: testes devem ser feitos durante a fase de testes. Testar quando o usuário está precisando da ferramenta dará dor de cabeça, com absoluta certeza.
Fonte: CIO Gestão
Como saber se é hora de trocar o ERP?
Sistemas de gestão não têm "data de validade", mas alguns pontos críticos podem determinar sua atualização.
Por Paulo Silas Martins, gerente comercial da SEND Informática
O mercado competitivo obriga as empresas a serem mais ágeis e a investirem cada vez mais na qualidade de seus produtos e serviços e também no atendimento aos clientes. Uma solução de ERP adequada é indispensável para que uma empresa obtenha destaque em seu segmento.
A tecnologia evolui, as empresas crescem e o ERP deve acompanhar essas mudanças. Há softwares que permitem customizações, mas nem sempre elas resolvem o problema, e a empresa se prejudica com um sistema que não atende mais as necessidades. É nessa hora que nasce a questão: chegou o momento de trocar o ERP?
A dúvida sobre trocar ou não o ERP surge porque a implantação de uma solução que envolve setores tão fundamentais da empresa é trabalhosa. Os funcionários precisam de tempo para adaptar-se ao novo sistema. Por isso, parece mais fácil fazer adaptações no ERP que as pessoas já estão acostumadas. Mas antes de decidir trocar ou não é preciso analisar algumas questões.
O surgimento de uma nova tecnologia não é fundamental para a troca do ERP. Mais importante que uma nova tecnologia é avaliar se as necessidades da empresa são atendidas pelo atual fornecedor do software. Crescimento da organização, mudanças legais ou alterações de processos internos são situações que exigem a alteração do sistema. Se o atual ERP consegue atender essas mudanças com eficiência, não há necessidade da troca.
Também é importante ressaltar que a solução ERP não tem "data de validade". Mas é preciso analisar se o fornecedor do software realiza as atualizações tecnológicas, nos bancos de dados e nos aplicativos. As novas tecnologias trazem maior agilidade na utilização de determinados processos e melhoram alguns procedimentos. Portanto, se o fornecedor não atualiza seu ERP pode haver a necessidade de trocá-lo.
Observar se o uso de planilhas eletrônicas é demasiado ou concorre com o ERP também é importante. Afinal, se é preciso um "sistema" paralelo, isso demonstra que a solução não está atendendo as necessidades, ou seja, está obsoleto. Se há dúvidas que a sua solução de ERP está ajudando a sua empresa a vencer seus desafios, talvez esteja na hora de pensar em trocá-lo.
Esses são alguns pontos a considerar para saber se é o momento mais adequado para isso.
Tecnologia
Atendimento
Customizações e melhorias
Fonte: CIO Gestão
Por Paulo Silas Martins, gerente comercial da SEND Informática
O mercado competitivo obriga as empresas a serem mais ágeis e a investirem cada vez mais na qualidade de seus produtos e serviços e também no atendimento aos clientes. Uma solução de ERP adequada é indispensável para que uma empresa obtenha destaque em seu segmento.

A dúvida sobre trocar ou não o ERP surge porque a implantação de uma solução que envolve setores tão fundamentais da empresa é trabalhosa. Os funcionários precisam de tempo para adaptar-se ao novo sistema. Por isso, parece mais fácil fazer adaptações no ERP que as pessoas já estão acostumadas. Mas antes de decidir trocar ou não é preciso analisar algumas questões.
O surgimento de uma nova tecnologia não é fundamental para a troca do ERP. Mais importante que uma nova tecnologia é avaliar se as necessidades da empresa são atendidas pelo atual fornecedor do software. Crescimento da organização, mudanças legais ou alterações de processos internos são situações que exigem a alteração do sistema. Se o atual ERP consegue atender essas mudanças com eficiência, não há necessidade da troca.
Também é importante ressaltar que a solução ERP não tem "data de validade". Mas é preciso analisar se o fornecedor do software realiza as atualizações tecnológicas, nos bancos de dados e nos aplicativos. As novas tecnologias trazem maior agilidade na utilização de determinados processos e melhoram alguns procedimentos. Portanto, se o fornecedor não atualiza seu ERP pode haver a necessidade de trocá-lo.
Observar se o uso de planilhas eletrônicas é demasiado ou concorre com o ERP também é importante. Afinal, se é preciso um "sistema" paralelo, isso demonstra que a solução não está atendendo as necessidades, ou seja, está obsoleto. Se há dúvidas que a sua solução de ERP está ajudando a sua empresa a vencer seus desafios, talvez esteja na hora de pensar em trocá-lo.
Esses são alguns pontos a considerar para saber se é o momento mais adequado para isso.
Tecnologia
- Evolução - A evolução de seu ERP NÃO acompanha a dinâmica de crescimento da sua empresa?
- Velocidade de mudança - As mudanças solicitadas no seu ERP demoram a serem realizadas?
- Necessidade de infraestrutura - O seu ERP exige uma infraestrutura com custos elevados para ser operacionalizado.
Atendimento
- Treinamento - O treinamento para novos usuários de seu ERP ou novos módulos, ou implementação de novas funcionalidades é eficaz?
- Suporte - Quando solicitado suporte ao seu fornecedor de ERP ele é eficiente? Seu fornecedor de ERP lhe fornece um suporte pró-ativo ou somente quando solicitado?
- Visitas - Seu fornecedor de ERP efetua visitas regulares e avaliação de seu nível de satisfação?
- Agilidade - O atendimento do seu fornecedor do ERP oferece a agilidade necessária a solução dos seus problemas no tempo desejado?
- Custo - O custo das visitas para atendimento de suas solicitações é elevado e acabam por inibi-las?
Customizações e melhorias
- Atendimento das solicitações - As suas solicitações de melhorias são atendidas ou há necessidade de partir para controles paralelos?
- Custo das solicitações - Os custos das customizações e melhorias inviabilizam sua execução?
- Agilidade da entrega - Os prazos de entrega de suas solicitações não atendem as suas expectativas de prazo desejado?
- Qualidade - A qualidade do atendimento de suporte ou atendimento de solicitações de melhorias não apresenta a qualidade esperada ou desejada?
Fonte: CIO Gestão
É hora de mudar o ERP?

Toda organização deve ter sua evolução amparada por uma estratégia. Por isso, pessoas, processos e tecnologia são pilares fundamentais no desenvolvimento de qualquer empresa, já que traçam o caminho da evolução. As pessoas precisam estar aptas a executar o trabalho de acordo com os processos estabelecidos. Quando capacitados e capazes de tomar as decisões certas para atender a estratégia, os funcionários garantem que o ciclo ganhe movimento e que possa ser reavaliado e melhorado sempre que necessário.
Com a análise dos processos é possível determinar o que pode atrapalhar ou auxiliar a estratégia da empresa e, principalmente, qual caminho facilita a troca de informações entre os setores.E a tecnologia, quando adequada ao momento da organização, funciona como facilitador inteligente que tem, como prioridade, acelerar e aumentar a segurança a precisão dos processos, que vão gerar informações necessárias para amparar a estratégia.
A mudança do sistema de gestão deve partir de uma visão estratégica, pois não existe a melhor ou pior tecnologia, e sim a mais adequada ao planejamento, processos e pessoas da organização. Com olhar na estratégia, é necessário avaliar se a tecnologia atual é capaz de suportar, nos médio e longo prazos, os processos necessários para sua execução. Se a resposta for positiva, a substituição não é necessária. Se a tecnologia atual não suportar a demanda, a estratégia pode ser prejudicada ao longo da execução do plano e coloca em risco a competitividade e o posicionamento de mercado.
Vamos focar nas empresas que têm o crescimento como objetivo. Por exemplo, se a estratégia indica que a meta é crescer 50% nos próximos dois anos por meio da criação de unidades de negócios, da abertura de fi liais em outros estados e do aumento da efi ciência de vendas, os gestores devem avaliar se a tecnologia irá apoiar as atividades, pois ela deve permitir a visualização e o controle de resultados por unidade e fi lial e a alteração dos processos de vendas para aumentar o fl uxo do negócio. Os funcionários devem ser treinados para preencher adequadamente as informações no sistema e podem ser necessárias contratações para suportar o novo posicionamento.
Se, em uma mudança como essa, o ERP não é alterado, a empresa pode ter de aumentar excessivamente o número de funcionários, devido à difi culdade de executar os processos por meio de uma tecnologia inadequada. Caso não faça contratações, os processos podem sofrer impacto. Como consequência, o sucesso da ação será comprometido.
Deve-se sempre olhar para o futuro e avaliar se, no cenário planejado, a tecnologia atual continuará sendo adequada e efi ciente ou se será necessário realizar alterações. Em algumas situações, o sistema de gestão pode ser apenas adaptado para atender à demanda que as mudanças estratégicas irão promover (quando a ferramenta possui escalabilidade sufi ciente); em outros, isso não é viável e deve ser substituído.
Mas como saber quando deve ser feita a mudança do ERP ou se ainda é possível dar sobrevida ao sistema atual? Cinco perguntas que podem orientar a decisão.
1. O ERP impedirá transações vitais?
O crescimento da empresa pode deixar as operações diárias complexas. A criação de processos, controles e departamentos exigem alterações no sistema. O ERP se torna o cérebro dessas mudanças, pois centraliza as principais operações e informações da empresa. Se um gestor não puder tomar decisões porque o sistema não disponibiliza dados estratégicos ou depende de muitas planilhas e controles manuais, é sinal de que modifi cações no ERP devem ser consideradas.
Mas várias pequenas mudanças podem transformar o sistema em uma colcha de retalhos. Remendado, ele não irá, necessariamente, impedir o crescimento ou a execução das estratégias. Mas a má conexão entre os programas pode causar instabilidade no ERP e deixá-lo vulnerável a erros, tanto do ponto de vista tecnológico, quanto do de negócios, já que pode comprometer a qualidade da informação que está no sistema, gerando decisões equivocadas. O novo ERP pode evitar esses erros.
2. A tecnologia está alinhada com a estratégia de crescimento da empresa?
O que mais vemos em veículos que cobrem o mundo empresarial são anúncios de lucros, lançamento de produtos e serviços, movimentações entre as empresas, compras, fusões, joint-ventures e fechamento de grandes contratos. Todos nós gestores sabemos que esses momentos são complicados, pois exigem atenção e dedicação de recursos financeiros e humanos.
Se sua empresa está passando por uma dessas situações, o ERP deve suportar os futuros processos que surgirão para que os erros sejam mínimos. Por isso, é importante o investimento na tecnologia. Mas, a escolha tem de facilitar as mudanças. Se os gestores têm planos de abrir capital na bolsa ou buscar investidores, ter um sistema de nível global, que garanta compliance, pode ser etapa de preparação, possibilitando maior segurança e informações precisas aos futuros investidores.
3. Os processos caberão na tecnologia atual?
Na execução da estratégia, o ERP precisa apoiar os novos processos e deve ser o facilitador de troca de informação entre as áreas. Porém, quando o sistema atende à demanda, algumas informações começam a ser passadas por fora e, pode ocorrer perdas de dados que deveriam ficar armazenados e, consequentemente, áreas correlacionadas trabalhando com informações erradas.
Na escolha do sistema, a empresa deve optar por fabricantes que investem em atualizações constantes com correções e inovações no sistema. Explico: o desenvolvimento das empresas, as movimentações do mercado e a exigência de novas leis fiscais no País demandam novos processos.
Por exemplo, por conta de SPED, SPED-Pis/Cofins, IFRS, Nota Fiscal Eletrônica etc, o fabricante deve desenvolver atualizações e disponibilizá-las o mais rápido possível para que a empresa atualize as atividades. Essa preocupação evita que multas sejam pagas e que outros prejuízos ocorram por atraso na adequação.
Alguns fabricantes também desenvolvem inovações que proporcionam benefícios e diferenciais competitivos para as empresas. É o caso do módulo que controla os contratos de venda e locação de propriedades, incluindo criação, atualização, renovação e encerramento de contratos entre outros, evita que o financeiro pague multas por atraso de pagamento das contas dos imóveis.
4. Quais os custos e benefícios em manter ou trocar de ERP?
Novos sistemas de gestão podem ter custos altos, pois incluem a compra de licenças e hardware, contratação de empresas de consultoria, treinamentos e disponibilidade de funcionários para atuar no projeto. Mas, muitas vezes, adequar o sistema atual pode sair mais caro que implementar um novo.
A quantidade de modificações necessárias pode significar dinheiro jogado fora, já que o sistema pode não ter escalabilidade suficiente para suportar os novos processos e, em pouco tempo, ter de ser substituído.
5. As pessoas estão preparadas para a nova tecnologia?
Novo ERP, nova cultura. É fato. Quando um sistema é implementado, os processos desenvolvidos pelos funcionários sofrem alterações. Por isso, deve-se incluir nos planos o tempo que toda a equipe, incluindo gerentes e diretores, terá de dedicar para se adequar aos processos e aprender formas de desenvolver o trabalhos.
É importante envolver os usuários e abrir um canal em que possam passar ideias e informações valiosas, evitando conflitos desnecessários no período de execução do plano estratégico. Com a conversa direta, aumentam as possibilidades dos funcionários se tornarem defensores dos novos sistema e cultura.
Devo destacar que nenhuma empresa é igual a outra. Mas esse diagnóstico, feito pelos próprios gestores, é o primeiro passo para essa grande mudança.
Fonte: CIO Gestão
terça-feira, 12 de julho de 2011
Postado por
Unknown