Os 5 maiores erros na implementação de um ERP - e como evitá-los

Qualquer pessoa que esteja a pensar em introduzir um sistema ERP ou em substituir um sistema existente tem normalmente um objetivo claro em mente: mais organização, uma melhor visão geral e menos fricção nas operações do dia a dia. A esperança é compreensível. Os processos devem decorrer de forma mais fluida, a informação deve estar disponível de forma centralizada e as decisões devem ser tomadas mais rapidamente.

No entanto, a prática mostra uma imagem diferente. Muitos projectos ERP revelam-se muito mais difíceis do que o previsto. Os calendários falham, os orçamentos são ultrapassados, os empregados reagem com cautela ou ficam sobrecarregados. Em alguns casos, existe mesmo a sensação paradoxal de que o trabalho se tornou mais complicado após a implementação do que antes.

O mais surpreendente é que: Nos casos mais raros, o problema real está no próprio software.

O ERP é frequentemente visto como um projeto de software puro

Um equívoco comum é que a introdução de um Sistema ERP como um projeto clássico de TI. Uma solução é selecionada, instalada e configurada - e depois espera-se que os processos da empresa se adaptem automaticamente a ela.

Em teoria, isto parece lógico. Na prática, porém, esta abordagem é insuficiente. Um sistema ERP não mapeia apenas dados, mas também métodos de trabalho, responsabilidades e estruturas estabelecidas. Ele intervém em processos que se desenvolveram ao longo de anos - por vezes décadas. Quem pensa exclusivamente em termos técnicos esquece o facto de que cada mudança no sistema implica também uma mudança no comportamento dos empregados e na própria organização.

A introdução de um sistema ERP não é, portanto, uma questão isolada de software, mas sempre também uma intervenção organizacional - com todas as suas consequências.

Os verdadeiros problemas começam muitas vezes antes da implementação

Outro ponto que é subestimado em muitos projectos: O rumo decisivo é normalmente definido muito antes de a primeira máscara ser desenhada ou de a primeira Interface está programado.

Processos pouco claros, expectativas diferentes entre departamentos, falta de responsabilidades ou suposições não ditas - tudo isto muitas vezes só se torna aparente quando um sistema começa a mapear estas estruturas. E é precisamente aqui que surgem as fricções.

O sistema ERP funciona então como uma espécie de espelho. Mostra onde é que as coisas "funcionavam de alguma forma", mas nunca foram claramente definidas. O que antes era compensado por improvisações, apelos ou conhecimentos individuais, de repente tem de ser claramente descrito.

Isto não é uma falha do sistema, mas uma consequência da sua tarefa.

Experiência prática: o sucesso raramente depende apenas da tecnologia

No nosso trabalho diário no GoFileMaker, sabemos que o sucesso de um projeto ERP raramente é determinado por detalhes técnicos. É claro que a estabilidade, a funcionalidade e a interface do utilizador desempenham um papel importante. Mas raramente são o fator decisivo.

É muito mais importante a clareza com que uma empresa conhece os seus próprios processos, o realismo com que as expectativas são formuladas e a consistência com que as decisões são apoiadas internamente. A questão da flexibilidade com que um sistema pode reagir às mudanças e da sua independência a longo prazo está também a tornar-se cada vez mais importante.

Na prática, tem sido demonstrado repetidamente que duas empresas podem iniciar um projeto ERP com a mesma situação inicial - e ainda assim obter resultados completamente diferentes. A diferença geralmente não está no software, mas na forma como ele é utilizado.

Os cinco maiores erros repetem-se com uma frequência surpreendente

Se acompanhar os projectos ERP durante um longo período de tempo, rapidamente reconhece padrões recorrentes. Certos erros ocorrem repetidamente, independentemente do sector, da dimensão da empresa ou da solução utilizada. Estes incluem, entre outros:

• Processos pouco claros ou apenas aparentemente conhecidos
• o desejo de automatizar demasiado e demasiado cedo
• a decisão a favor de sistemas difíceis de adaptar posteriormente
• demasiado pouco respeito pela sua própria soberania em matéria de dados
• e a tendência para delegar responsabilidades em fornecedores externos ou no próprio software

Estes pontos não são espectaculares - mas é precisamente aí que reside a sua importância. Muitas vezes, surgem gradualmente e só se tornam visíveis quando a implementação já está em curso.

Neste artigo, gostaríamos de analisar mais de perto estes cinco erros clássicos e categorizá-los numa perspetiva prática. O objetivo não é fornecer um guia universalmente válido, mas sim transmitir uma ideia do que é realmente importante numa implementação ERP - e onde vale a pena olhar mais de perto.

Afinal, uma boa implementação de ERP não começa com a seleção do software, mas com uma visão clara da sua própria empresa.

Erro 1: Não conhecer realmente os processos - mas querer digitalizá-los

Um dos erros mais comuns e, ao mesmo tempo, mais consequentes na introdução de um sistema ERP é cometido surpreendentemente no início do projeto. Muitas empresas decidem a favor de uma nova solução, apesar de não ser completamente claro internamente como funcionam os seus próprios processos em pormenor.

À partida, isto parece contraditório. Afinal de contas, "tudo está a funcionar". As encomendas são processadas, as facturas são emitidas, as entregas são efectuadas. No entanto, um olhar mais atento revela frequentemente uma imagem diferente.

Os processos estabelecidos são muitas vezes apenas aparentemente claros

Em muitas empresas, os processos desenvolveram-se ao longo de muitos anos. Raramente foram concebidos de forma consciente, mas surgiram de necessidades práticas. Foram acrescentados passos individuais, incorporados atalhos, resolvidos casos especiais de forma improvisada. Para o mundo exterior, isto parece estável. No entanto, internamente, existem frequentemente diversas variantes do mesmo processo - dependendo de quem o executa, da experiência disponível ou da situação atual.

Um orçamento talvez seja normalmente elaborado de acordo com um determinado padrão. Na prática, porém, há excepções: clientes especiais, descontos personalizados, alterações a curto prazo. Uma encomenda é "normalmente" processada de uma determinada forma, mas em muitos casos são utilizados métodos alternativos.

Enquanto estes processos funcionarem de forma informal, este facto é quase impercetível. Só quando é necessário um sistema ERP para mapear estes processos é que surge a pressão para os definir claramente.

Porque é que o conhecimento tácito de cada trabalhador é um risco

