Dicas Para Avaliar Um Erp

Dicas para Avaliação de uma Solução ERP

Paulo Henrique Pinhão cel.: 21-9-91101649 mailto:[email protected]

• Requerimentos de Negócio:

o Identifique os requerimentos realmente relevantes e importantes, estabelecendo pesos diferenciados a partir das estratégias de negócio. Esses requerimentos de negócio devem ser prioritariamente dirigidos aos provedores como questionamentos. O uso de RFPs e RFQs não é a melhor de avaliar a aderência desses requerimentos, procure, também, a interação direta com o produto, com o provedor e com usuários experientes.

o Os requerimentos não devem ser deduzidos somente a partir das necessidades atendidas pelos sistemas atuais. É importante gerar requerimentos a partir do entendimento das dificuldades atuais e das necessidades ainda não atendidas (ex. controles manuais, retrabalhos, etc.), tendo como base o processo de negócio.

o A forma como a solução atende ao requerimento deve influenciar a avaliação. Ou seja, a existência da informação, como input e/ou output, é a premissa básica da aderência, mas é necessário avaliar o controle que o sistema promove com essas informações. Essa avaliação também esta relacionada à flexibilidade com que esses controles podem ser configurados, e o quanto eles podem ser pró-ativos em relação aos usuários. O sistema precisa conduzir o usuário.

� Essa capacidade de conduzir o usuário dentro de um fluxo de trabalho é suportada pela tecnologia de Workflow que deve estar presente na solução ERP. É importante avaliar os recursos de Workflow pelo enfoque do gestor do fluxo de trabalho. Ou seja, como ele consegue interagir na configuração, tratar formulários, administrar alçadas, padronizar notificações e monitorar esses fluxos e suas métricas.

o Procure identificar novos requerimentos a partir da interação com o provedor e com outros usuários da solução ERP. É preciso estar aberto ao entendimento de novas maneiras de fazer o mesmo controle, assim como suas vantagens e desvantagens.

o Os requerimentos fiscais e legais são mutantes em nosso país, assim como se diferenciam conforme a região e o tipo de produto ou serviço. Por isso, é preciso avaliá-los de forma mais minuciosa junto aos provedores. Os provedores globais encontram grande dificuldade na manutenção dessas regras locais, sendo assim, eles apresentam um tempo de resposta maior em termos de reação às mudanças.

� Avalie o custo x benefício de integrar soluções específicas (nacionais) para atendimento aos requerimentos fiscais e legais. Alguns provedores de ERP já adotam essa estratégia.

• Produtividade operacional e facilidade de uso:

o É importante observar a forma intuitiva e ágil da navegação entre campos,

telas e menus. o É preciso avaliar as mensagens de interação do sistema (on-line, por e-mail,

SMS, etc).



o Avalie a qualidade dos Helps On-line e dos Wizards pertinentes. o Quando a apresentação do produto é conduzida e liderada exclusivamente

pelo provedor, não é possível ter uma adequada avaliação desses aspectos. O certo, nesse caso, seria prever uma interação prática, onde alguns de seus usuários “chave”, ou analistas, possam fazer algumas transações com base num roteiro (script) pré-estabelecido, contando com o apoio próximo do provedor.

• “Input” e “Output”:

o Avalie a entrada de dados nos seguintes aspectos;

� Garantia da integridade: • Recursos de consistência on-line e off-line (Ex. input via

planilha) • Segmentação de cadastros (conforme o perfil e estrutura

organizacional) • Manutenção do log de acessos (rastreabilidade)

� Facilidade de Personalização da Interface: • Adequação da terminologia (nomes de campos e menus) • Inserção de novos campos e respectivas consistências • Possibilidade de ajustes no look&feel

o Entenda os recursos existentes para extração de informações e avalie o grau de independência que eles proporcionam aos usuários (em relação à área de TI).

� Ex. Gerador de Relatórios (Queries), exportação para planilha, etc... o Avalie a capacidade de apuração de métricas e indicadores que apóiem os