Outro ponto crítico é o conhecimento tácito. Em quase todas as empresas, há funcionários que têm um "feeling" para determinados processos. Sabem quando algo tem de ser tratado de forma diferente, estão cientes das excepções e conseguem reconhecer correlações que nunca foram documentadas.

Este conhecimento é valioso - mas é também um risco. Isto porque um sistema ERP só pode mapear o que está especificamente descrito. Tudo o que antes era tratado de forma implícita, de repente tem de ser formulado de forma explícita. E é precisamente aqui que surgem as lacunas.

Se os processos centrais existirem apenas na mente dos indivíduos, a introdução de um sistema torna-se rapidamente um trabalho de detetive. São feitas tentativas para reconstruir os processos retrospetivamente, ao mesmo tempo que já estão a ser tomadas decisões para a implementação. Isto leva frequentemente a imprecisões que se tornam visíveis mais tarde durante a operação.

A falha no pensamento: "O software já mapeia isto de alguma forma"

Um erro particularmente comum é acreditar que um sistema ERP mapeará automaticamente os processos existentes "de forma adequada". De acordo com o lema: introduz-se o software, personalizam-se alguns campos - e o resto acontece durante a operação.

Esta expetativa é compreensível, mas não reconhece a verdadeira função de um sistema ERP. Um sistema ERP não é um mecanismo inteligente de equalização de processos pouco claros. Pelo contrário, obriga-o a tomar decisões. Cada passo deve ser definido:

1. O que acontece quando?
2. Quem é responsável?
3. Que dados são necessários?
4. Como são tratadas as excepções?

Se estas questões não forem devidamente esclarecidas com antecedência, surgem inevitavelmente compromissos no sistema. Os campos são utilizados incorretamente, os processos são contornados, são criadas listas adicionais juntamente com o sistema.

O resultado é exatamente o que deve ser evitado: um sistema aparentemente estruturado que tem de ser complementado na prática por soluções individuais.

O que deve acontecer primeiro

Antes da introdução de um sistema ERP, vale a pena fazer uma análise sóbria dos seus próprios processos. Não no sentido de uma descrição teórica ideal, mas com base na prática efectiva.

Não se trata de documentar cada processo até ao mais ínfimo pormenor. Pelo contrário, é crucial desenvolver uma compreensão clara dos processos centrais e reconhecer conscientemente as variantes típicas. As questões importantes podem ser:

1. Como é que uma encomenda passa atualmente pela empresa - desde o primeiro contacto até à faturação?
2. Que desvios ocorrem regularmente?
3. Onde é que ocorrem as dúvidas ou os atrasos?
4. Quem toma que decisões - e com que base?

É particularmente valioso olhar não só para o processo "oficial", mas também para a prática efectiva. Muitas vezes, são os desvios que revelam os conhecimentos decisivos.

É igualmente importante definir claramente as responsabilidades. Um sistema ERP funciona melhor quando é claro quem é responsável por cada secção. Por outro lado, responsabilidades pouco claras conduzem quase inevitavelmente a atrasos e incertezas.

A digitalização precisa de clareza antes da automatização

O ponto-chave pode ser resumido de forma simples: Digitalização reforça o que já existe. Se os processos forem claros e compreensíveis, um sistema ERP pode mapear estas estruturas de forma estável e apoiá-las eficazmente. Se, por outro lado, não forem claros ou forem contraditórios, precisamente estas fraquezas tornam-se visíveis no sistema - e muitas vezes são mesmo reforçadas.

Na prática, isto significa que faz sentido dar um passo atrás antes da implementação técnica. Não para aperfeiçoar tudo, mas para compreender e conceber conscientemente os processos essenciais.

Só nesta base é que um sistema ERP pode desenvolver a sua verdadeira força: Criar ordem, aumentar a transparência e apoiar os processos de forma fiável. Se saltar esta etapa, corre o risco de não trazer ordem à empresa, mas simplesmente de transferir as ambiguidades existentes para uma nova interface - com a diferença de que aí são muito mais difíceis de corrigir.

Erro 2: Tentar automatizar demasiado e demasiado cedo

Quase nenhum outro termo tem uma conotação tão positiva em relação aos sistemas ERP como "automatização". Os processos devem ser mais rápidos, os erros devem ser reduzidos e as actividades manuais devem ser minimizadas. À primeira vista, a ideia de um sistema que faz o máximo possível de forma autónoma em segundo plano parece um progresso lógico.

No entanto, a prática mostra que é precisamente este desejo que conduz a uma complexidade desnecessária em muitos projectos.

Porque é que o desejo de automatização total é compreensível, mas perigoso

A ideia de automatizar o maior número possível de processos desde o início surge normalmente de um impulso compreensível. As empresas querem tornar-se mais eficientes, poupar recursos e libertar-se de tarefas repetitivas.

Além disso, os sistemas ERP modernos e os seus fornecedores transmitem muitas vezes precisamente esta imagem: um sistema totalmente ligado em rede, no qual os dados são registados apenas uma vez e depois processados automaticamente - desde a cotação até à encomenda, passando pela faturação e avaliação. O problema não reside tanto nesta imagem-alvo como na calendarização.

Muitas empresas tentam alcançar esta automatização completa logo na fase de implementação. Isto não tem em conta o facto de que tal estado é normalmente o resultado de um sistema evoluído - e não o seu ponto de partida.

Consequências típicas de uma automatização precipitada

Se os processos forem automatizados antes de serem realmente compreendidos e implementados de forma estável, surgem frequentemente os efeitos que deveriam ser evitados.

Um caso frequente é a criação de cadeias de erros. Por exemplo, se um registo de dados incorreto ou incompleto for processado automaticamente, este erro continua ao longo de várias etapas do processo. O que anteriormente poderia ter sido detectado num ponto, agora só se torna visível no final - muitas vezes com um esforço significativamente maior necessário para a correção.

A isto junta-se uma crescente falta de transparência. Quanto mais passos são automatizados em segundo plano, mais difícil se torna para os funcionários compreenderem como é que um determinado resultado foi alcançado. As decisões deixam de parecer tangíveis e passam a ser vistas como "comportamento do sistema".

A aceitação dentro da empresa também sofre com isso. Os colaboradores que têm a impressão de que os processos já não são compreensíveis ou que já não têm qualquer influência reagem frequentemente com relutância. Em alguns casos, são criadas formas de trabalho paralelas fora do sistema - por exemplo, sob a forma de listas separadas ou notas manuais.

Porque é que primeiro precisa de processos básicos estáveis

A automatização exige sempre uma coisa: clareza. Um processo que não esteja claramente definido pode ser tecnicamente automatizado - mas o resultado continua a não ser fiável. Pequenas ambiguidades ou excepções que ainda eram tratadas intuitivamente no processo manual conduzem rapidamente a problemas no processo automatizado.

Por conseguinte, faz sentido manter deliberadamente os novos processos "simples" no início. A forma básica de um processo deve ser compreensível, estável e entendida pelas pessoas envolvidas antes de ser automatizada.

Esta fase tem menos a ver com a maximização da eficiência e mais com a segurança e a transparência. Os funcionários precisam de compreender como funciona o processo, que dados são necessários e que passos se seguem uns aos outros. Só quando este estado for atingido é que a automatização pode atingir a sua verdadeira força.

A melhor maneira: introdução gradual em vez de automatização completa

Na prática, uma abordagem passo a passo tem-se revelado bem sucedida. Em vez de tentar automatizar totalmente todos os processos desde o início, começa-se por criar uma base estável. Os processos principais são claramente mapeados, as responsabilidades clarificadas e as estruturas de dados definidas. Os processos são deliberadamente concebidos de forma a permanecerem compreensíveis - mesmo que isso signifique que alguns passos sejam inicialmente efectuados manualmente.

O passo seguinte é verificar onde a automatização faz efetivamente sentido. Acontece frequentemente que nem todas as etapas do processo beneficiam igualmente da automatização. Alguns processos podem ser muito bem normalizados, enquanto outros devem manter-se deliberadamente flexíveis.

Esta abordagem tem várias vantagens. Os erros são reconhecidos mais cedo, os ajustamentos podem ser implementados mais facilmente e as pessoas envolvidas desenvolvem uma melhor compreensão dos processos. Também cria uma base sólida sobre a qual podem ser construídas expansões subsequentes.

A longo prazo, esta abordagem conduz frequentemente a um sistema mais estável e, ao mesmo tempo, mais eficiente do que tentar automatizar tudo na perfeição desde o início.

Nem tudo o que é possível é também sensato

Atualmente, as possibilidades técnicas dos sistemas ERP modernos são maiores do que nunca. Interfaces, reservas automáticas, processos em segundo plano, análises em tempo real - muitas coisas podem ser implementadas, muitas vezes com comparativamente pouco esforço.

É precisamente por isso que a contenção no sítio certo é um sinal de experiência. Nem toda a automatização conduz a um melhor resultado. Em alguns casos, um passo manual deliberado faz mais sentido porque permite o controlo ou mantém a flexibilidade. Um sistema deve apoiar as pessoas, não substituí-las completamente.

Aqueles que entendem a automação como uma ferramenta - e não como um fim em si mesmo - criam as condições para um sistema ERP que não só é eficiente, mas também se mantém sustentável a longo prazo.

Erro 3: Selecionar o sistema ERP de forma demasiado rígida - e subestimar as alterações subsequentes

Em muitas empresas, um sistema ERP é selecionado com um objetivo claro: Deve cobrir as necessidades actuais da forma mais completa possível. As funções são comparadas, as listas de controlo são elaboradas, as apresentações são avaliadas. No final, a decisão é tomada a favor da solução que parece ser a mais adequada no momento.

O problema aqui não é tanto a seleção em si, mas a perspetiva. Afinal de contas, um sistema ERP é muitas vezes adquirido para as necessidades actuais - mas na prática tem de ser capaz de suportar as mudanças dos próximos anos.

As empresas estão a mudar mais rapidamente do que muitas especificações sugerem

Quase nenhuma empresa continua a funcionar exatamente como antes durante muito tempo. São criados novos produtos, os serviços mudam, os mercados alteram-se e são acrescentados requisitos legais. As estruturas internas também evoluem: os empregados mudam, as responsabilidades são redistribuídas, os processos são adaptados.

Todas estas alterações têm um impacto direto nas necessidades de um sistema ERP. Este aspeto é frequentemente subestimado na fase de planeamento de um projeto. Elabora-se um caderno de encargos, definem-se as necessidades e pressupõe-se implicitamente que estas se manterão estáveis durante um longo período de tempo. Na realidade, porém, raramente é esse o caso.

Um sistema que hoje se adapta perfeitamente pode atingir os seus limites ao fim de pouco tempo - não porque seja mau, mas porque as condições de enquadramento mudaram.

Surgem quase sempre novos requisitos - e muitas vezes mais depressa do que o previsto

Quem introduz um sistema ERP deve partir do princípio de que as novas necessidades não são a exceção, mas sim a regra. Podem ser pequenas coisas, como análises adicionais ou novos campos. No entanto, é frequente haver ajustamentos mais fundamentais: fluxos de processos alterados, novas interfaces para sistemas externos, diferentes requisitos de recolha de dados ou passos adicionais em fluxos de trabalho existentes.

Isto torna-se particularmente claro quando as empresas crescem ou se realinham estrategicamente. O que anteriormente funcionava numa estrutura gerível, de repente tem de ser aumentado ou adaptado a novas circunstâncias.

Os desenvolvimentos tecnológicos também desempenham um papel importante. Temas como análises automatizadas, painéis de controlo individuais ou a integração de aplicações de IA estão a tornar-se cada vez mais importantes. Os sistemas que não oferecem abertura suficiente para o efeito atingem rapidamente os seus limites.

A ideia errada do "sistema normalizado pronto a utilizar"

Uma ideia generalizada é a de que já existem soluções padrão adequadas para a maioria das necessidades. Esta ideia é apoiada por muitos fornecedores que apresentam os seus sistemas como soluções completas e abrangentes.

Isto pode ser verdade em certos domínios. O software padrão pode mapear muitos processos típicos de forma muito eficiente - especialmente quando os processos são semelhantes em toda a indústria. No entanto, torna-se problemático quando uma empresa se desvia destes padrões.

Cada organização tem as suas próprias particularidades: processos individuais, requisitos especiais, estruturas evoluídas. Estas nem sempre podem ser enquadradas em padrões pré-definidos sem perder eficiência ou clareza.