gestores dos processos de negócio. � É cada vez mais importante ter essa apuração sendo feita em tempo

real (ou quase real), pois a gestão dos processos demanda ciclos decisórios com tempos de resposta cada vez menores.

� A apuração de indicadores, em sua grande maioria, necessita buscar informações em bases funcionais distintas. As soluções com maior fragmentação do modelo de dados, irão apresentar maiores dificuldades (menor performance) em fazer essa consolidação dinâmica.

• Interação “Self-service”, B2B e B2C:

o Mesmo dentro de uma amplitude administrativa e financeira percebemos

uma crescente demanda da solução ERP na interação com usuários externos ao escopo da aplicação (ex. clientes, fornecedores, auditores, funcionários de ouras áreas, etc).

o É importante avaliar como a solução ERP utiliza a web para endereçar essas necessidades de interação externa:

� Ex. Status do pedido, posição de títulos, informes financeiros, limites de crédito, etc.



• A Implantação do ERP:

o A maior parte do esforço de implantação de uma solução ERP está

relacionada à tradução dos requerimentos de negócio em parametrização do aplicativo. Esse trabalho inclui esforços intensivos de teste e é chamado de configuração. Durante a implantação, a configuração é feita de forma evolutiva e cíclica.

o O projeto de implantação do ERP deve sempre considerar as seguintes premissas:

� Não prever esforços de customização. Essa palavra “customização” deve ser banida do escopo do projeto. Ela deve ser substituída pelas palavras “integração” e “componentização”. Os “gaps” funcionais da solução a ser implantada deverão ser disponibilizados através da integração de componentes pré-existentes ou pela construção de serviços (web services) que venham a ser integrados ao ERP, através de tecnologia baseada em SOA (Service Oriented Architecture).

� O provedor de ERP deverá disponibilizar uma alternativa de solução pré-configurada. Ou seja, essa alternativa deverá assumir alguns requerimentos e sua respectiva parametrização. Isso reduz os esforços e os custos de implantação, mas por outro lado, “engessa” a aderência personalizada dos requerimentos de negócio.

• Para poder tomar a decisão pela pré-configuração, as questões dirigidas aos provedores deverão validar não somente a aderência funcional do produto, como também a aderência ao “template” pré-configurado pelo provedor.

� Normalmente o provedor de solução ERP indica a empresa de consultoria habilitada ao projeto de implantação. Para avaliar essa consultoria, analise os currículos de seus consultores, acesse alguns clientes de projetos anteriores e, principalmente, entenda a experiência dos gerentes de projetos na implantação do ERP (estrutura do PMO).

• Peça com que a consultoria apresente a metodologia de implantação e a de gerenciamento.

• Certificações PMP são bem vindas.

• O Provedor da Solução:

o Avaliação do Provedor da solução é tão importante quanto a avaliação de funcionalidades.

o Alguns pontos de atenção: � Pondere sobre o nível de serviço prestado pelo provedor em termos

de suporte e manutenção à solução ERP. • A maneira mais adequada de obter essas informações é

acessando diretamente a base instalada e as associações de empresas usuárias do ERP.



� O provedor possui estratégia orientada ao seu segmento de negócio? A solução possui funcionalidades e/ou pré-configuração dirigida especificamente ao seu segmento?

• É preciso entender se o provedor irá evoluir a solução de, propiciando uma parceria estratégica de longo prazo com a comunidade.

� É importante avaliar a qualidade dos recursos de educação (presencial e a distância) e certificações oferecidas pelo Provedor, tendo em vista a capacitação da equipe de implantação e dos usuários finais.

� Dê preferência aos provedores que ofereçam serviços (SaaS) em substituição ao modelo tradicional de licenciamento. Além de propiciar uma oferta mais competitiva em termos de TCO, esses provedores tendem a oferecer um atendimento mais qualificado e próximo.

� O tamanho da base instalada indica a solidez da solução, mas não garante a sua continuidade e a do seu provedor.