Se um sistema estiver demasiado ligado a estas normas, existe muitas vezes uma pressão para se adaptar. Os processos já não são concebidos de uma forma que faça sentido para a empresa, mas sim da forma como estão previstos no sistema. Isto pode funcionar a curto prazo, mas conduz frequentemente a perdas por fricção a longo prazo.

Porque é que a flexibilidade não é um luxo, mas sim um fator económico

A capacidade de personalizar um sistema ERP é frequentemente vista como um complemento - algo que é "bom ter" mas não essencial. Na prática, porém, é precisamente esta flexibilidade que pode fazer uma diferença económica significativa.

Um sistema adaptável permite reagir às mudanças sem ter de questionar sempre as decisões fundamentais. Os novos requisitos podem ser integrados passo a passo e os processos existentes podem ser desenvolvidos sem que seja necessário repensar todo o sistema.

Se esta flexibilidade não existir, surgem outros custos. As personalizações só são possíveis através do fornecedor, demoram mais tempo ou são totalmente evitadas por razões de custos. Em muitos casos, são criadas soluções alternativas fora do sistema - por exemplo, sob a forma de ferramentas adicionais ou processos manuais. Esta situação conduz à fragmentação que um sistema ERP deveria efetivamente evitar.

Erros típicos na seleção de software ERP

Expansibilidade personalizada como fator de segurança para o futuro

Um sistema ERP não é uma solução estática, mas uma ferramenta a longo prazo. Acompanha uma empresa durante anos e deve crescer com as suas necessidades.

Por isso, faz sentido considerar a facilidade com que o sistema pode ser expandido ao fazer a seleção. Não se trata apenas das funções existentes, mas também da abertura fundamental da arquitetura.

• Pode adicionar os seus próprios campos, máscaras ou processos ao sistema?
• As interfaces com outras aplicações podem ser integradas sem grande esforço?
• É possível efetuar ajustamentos independentemente do fabricante?

Os sistemas que se baseiam em plataformas abertas ou que podem ser personalizados oferecem frequentemente vantagens significativas neste domínio. Permitem encarar o sistema ERP como uma ferramenta que se adapta à empresa - e não o contrário.

Esta forma de expansibilidade não é um pormenor técnico, mas uma forma de segurança. Garante que o sistema pode continuar a ser utilizado de forma sensata, mesmo que as necessidades mudem.

Se estiver dependente do fornecedor para cada alteração, perde margem de manobra

Um aspeto que está a tornar-se cada vez mais importante neste contexto é a questão da independência. Se todas as personalizações, todas as extensões e todas as interfaces só puderem ser implementadas através do fornecedor original, isso cria uma forte ligação. Isto pode não parecer problemático na fase inicial, mas é frequentemente visto como uma restrição com o passar do tempo.

As mudanças demoram mais tempo, são difíceis de calcular ou são adiadas por razões de custos. As decisões que deveriam ser tomadas dentro da empresa são transferidas para o exterior. Esta situação torna-se particularmente relevante quando entram em jogo novas tecnologias.

Olhando para o futuro: a flexibilidade tornar-se-á ainda mais importante com a IA e os novos requisitos

Os requisitos dos sistemas ERP não se tornarão mais simples nos próximos anos, mas sim mais complexos. Temas como a análise personalizada de dados, o apoio automatizado à decisão e a integração de aplicações de IA estão já a ganhar importância.

Há aqui uma tendência clara: as empresas querem cada vez mais decidir por si próprias como utilizam os seus dados e que ferramentas utilizam. No domínio das soluções locais de IA, em particular, é necessária uma ligação direta aos sistemas existentes - sem desvios através de plataformas externas.

Um sistema ERP que não ofereça abertura suficiente para tal pode rapidamente tornar-se um fator limitativo. Por isso, faz sentido considerar a flexibilidade não como uma reflexão tardia, mas como um critério de seleção central. Um sistema não deve apenas satisfazer os requisitos actuais, mas também oferecer a possibilidade de reagir a desenvolvimentos futuros.

Afinal, não é a perfeição no momento da introdução que determina o sucesso a longo prazo, mas sim a capacidade de adaptação à mudança.

Erro 4: Prestar muito pouca atenção à soberania dos dados e à dependência do sistema

Um sistema ERP gere os dados centrais de uma empresa. Cotações, encomendas, facturas, informações sobre os clientes, análises - tudo isto é reunido e processado de forma estruturada. Por isso, é ainda mais surpreendente que um aspeto crucial seja muitas vezes considerado apenas marginalmente ao fazer uma seleção: a questão de quem tem realmente o controlo sobre estes dados.

Não se trata de um pormenor teórico, mas de uma decisão comercial fundamental.

Porque é que a soberania dos dados é frequentemente abordada demasiado tarde nos projectos de ERP

Na fase inicial de um projeto ERP, outras questões assumem geralmente um papel central: âmbito funcional, facilidade de utilização, custos, tempo de implementação. Estes pontos são importantes e compreensíveis - afinal, os processos quotidianos devem ser suportados da melhor forma possível.

A questão da soberania dos dados, por outro lado, parece inicialmente mais abstrata. Desde que um sistema funcione e produza os resultados desejados, parece ser de importância secundária o local onde os dados estão efetivamente localizados ou a forma como são processados internamente.

Este ponto só se torna mais importante à medida que a utilização aumenta. Coloca-se então a questão da flexibilidade de reação a novos requisitos, da independência em relação a fornecedores externos e das opções existentes para o tratamento posterior dos seus próprios dados. Neste ponto, no entanto, as decisões fundamentais já foram tomadas.

A ilusão conveniente: o mais importante é que seja executado algures na nuvem

As soluções em nuvem tornaram-se cada vez mais importantes nos últimos anos. Prometem uma configuração simples, barreiras de entrada reduzidas e funcionamento sem uma infraestrutura interna. Isto é inicialmente atrativo para muitas empresas.

Em muitos casos, porém, isto resulta numa atitude que poderia ser descrita como comodidade funcional: Desde que o sistema seja acessível de forma fiável e cumpra as tarefas diárias, a estrutura subjacente dificilmente é questionada.

No entanto, esta visão é insuficiente. Um sistema ERP não é uma ferramenta qualquer, mas sim a base de dados central de uma empresa. Quem se baseia apenas no facto de "correr algures" está a renunciar deliberadamente a uma parte do seu controlo.

Isto não tem de ser problemático em princípio - mas deve ser uma decisão consciente e não um efeito secundário.

Riscos de dependência: fidelidade do fornecedor e opções de ação limitadas

A decisão a favor de um determinado sistema é sempre acompanhada de uma forma de compromisso. Este é inevitável e, em muitos casos, também não é crítico. No entanto, torna-se problemático quando este compromisso está associado a uma perda de margem de manobra.

Um exemplo típico é a capacidade limitada de aceder aos seus próprios dados ou de os utilizar noutros contextos. Se as exportações só forem possíveis de forma limitada, se faltarem interfaces ou se estas implicarem custos adicionais, cria-se uma dependência que, no início, é pouco percetível no quotidiano, mas que se torna visível a longo prazo.

As extensões também podem ser afectadas. Se as novas exigências só puderem ser implementadas através do fornecedor, parte da liberdade de decisão empresarial é transferida para o exterior. As adaptações demoram mais tempo, são difíceis de calcular ou são adiadas por razões económicas.

Na prática, isto conduz frequentemente a soluções alternativas. São utilizadas ferramentas adicionais, os dados são mantidos em paralelo ou os processos são organizados fora do sistema. Isto compromete o objetivo real de um sistema ERP - uma base de dados centralizada e coerente.

Porque é que as estruturas controláveis fazem muitas vezes mais sentido a longo prazo

Uma abordagem alternativa é manter conscientemente o controlo dos seus próprios dados dentro da empresa - ou, pelo menos, protegê-los tanto quanto possível. Isto não significa necessariamente prescindir de tecnologias modernas ou depender inteiramente de sistemas locais. Trata-se antes de saber até que ponto a estrutura de dados é aberta e acessível e até que ponto a própria empresa pode dispor dela.

• Os dados podem ser acedidos diretamente?
• É possível exportar em formatos comuns?
• Pode criar as suas próprias análises independentemente do fornecedor?
• É possível definir interfaces de forma independente?

Os sistemas que deixam espaço de manobra neste domínio oferecem uma qualidade de utilização diferente. Permitem encarar o sistema ERP não apenas como uma aplicação, mas como parte da sua própria infraestrutura.

Especialmente em conjunto com soluções personalizáveis, esta forma de controlo conduz a uma maior estabilidade a longo prazo. As alterações podem ser implementadas internamente sem que seja necessário coordenar todos os pormenores. As decisões permanecem onde devem estar - dentro da própria empresa.

A soberania dos dados no contexto das novas tecnologias e da IA

Um aspeto que continuará a ganhar importância nos próximos anos é a utilização de dados em ligação com as novas tecnologias. No domínio da inteligência artificial, em particular, já está a tornar-se evidente que as empresas querem cada vez mais analisar os seus próprios dados e integrá-los em processos individuais. Isto envolve não só serviços externos, mas também soluções locais que funcionam diretamente com os sistemas existentes.

Isto levanta a questão da soberania dos dados de uma forma intensificada. Se os dados só estiverem acessíveis de forma limitada ou só puderem ser processados através de plataformas externas, muitas destas abordagens são quase impossíveis de implementar. As análises individuais, os modelos internos ou a automatização específica exigem que os dados estejam livremente disponíveis e possam ser utilizados de forma estruturada.

Um sistema ERP que restringe estas possibilidades desde o início pode, portanto, tornar-se um fator limitativo - independentemente da sua eficiência noutras áreas.

Um sistema ERP deve ser suficientemente aberto amanhã

A introdução de um sistema ERP não é uma decisão a curto prazo. Ela molda a forma como uma empresa trabalha durante muitos anos. Por isso, é ainda mais importante considerar não apenas os requisitos actuais, mas também os efeitos a longo prazo. A soberania dos dados e a abertura do sistema não são apenas princípios abstractos, mas pré-requisitos concretos para a capacidade de ação empresarial.

Quem presta atenção ao local e à forma como os seus próprios dados são geridos numa fase inicial cria espaço de manobra para desenvolvimentos futuros. As adaptações podem ser feitas de forma independente, as novas tecnologias podem ser integradas e a empresa continua em posição de desenvolver ativamente os seus sistemas. Quem negligencia este aspeto, por outro lado, muitas vezes só se apercebe, em retrospetiva, de como as suas opções se tornaram limitadas.

Um sistema ERP deve, portanto, não só funcionar de forma fiável, mas também oferecer a liberdade de se desenvolver mais. Afinal de contas, não se trata apenas de gerir dados - trata-se de poder utilizá-los de forma sensata e independente.

Erros típicos na adaptação de um software ERP aos seus próprios processos

Erro 5: Externalizar a responsabilidade a fornecedores de software ou de serviços

Um sistema ERP é frequentemente introduzido com a expetativa de que irá criar ordem, estruturar processos e apoiar decisões. Esta expetativa é basicamente justificada. No entanto, torna-se problemática quando daí decorre um pressuposto implícito: que parte da responsabilidade empresarial é "assumida" ao mesmo tempo.

Na prática, tem sido demonstrado repetidamente que é precisamente aqui que ocorre um erro fundamental.

Porque é que os projectos ERP são sempre também questões de gestão

A introdução de um sistema ERP não afecta apenas os processos, mas também as responsabilidades, as prioridades e as decisões. Trata-se de definir a forma como uma empresa funciona - e quem é responsável por ela.

Estas questões não podem ser delegadas. Um projeto ERP requer orientações claras por parte da direção da empresa ou, pelo menos, por parte de um nível responsável que acompanhe o panorama geral. Sem esta orientação, rapidamente se cria uma situação em que os departamentos individuais introduzem as suas próprias ideias sem que estas sejam reunidas para formar um processo global coerente.

O resultado são soluções de compromisso que podem funcionar a curto prazo, mas que conduzem a perdas por fricção a longo prazo. Um sistema pode fornecer uma estrutura - mas não pode decidir qual a estrutura que faz sentido para uma empresa.

O erro de delegar decisões "no software" ou em consultores externos

Um reflexo comum é externalizar as decisões tanto quanto possível. Ou se parte do princípio de que o sistema escolhido já fornece uma estrutura "testada e comprovada", ou se confia em consultores externos para desenvolver as soluções corretas. Ambos podem fazer sentido em determinadas situações, mas tornam-se problemáticos se se tornarem a atitude básica.

O software apenas representa suposições. Mesmo as chamadas melhores práticas são, em última análise, modelos generalizados que podem ser adequados para muitas empresas - mas não necessariamente para a sua. Se adotar estas estruturas sem as verificar, corre o risco de a empresa se adaptar gradualmente ao sistema, em vez de o sistema se adaptar às suas próprias necessidades.