� Com a constatação de que os provedores de ERP não têm vocação para a prestação de serviços, começam a surgir os Centros de Solução que buscam preencher essa lacuna de mercado, através de serviços especializados de HelpDesk, Administração remota de ambientes, Fábrica de componentes e Orientação aos processos de um segmento específico.

B2BB2B

InteligInteligêência ncia

dede

NegNegóócioscios

AplicaAplicaçõçõeses

AnalAnalííticasticas


dede

RetaguardaRetaguarda


CrCrííticasticas

Camada deCamada de

IntegraIntegraçãçãoo

AplicaAplicaçõções es

ExistentesExistentes

Fo

rne

ce

do

res

Fo

rnece

do

res

Dis

trib

ui

Dis

trib

ui ç

ãç

ãoo

Co

mp

ras

Co

mp

ras

Pro

du

Pro

du

çã

çãoo

Fre

tes

Fre

tes

Ve

nd

as

Ve

nd

as

Fo

rne

ce

do

res

Fo

rnece

do

res

Dis

trib

ui

Dis

trib

ui ç

ãç

ãoo

Co

mp

ras

Co

mp

ras

Pro

du

Pro

du

çã

çãoo

Fre

tes

Fre

tes

Ve

nd

as

Ve

nd

as

Co

ntr

ato

sC

on

tra

tos

PPóó

ss-- V

en

da

Ve

nd

a

Ma

nu

ten

Ma

nu

ten

çã

çãoo

Or

Or çç

am

en

tos

am

en

tos

CR

MC

RM

Fin

an

ce

iro

Fin

an

ce

iro

Co

ntr

ato

sC

on

tra

tos

PPóó

ss-- V

en

da

Ve

nd

a

Ma

nu

ten

Ma

nu

ten

çã

çãoo

Or

Or çç

am

en

tos

am

en

tos

CR

MC

RM

Fin

an

ce

iro

Fin

an

ce

iro

Ambientes Legados (HeterogAmbientes Legados (Heterogêêneos)neos)

Hub Hub de Integrade Integraçãçãoo–– BPM/SOABPM/SOA

InformaInformaçõções Gerenciaises Gerenciais

Indicadores de PerformanceIndicadores de Performance

Portal Portal –– ColaboraColaboraçãção o –– Single SignSingle Sign--onon

Amplitude do Escopo de SoluAmplitude do Escopo de Soluçãçãoo



• A Tecnologia embarcada:

o Opte por soluções web baseadas em 3 camadas (no mínimo) onde a maior

parte da lógica funcional seja tratada como serviços aplicativos (application server)

o A arquitetura da camada “Cliente” deve buscar o equilíbrio entre a “leveza” transacional e a qualidade da interface com o usuário.

o Opte por arquiteturas que privilegiem e otimizem a performance e a integridade da comunicação de dados entre o aplicativo e o SGBD.

o Procure avaliar o nível de fragmentação do modelo de dados. o Evite soluções suportadas por metaframe. o Dê preferência às soluções baseadas em plataforma de desenvolvimento

aberta, orientada a objetos e de uso em larga escala pela comunidade desenvolvedora (fábricas de software).

o A compatibilidade com plataformas “OpenSource” é um aspecto relevante a ser considerado (Linux, Jboss, etc). Já existem opções de ERP OpenSource no mercado (Compiere e ERP5).

o Considere arquiteturas componentizadas (modularizadas) que já façam uso de um “middleware” de integração suportado por padrões abertos (XML, SOAP, etc) e adaptadores prontos.

o Privilegie as soluções suportadas por tecnologia workflow ou BPM. o Algumas soluções já trazem em seu bojo, ferramentas para estruturação e

personalização de portais colaborativos e “workplaces” comunitários. Veja isso como um diferencial.

o A solução deverá ser suportada por um núcleo de administração de acessos / perfis, controle de ambientes (setups, atualizações, etc), distribuição de cargas e prioridades (serviços concorrentes), administração dos BD e do Archiving (limpeza lógica dos dados históricos).

Technology

Dicas Para Avaliar Um Erp