A situação é semelhante com os prestadores de serviços externos. Estes trazem experiência, conhecem os processos típicos e podem dar um contributo valioso. No entanto, não fazem parte da empresa. Não assumem a responsabilidade a longo prazo pelas decisões, mas acompanham a sua implementação.

Se as decisões-chave forem completamente entregues a organismos externos, cria-se uma lacuna. As decisões são tomadas sem estarem verdadeiramente ancoradas internamente. Este facto conduz frequentemente a incertezas ou resistências posteriores.

Por que razão é necessário reunir os serviços especializados, a gestão e a execução

Um projeto ERP bem sucedido é criado quando se reúnem diferentes perspectivas. Os departamentos especializados estão familiarizados com os processos diários e sabem onde surgem os problemas. A gestão tem uma visão geral dos objectivos estratégicos e das condições económicas. A implementação técnica assegura que estes requisitos são traduzidos num sistema funcional.

Se um destes níveis estiver em falta ou se se afastar demasiado, surge um desequilíbrio. Um sistema construído exclusivamente de uma perspetiva técnica pode ser inadequado de um ponto de vista funcional. Inversamente, os requisitos tecnicamente sensatos podem falhar se não forem corretamente implementados do ponto de vista técnico. E sem uma classificação estratégica, a definição de prioridades é muitas vezes inexistente.

Por conseguinte, é fundamental estabelecer uma ligação consciente entre estes níveis. As decisões devem ser tomadas de forma transparente, as responsabilidades devem ser claramente definidas e a comunicação entre os intervenientes deve ser estruturada.

Um sistema ERP não é um produto que é simplesmente introduzido. É o resultado de uma compreensão partilhada da forma como uma empresa pretende trabalhar.

A responsabilidade interna como condição prévia para o sucesso a longo prazo

Um fator-chave de sucesso é o facto de a responsabilidade pelo sistema ERP permanecer ancorada na própria empresa. Isto não significa que tudo tenha de ser implementado internamente. O apoio externo pode ser útil e é muitas vezes necessário. No entanto, é crucial que as decisões fundamentais sejam tomadas e apoiadas dentro da empresa.

Se as responsabilidades forem claramente definidas, cria-se uma qualidade diferente no decurso do projeto. As decisões são tomadas de forma mais consciente, os ajustamentos podem ser feitos mais rapidamente e o sistema é visto como parte da própria estrutura da empresa - e não como uma solução externa que "de alguma forma funciona".

Esta diferença também é claramente evidente após a implementação. Um sistema ERP não é um projeto acabado, mas continua a desenvolver-se. Surgem novas necessidades, os processos são adaptados, tornam-se necessárias extensões.

Se a responsabilidade por isso existir internamente, o sistema mantém-se flexível. Sem esta base, cada mudança torna-se um projeto por si só - com o esforço correspondente.

Um sistema pode apoiar - mas não substituir - a ambiguidade

No final, este erro pode ser reduzido a um simples ponto: Um sistema ERP pode fazer muito, mas não pode compensar as ambiguidades fundamentais da empresa.

Pode mapear processos, estruturar dados e apoiar fluxos de trabalho. No entanto, não pode decidir que processos fazem sentido, que prioridades devem ser estabelecidas ou como a responsabilidade é distribuída.

Quem espera que um sistema "resolva" estas questões ficará inevitavelmente desiludido. Um bom projeto ERP não começa, portanto, com a questão do software a utilizar, mas sim com a clarificação das estruturas próprias da empresa. Só quando esta base estiver estabelecida é que um sistema pode jogar com os seus pontos fortes.

E é precisamente esta a diferença entre uma introdução que apenas funciona - e uma que é sustentável a longo prazo.

O que aprendi em 30 anos de desenvolvimento de ERP

Quando se trabalha com sistemas ERP durante um longo período de tempo, a visão sobre estes temas muda inevitavelmente. O que, no início, ainda é altamente técnico - funções, máscaras, estruturas de dados - passa para segundo plano com o tempo. Em vez disso, surgem outras questões:

• Como é que as empresas funcionam realmente?
• O que funciona na vida quotidiana - e o que não funciona?
• E acima de tudo: o que determina realmente o sucesso de um projeto?

Depois de muitos anos no terreno, uma coisa pode ser dita com toda a clareza: raramente são os sistemas que determinam o sucesso ou o fracasso. São as pessoas, os processos - e a forma como são geridos.

Compreender os processos primeiro - não corrigi-los depois

Uma das conclusões mais importantes é também uma das mais simples: se não compreender os processos, não conseguirá digitalizá-los de forma significativa. Isto parece óbvio, mas é surpreendentemente ignorado na prática. Muitos projectos começam com a questão de saber quais as funções necessárias, em vez de esclarecerem como são realmente os processos na empresa. No entanto, é precisamente aqui que reside a chave.

Tem sido demonstrado repetidamente que a forma mais limpa é abordar os processos individuais passo a passo. Não de cima para baixo, mas de baixo para cima. Por isso, não comece com grandes conceitos, mas com os processos concretos da vida quotidiana.

• Como é criada uma encomenda?
• Como é que é processado posteriormente?
• Onde é que surgem as dúvidas?
• Quais são as excepções?

Se responder corretamente a estas perguntas, criará uma base sobre a qual um sistema ERP pode ser construído de forma sensata. Tudo o resto conduzirá, mais cedo ou mais tarde, a correcções.

Trabalhar com uma estrutura existente - e fazer adições específicas

Outro ponto que se comprovou na prática: Muitas vezes, é muito mais eficiente trabalhar com uma estrutura existente e bem pensada do que começar do zero.

Esta é precisamente uma das vantagens do Soluções como gFM-Business. Os processos básicos já estão implementados. Não é necessário pensar na estruturação de um orçamento, de uma encomenda ou de uma fatura de raiz para cada projeto. Estes processos já estão em vigor e já deram provas em muitos casos.

No entanto, isto não significa que tenha de adotar estas estruturas sem alterações. O passo decisivo é tomar os processos existentes como ponto de partida - e depois verificar especificamente onde existem desvios na sua própria empresa.

• Onde é que a norma se encaixa?
• Onde se verificam as lacunas?
• Que caraterísticas especiais devem ser acrescentadas?

O resultado não é um sistema rígido, mas uma solução personalizada que se baseia em princípios comprovados e tem em conta os requisitos individuais. Esta abordagem é geralmente muito mais rápida e estável do que tentar desenvolver tudo de raiz.

A abertura como condição prévia para uma personalização significativa

Um sistema só pode ser personalizado de forma significativa se também permitir essa personalização. Precisamente por esta razão, concebi deliberadamente a gFM Business como uma solução aberta. As empresas devem poder personalizar totalmente o software de acordo com os seus próprios processos - e não ter de adaptar os seus processos a especificações rígidas.

Esta abertura não é um pormenor técnico, mas uma decisão fundamental. Porque, na prática, ficou demonstrado repetidamente que não há duas empresas que trabalhem exatamente da mesma forma. Mesmo em sectores comparáveis, existem diferenças que não podem ser significativamente enquadradas numa grelha rígida.

Uma estrutura aberta permite mapear estas diferenças sem pôr em causa a estabilidade do sistema. Cria a base para garantir que um sistema ERP possa não só ser introduzido, mas também continuar a ser desenvolvido ao longo dos anos.

O fator decisivo: a cooperação do lado do cliente

Por muito importantes que sejam a tecnologia e a estrutura, o sucesso de um projeto ERP depende, em última análise, em grande medida, da cooperação do lado do cliente.
Este facto é frequentemente subestimado. Um sistema ERP não pode ser "introduzido" como um produto acabado. Ele é criado através da colaboração. E isso requer tempo, atenção e vontade da empresa de examinar os seus próprios processos.

O ideal é que haja uma responsabilidade clara. Ou o próprio empresário ou uma pessoa responsável na empresa que se ocupe ativamente do projeto. Este papel não pode ser desempenhado à margem.

A questão dos testes também é frequentemente mal avaliada. Por muito bem que um sistema seja implementado tecnicamente, se não for suficientemente testado na utilização quotidiana, surgirão problemas mais tarde. Estes testes devem ser efectuados o mais próximo possível da utilização real. Aqueles que se baseiam exclusivamente na implementação externa esquecem-se frequentemente de pormenores cruciais.

Isto não significa que tudo tenha de ser feito internamente. Mas sem um envolvimento ativo, um projeto ERP raramente se torna uma solução verdadeiramente adequada.

Compreender o processo não é um dado adquirido - mas é crucial

Outra experiência de muitos anos de prática: compreender os processos não é uma coisa óbvia. Nem toda a gente tem a mesma capacidade de compreender os processos de uma forma estruturada, de reconhecer as ligações e de os colocar numa forma clara. Isto não é surpreendente - afinal, trata-se de uma forma de pensar bastante abstrata que nem sempre é necessária na vida quotidiana.

Ao mesmo tempo, é precisamente esta compreensão que constitui um pré-requisito essencial para projectos ERP bem sucedidos. Por esta razão, também me ocupei mais intensamente deste tema e, entre outras coisas, publiquei o livro O livro de bases de dados com uma diferença escrito. Trata-se menos de tecnologia no sentido restrito e mais de compreender processos, estruturas e inter-relações.

Afinal, um sistema ERP nada mais é do que o mapeamento de processos de forma estruturada.

A experiência não substitui a diligência - mas mostra padrões

Quem trabalha nesta área há tempo suficiente, reconhece rapidamente certos padrões. É possível ver onde os projectos param, onde ocorrem os erros típicos e quais as abordagens que se revelaram bem sucedidas.

No entanto, cada implementação é individual. A experiência pode ajudar a reconhecer e a evitar problemas típicos numa fase inicial. No entanto, não substitui a diligência necessária num projeto específico. Cada empresa tem os seus próprios requisitos, os seus próprios processos e a sua própria forma de pensar.

É por isso que o princípio mais importante permanece inalterado apesar de toda a nossa experiência: Um sistema ERP funciona melhor quando é orientado para os processos reais - e não para ideias abstractas de como estes processos deveriam ser idealmente. Quem segue esta abordagem cria uma base sólida. E é exatamente isso que importa no final.

Implementação do ERP com um sentido de proporção em vez de euforia tecnológica

A introdução de um sistema ERP é um passo significativo para muitas empresas. Promete estrutura, eficiência e uma melhor base para a tomada de decisões. Ao mesmo tempo, a experiência prática mostra que é precisamente aqui que surgem os maiores mal-entendidos.

Os cinco erros descritos não são excepções, mas sim padrões recorrentes. Os processos não são suficientemente controlados, a automatização é impulsionada demasiado cedo, os sistemas são selecionados de forma demasiado rígida, a soberania dos dados da própria empresa é subestimada - e, por último, mas não menos importante, a responsabilidade é demasiadas vezes externalizada.

Todos estes problemas têm uma coisa em comum: não resultam de falta de cuidado, mas de falsas suposições. O ERP é muitas vezes visto como uma solução técnica, embora na realidade se trate de outra coisa - clareza dentro da empresa. Processos limpos, decisões compreensíveis e uma estrutura que não só funciona hoje, mas que também será sustentável amanhã.

Numa altura em que temas como interfaces, análises personalizadas e inteligência artificial estão a tornar-se cada vez mais importantes, torna-se evidente a importância da flexibilidade e da soberania dos dados. Os sistemas devem ser não só estáveis, mas também suficientemente abertos para se poderem desenvolver.

Também foi demonstrado repetidamente que o sucesso de um projeto ERP depende, em grande medida, da cooperação dentro da própria empresa. Quem dedica tempo a compreender os processos, a definir claramente as responsabilidades e a apoiar ativamente a implementação, cria um ponto de partida completamente diferente daquele que delega o projeto tanto quanto possível.

Em última análise, um sistema ERP não é um fim em si mesmo. É uma ferramenta. E, como acontece com qualquer ferramenta, não é apenas a sua qualidade que determina o resultado, mas também a forma como é utilizada. Aqueles que dedicam tempo a compreender realmente os seus próprios processos, que procedem passo a passo e prestam conscientemente atenção à personalização e independência não só criarão ordem com um sistema ERP, como também assegurarão a sua própria agilidade empresarial a longo prazo.

---

Perguntas mais frequentes

1. Que sinais típicos indicam que a nossa empresa ainda não está preparada para a introdução de um sistema ERP?
   Se os processos não estiverem claramente definidos, se as responsabilidades mudarem frequentemente ou se muitos processos funcionarem apenas "de alguma forma", este é um sinal claro. Mesmo que a informação importante esteja retida em cabeças individuais ou seja mantida em paralelo em várias listas de Excel, falta normalmente a base necessária. Um sistema ERP não pode organizar automaticamente tais estruturas, mas muitas vezes apenas torna visíveis as ambiguidades existentes.
2. Com que pormenor é que os nossos processos devem ser documentados antes da implementação de um ERP?
   Não se trata de escrever todos os passos até ao mais ínfimo pormenor. É crucial uma compreensão clara dos processos centrais e das suas variantes típicas. É importante que seja claro como um processo decorre na empresa do início ao fim e onde ocorrem regularmente desvios.
3. Faz sentido otimizar completamente os processos existentes antes de introduzir o ERP?
   Uma otimização completa antecipada raramente é realista e muitas vezes não é necessária. É mais importante compreender os processos e reconhecer os pontos fracos óbvios. Muitas melhorias só surgem na interação com o sistema quando os processos se tornam mais transparentes.
4. Porque é que é problemático automatizar demasiado e demasiado cedo?
   Porque a automatização reforça os processos existentes. Se um processo ainda não é claro ou está sujeito a erros, é exatamente isso que é transmitido automaticamente. Isto resulta frequentemente em cadeias de erros que são mais difíceis de reconhecer e corrigir do que nos processos manuais.
5. Como é que reconheço os processos que são adequados para automatização?
   Os processos que são estáveis, recorrentes e claramente definidos são geralmente bem adequados. No entanto, se existirem muitas excepções ou se as decisões dependerem fortemente de juízos individuais, deve ser cauteloso e concentrar-se inicialmente na transparência e não na automatização.
6. A introdução gradual de um sistema ERP é realmente melhor do que uma mudança completa?
   Na maior parte dos casos, sim. Uma introdução gradual permite ganhar experiência, reconhecer os erros numa fase inicial e efetuar ajustamentos. Uma mudança completa, por outro lado, comporta o risco de os problemas só se manifestarem durante o funcionamento.
7. Qual é a importância da flexibilidade de um sistema ERP quando se faz uma seleção?
   É fundamental. As necessidades mudam quase sempre com o tempo. Um sistema difícil de adaptar pode rapidamente tornar-se um obstáculo. A flexibilidade não é, portanto, um complemento, mas um requisito básico para a usabilidade a longo prazo.
8. Porque é que as soluções padrão não são muitas vezes suficientes?
   As soluções standard cobrem bem os processos típicos, mas atingem os seus limites quando se trata de requisitos individuais. Todas as empresas têm caraterísticas especiais que nem sempre podem ser integradas em estruturas predefinidas. Sem opções de personalização, surgem frequentemente soluções de contorno.
9. O que significa realmente a soberania dos dados no contexto de um sistema ERP?
   A soberania dos dados significa que uma empresa mantém o controlo sobre os seus próprios dados. Isto significa que os dados devem ser acessíveis, exportáveis e processáveis de forma independente. Trata-se de poder decidir por si próprio como e onde a sua própria informação é utilizada.
10. Quais são os riscos das soluções ERP puramente na nuvem?
    As soluções na nuvem são cómodas e, muitas vezes, estão rapidamente prontas a utilizar, mas podem dar origem a dependências. Se os dados só puderem ser exportados de forma limitada ou se os ajustamentos só puderem ser feitos através do fornecedor, a sua própria liberdade de ação é restringida.
11. A nuvem é fundamentalmente problemática ou existem áreas de aplicação sensatas?
    A nuvem não é fundamentalmente problemática. Pode fazer sentido em muitos casos, especialmente com requisitos normalizados. O fator decisivo é conhecer as condições de enquadramento e decidir conscientemente qual o controlo que se pretende ceder e qual o que se pretende manter.
12. Porque é que a importância da soberania dos dados é frequentemente subestimada?
    Porque, à partida, não parece desempenhar um papel na vida quotidiana. Desde que o sistema funcione, a estrutura subjacente dificilmente é questionada. Só quando se tornam necessários ajustamentos ou extensões é que se torna claro o quão limitadas são as nossas próprias opções.
13. Que papel desempenhará a inteligência artificial nos sistemas ERP no futuro?
    A IA tornar-se-á cada vez mais importante, especialmente nos domínios da análise, da automatização e do apoio à decisão. No entanto, a condição prévia para isso é que os dados sejam estruturados e acessíveis. Os sistemas com disponibilidade limitada de dados podem rapidamente atingir os seus limites neste domínio.
14. Porque é que a colaboração do lado do cliente é tão importante num projeto ERP?
    Porque um sistema ERP mapeia os processos da empresa. Sem o envolvimento ativo de quem conhece esses processos, não é possível criar um sistema adequado. Os prestadores de serviços externos podem dar apoio, mas não podem substituir a perspetiva interna.
15. Quem na empresa deve assumir a responsabilidade por um projeto ERP?
    Idealmente, uma pessoa ou uma pequena equipa com autoridade suficiente para tomar decisões e com uma visão geral dos processos. Este papel deve ser claramente definido e não deve ser desempenhado apenas de forma ocasional.
16. Porque é que os testes efectuados pelos próprios clientes são tão importantes?
    Porque só os utilizadores reais podem avaliar se um sistema funciona na utilização quotidiana. Os testes externos cobrem os aspectos técnicos, mas não as subtilezas práticas que são cruciais na utilização quotidiana.
17. O que é que significa abordar os processos "a partir de baixo"?
    Isto significa não começar a análise com conceitos abstractos, mas com os processos concretos da vida quotidiana. Por outras palavras, com os passos individuais que são efetivamente executados e não com ideais teóricos.
18. Como é que uma estrutura ERP existente pode facilitar a introdução?
    Uma estrutura existente oferece um ponto de partida testado e comprovado. Não tem de desenvolver tudo de raiz, mas pode concentrar-se em acrescentar as suas próprias caraterísticas especiais. Isto poupa tempo e reduz as fontes de erro.
19. Como reconhecer se um projeto ERP foi bem sucedido?
    Não pelo facto de todas as funções terem sido implementadas, mas pelo facto de os processos na empresa se terem tornado efetivamente mais claros, mais estáveis e mais eficientes. Um sistema ERP bem sucedido é aceite no dia a dia e apoia o trabalho em vez de o dificultar.