Implementação de um Sistema ERP numa PME

Implementação de um Sistema Integrado de Gestão na Rall
A empresa estudada, e que serviu de suporte ao presente trabalho, é uma empresa do sector metalomecânico, agindo no mercado do mobiliário metálico para escritório. Tem sede em Águeda, distrito de Aveiro, e a sua designação é Rall. Presentemente é dirigida pela segunda geração de gestores e este facto é, só por si, factor diferenciador no panorama da região e do sector. Assim, o Dr. Victor Almeida, um gestor jovem e moderno, aberto à mudança e à inovação, no momento em que se tornou estratégico realizar um ajuste interno de processos e de organização, considerou criteriosamente a possibilidade de investir num Sistema de Informação capaz de permitir à empresa, entrar no século XXI com uma organização interna madura, dialogante e célere no bom serviço aos seus clientes. O ERP SAP R/3 foi o pacote de software escolhido, pela Rall, para organizar internamente a empresa e a projectar para o exterior.
Este capítulo pretende descrever o processo de implementação de um sistema integrado de gestão na empresa Rall. Assim, inicialmente apresenta-se uma caracterização da referida empresa que abrange o processo de produção e, fundamentalmente, descreve-se o histórico dos sistemas de informação na Rall, antes da implementação do R/3, mostrando como a política dos SI’s era informal e casuística. No resto do capítulo, detalha-se o processo de implementação, referindo a preparação da organização para a mudança (pressupostos, objectivos e metas a alcançar no projecto), o Projecto SAP (estrutura da equipa, metodologia de implementação, fases do projecto, padrões e procedimentos da gestão do projecto) e o desenvolvimento e parametrização (incluindo o desenho de layouts e algum desenvolvimento específico). No que concerne a implementação explanam-se as 5 fases, incluindo as tarefas mais importantes de cada uma, e também se refere, de forma breve, o plano de contingência. Nas conclusões resumem-se as alterações decorrentes dos novos processos, os aspectos negativos e positivos durante a implementação, bem como o momento posterior à mesma implementação.

IV.1 Caracterização da Rall
A Rall foi fundada em 1971 com dois funcionários e uma unidade de produção de cerca de 200 m2, dedicando-se inicialmente à serralharia civil; conta hoje, na sua estrutura, com cerca de 150 funcionários e uma área coberta de mais de 10000 m2, tendo enriquecido a gama de produtos oferecidos, posicionando-se como uma organização especializada na produção de mobiliário metálico de escritório. Simultaneamente, foi realizando um contínuo esforço tecnológico através da aquisição de equipamentos, que permitiram aumentar e melhorar a produção (máquinas de corte, “quinadeiras”, balancés manuais, e mais recentemente um robot de soldadura).
Hoje em dia possuidora da certificação ISO 9001, a Rall tem, na gama que destina ao mercado a que se dedica, dois tipos de produtos: bens fabricados localmente e bens (sobretudo importados) que comercializa, em exclusividade ou não. Estes últimos produtos são chamados de mercadorias. Em termos comerciais, a Rall possui uma rede de cerca de uma centena de agentes, seu único canal de distribuição em 1999.

IV.1.1 Processo de Produção
O processo fabril da fabricação do equipamento de escritório (armários, secretárias, blocos e outros produtos metálicos) é relativamente rápido e simples, devendo considerar-se três grandes grupos de matérias-primas: (i) chapa; (ii) tampos em madeira, ou imitação (produzidos, em parte, numa unidade fabril do mesmo complexo); (iii) tinta (em pó).
De uma forma simplificada poder-se-á considerar a linha de fabrico de acordo com os seguintes passos:
(i) armazéns de matérias-primas;
(ii) corte da chapa;
(iii) maquinação da chapa ou tubo;
(iv) prensas (balancés);
(v) “quinadeiras”;
(vi) soldadura;
(vii) pintura;
(viii) montagem;
(ix) embalagem;
(x) armazenamento.
Há ainda um processo acessório, bastante mais simples, e que diz respeito à fabricação de tampos (para secretárias, blocos e mesas), bem como outros processos de montagem, como seja, montagem de cadeiras, com componentes pré-fabricados, acrescido dos tecidos; montagem de painéis (componentes metálicos em chapa pintada, tampos e tecidos); montagem de tampos (mesas e secretárias).
Em termos algo simplificados poderemos esquematizar a fabricação do seguinte modo, Fig.IV.1.

















Fig.IV.1 – Esquema, simplificado, de fabrico na Rall.

Será importante referir, para se ter uma ideia da complexidade na sua vertente comercial de um negócio deste tipo, que cada unidade final está dividida nos seus diversos componentes. Vamos dar como exemplo uma secretária; uma referência que para o cliente final seja “secretária modelo X, tamanho Y, cor Z, com tampo no material A” ou em alguns casos “X-Y-Z-A = modelo 123” deverá ser no Armazém de Produtos Acabados o mesmo que: 1 tampo no material A, 1 calha técnica, cor Z, n parafusos, referência I, 1 perna esquerda, cor Z, referência II, 1 perna direita, cor Z, referência III, 1 painel, cor Z, referência IV, 2 terminadores plásticos das pernas, cor Z’, referência V; ou seja, para construir uma referência comercial, é necessário pegar em várias referências da produção, que provêm de mais de uma linha de produção e de mais de uma linha de montagem. Se se tiver em conta que todos estes componentes terão que ser entregues ao mesmo tempo, dentro de um prazo razoável, muito possivelmente com mais elementos de escritórios, como cadeira, bloco de gavetas e outros acessórios, e se atendermos ainda ao facto de grande parte das encomendas poderem ser personalizadas, percebe-se como a complexidade aumenta grandemente.
Trata-se de um processo muito similar, em termos de exemplos mais correntes, ao momento em que escolhemos um automóvel (modelo, cor, cor dos estofos, jantes, etc.) e que do ponto de vista do cliente é relativamente simples. Do ponto de vista do fabricante, estamos perante uma indústria que comporta um alto índice de complexidade, em termos da gestão de materiais, bem como da gestão comercial, assim como do ponto de vista dos próprios Sistemas de Informação.

IV.1.2 Os Sistemas de Informação na Rall, antes da implementação do R/3
No que se refere à “Informática” , sendo apanágio da Rall o outsorcing na área dos Sistemas de Informação, a sua direcção era assegurada pelo próprio gerente da empresa, em acumulação com a direcção financeira (Anexo C). É digno de notar que, à data, a rede onde se enquadravam todos os utilizadores tinha um nível de segurança extremamente baixo, pois a vertente segurança era praticamente inexistente (por exemplo, ninguém usava passwords) e a política dos SI’s era informal e casuística.
Em 1991, a Rall adquiriu um pacote de software nacional para a gestão da produção , em Prolog, que compreendia as áreas Comercial, Planeamento e Gestão de Produção. Tinha um servidor próprio ligado à rede da empresa e os clientes emulavam terminais numa rede IPX. Este pacote sempre se mostrou bastante dependente dos prestadores de serviço e, sucessivamente, foi sendo “remendado” (patchs) e melhorado (upgraded) por forma a responder às crescentes solicitações dos utilizadores. Circunstâncias várias ditaram o seu afastamento; por exemplo:
- o facto da Software House ter passado por problemas de crescimento e cisão (três firmas diferentes foram herdando a conta);
- a manobra de retenção dos códigos fonte “em parte incerta”;
- o, relativamente fraco, mercado de conhecedores de Prolog;
- a exportação da solução desenvolvida para este cliente (vantagem concorrencial perdida, na percepção do cliente).
Os problemas a montante, no serviço prestado, tomaram formas prejudiciais em termos internos, pois os desenvolvimentos requeridos ou as correcções necessárias nem sempre se realizavam. Este clima de incerteza e dependência de um fornecedor único e incerto criou a necessidade de procura de uma solução alternativa.
Foi há cerca de seis anos que se iniciaram contactos para aquisição de uma alternativa ao programa de produção, acabando por ser escolhido um software espanhol (EDEF), com algumas centenas de implementações no país vizinho, e que era representado por uma firma de Coimbra. A aquisição deste pacote de software visava substituir o anterior sistema através da aquisição dos seguintes módulos: (i) Comercial; (ii) Planeamento de Produção; (iii) Gestão de Produção; (iv) Contabilidade.
O EDEF operava em UNIX, tinha uma base de dados proprietária e uma interface não gráfica. Ao contrário do que havia sido inicialmente proposto, este software não se conseguiu adaptar ao processo produtivo, pelo que se mostrou necessário manter o software nacional (escrito em Prolog) para a função Produção. Do mesmo modo, o EDEF não foi capaz de responder à totalidade de solicitações que a legislação nacional requeria na área da Contabilidade. Assim sendo, foi necessário realizar aplicativos diversos, autónomos, escritos em COBOL, para colmatar essa falha. O processamento de expedição era realizado no módulo comercial do EDEF. Por volta de 1997 foi tomada a decisão de passar o EDEF para Windows NT, tendo sido colocado numa rede Ethernet com protocolo TCP/IP. Foi feita a aquisição de um Alpha 1200, que corresponderia ao exigido aumento de desempenho não verificado no EDEF; o processo foi um desastre, já que o Alpha (uma máquina RISC) não se revelou melhor que um Pentium nesta aplicação. A análise da situação revelou o seguinte: no início de cada ano o sistema trabalhava bastante bem; porém, à medida que a sua base de dados (não relacional) ia crescendo, um simples clique de teclado para pedido de informação (listagem) mostrava-se demasiado moroso e afectava todos os que trabalhavam na base de dados. De igual forma, a velocidade de processamento parecia não afectada quando o multitasking não era necessário, pelo que muitos funcionários se mantinham para além da hora de saída (momento adequado para tirar listagens); a razão para este problema reside no facto de o software não ser Client-Server, mas ter sido projectado para UNIX. Assim o problema da falta de desempenho manteve-se e a empresa representante do software e fornecedora dos serviços de hardware não se mostrava capaz de encontrar soluções, designadamente o aumento da rede para 100Mbits e o incremento da plataforma de hardware das estações de trabalho para processadores Pentium.
Todas aquelas alterações foram paliativos que não resultaram e, até pelo contrário, se mostraram contraproducentes, uma vez que criaram falsas esperanças e expectativas jamais correspondidas. A explicação, posterior, da Software House não correspondia inteiramente à da sua representante, não recomendando, sequer, a aquisição de tão potente (e caro), mas inadequado, servidor RISC. Na verdade o problema era tanto mais grave quanto, ainda a acrescer a todos os outros problemas, a passagem de dados da Comercial para a Produção ter que ser “feita à mão” (literalmente, introdução de dados num sistema contra listagens em papel do outro). Esta situação “insustentável” manteve-se com ajustamentos internos de estrutura por cerca de dois anos.
Relativamente a outros aspectos, a situação era a seguinte: (i) a aplicação de Manutenção, instalada no servidor Alpha, mostrou-se capaz de responder (e até a exceder) às necessidades e expectativas originais dos utilizadores; (ii) a aplicação de salários, era uma aplicação comercial muito divulgada no mercado nacional e mostrava-se satisfatória. (iii) relativamente ao correio electrónico, uma vez que existia um servidor próprio, o Exchange Server, e que estava a ser utilizado no mínimo, o serviço de mensagens em Outlook (Client Exchange) não era divulgado.
Uma análise efectuada em Março de 1999, revelava que a Rall possuía duas aplicações principais para o seu negócio:
(i) uma aplicação de Produção/Comercial, de desenvolvimento nacional (Prolog) e continuadamente desenvolvida para a empresa durante cerca de 9 anos, com uma orientação muito taylor-made; esta aplicação estava colocada num servidor adequado, possuía uma interface “não gráfica”, existindo estações de trabalho com emulador de terminal, numa rede IPX;
(ii) a aplicação comercial EDEF, de origem espanhola, da empresa IMAGINE; esta aplicação tinha uma interface “não gráfica” e uma base de dados proprietária, não relacional.
Para além destas, a Rall possuía também as seguintes aplicações de suporte:
- aplicação PRISMA, para a gestão da Manutenção; aplicação Client_Server, com uma base de dados Oracle e correspondendo na totalidade à necessidade para a qual tinha sido adquirida;
- módulo de Contabilidade, da aplicação EDEF; integrada no módulo comercial e necessitando de alguns patches aplicacionais autónomos para cobrir as necessidades da contabilidade portuguesa;
- aplicação PHC, para os salários, que não cobria (na totalidade) as necessidades sentidas pelo departamento responsável;
- Exchange Server, para correio electrónico, servindo para Email Internet (dial-up) de um só utilizador.
Do ponto de vista da infra-estrutura informática, todos os postos de trabalho (cerca de 25) encontravam-se ligados em rede Ethernet nível 5, contando com dois servidores para as aplicações, servidor Alpha 1200, com Windows NT (servidor de domínio), servidor 486, exclusivamente para o software de produção e existindo, ainda, um servidor HP duplo Pentium para o Exchange Server. A ligação à Internet era realizada através de um Router.
IV.2. Um Sistema de Gestão Integrado na Empresa
A situação descrita na secção anterior define os SI na Rall em Março de 1999. Porém, em Maio de 1999, o autor desta dissertação entra para os quadros da empresa, tendo como objectivo muito específico encontrar uma solução no mercado que ultrapassasse aquele status quo e, concomitantemente, estivesse apta a não padecer do problema do ano 2000. A alteração estrutural, que passou pela introdução de um responsável pela gestão de informação, foi uma aposta na mudança da gestão de topo da organização (ver anexo D).
Perante as solicitações do mercado em que se insere, e a necessidade de dar corpo a uma visão enquadrada numa política de qualidade da empresa (recentemente entrada nos sistemas de qualidade), a Rall defrontou-se com a necessidade de mudar. Mas, porquê mudar?
Das muitas razões invocadoras da mudança, era evidente que algumas delas eram clamorosamente motivadoras de preocupação:
- ciclo de produção demasiado longo (14 a 28 dias, dependendo dos produtos);
- nível de stock demasiado alto (cerca de 100 000 contos), único meio de “responder” rapidamente às solicitações dos clientes;
- sistemas informáticos (comercial e produção) não comunicantes entre si, causando falhas e perdas internas;
- falta de garantia (dos sistemas informáticos) em ultrapassarem, sem problemas, o bug do ano 2000.
Estavam, assim, criadas condições para se gerar uma mudança rápida e eficaz.

IV.2.1 Preparação da Organização para a Mudança
Tendo em conta ser conhecido que a Haworth “produz” em cinco dias, tornava-se importante mudar para “muito melhor” do que aquilo que se tinha. Como referem Michael Fradette e Steve Michaud, na Corporate Kinetics:
“[na Haworth] Demora um dia a correr o MRP e a colocar a ordem na produção. São mais três dias para percorrer a zona fabril, e mais um para a colocar num camião. Resulta, assim, num processo de cinco dias desde a recepção da ordem até à sua execução. Isto acontece quer se trate de simples cadeiras, até ordens de 20 milhões de dólares.”

IV.2.1.1 Pressupostos do Projecto
Tomada a decisão, da mudança, a gerência colocou os seguintes pressupostos ao projecto:
- ser um software internacional, com um suporte alargado;
- ser um sistema integrado;
- capaz de saber “fazer” capacidades finitas .
Aparentemente as duas primeiras questões estariam respondidas num ERP. Já no tocante à terceira, é necessário lembrar que o planeamento de capacidades finitas não é um apanágio de todos os sistemas ERP. Contudo, a intenção mantinha-se, tendo a empresa começado por apreciar os seguintes softwares: Oracle, Symix, SAP (três empresas implementadoras, os três VAR da altura), BAAN, MFG/Pro, JDEdwards, Great Plains. Destes, apenas dois, correspondentes a quatro propostas, foram capazes de responder à terceira questão dos pressupostos de planeamento de capacidades finitas , pelo que passaram à short list: (i) SAP; (ii) MFG/Pro.
A escolha recaiu numa solução SAP (das três disponíveis), em virtude de se tratar de um software com provas dadas, comparativamente mais integrado e por falta de “massa crítica” dos consultores MFG/Pro. Este processo envolveu cerca de 7 pessoas da empresa , em 11 sessões de apresentação das soluções de um dia, e decorreu pelo período de pouco mais de um mês.
A escolha do sistema SAP R/3 deveu-se fundamentalmente às seguintes expectativas, e necessidades:
- integração on-line de processos empresariais, o que possibilita uma gestão mais eficaz da informação, do fluxo documental e das interdependências existentes entre os vários departamentos;
- possibilidade de configuração e adaptabilidade do sistema à estrutura organizativa da empresa;
- “Business Best Practices” – possibilidade de aproveitamento do know-how de gestão que serviu de base ao desenvolvimento das funcionalidades disponíveis nos vários módulos do sistema;
- continuidade, desenvolvimento e evolução da plataforma tecnológica assegurada, uma vez que o SAP R/3 é líder mundial na área dos ERP´s;
- possibilidade de recurso a um vasto conjunto de funcionalidades SAP que estão fora do âmbito do Projecto, mas que poderão vir a ser desenvolvidas e incorporadas futuramente no sistema.
A tomada de decisão fez-se com a totalidade dos membros do staff da empresa a pronunciarem-se e comprometerem-se com a solução escolhida. Assinado o contrato, o trabalho iniciou-se de imediato.

IV.2.1.2 Objectivos e metas a alcançar no Projecto
Numa perspectiva empresarial, os objectivos e metas estabelecidos para o projecto foram:
- integração funcional dos vários departamentos;
- dotar o Departamento Comercial das ferramentas de gestão e de decisão adequadas ao crescimento e orientação estratégica prevista para os próximos anos, pretendendo-se:
- a diminuição dos ciclos logísticos através de uma mais rápida e eficiente resposta às encomendas dos clientes, tanto ao nível da produção interna como ao nível das encomenda de mercadorias a fornecedores;
- facilidade e automatismo dos processos comerciais.
- dotar o Departamento Comercial de uma base de dados “robusta” e acessível, permitindo a extracção de análises flexíveis e multi-características para a tomada de decisão ao nível dos produtos e estratégia de mercado a seguir;
- implementação do “Make to Order” como principal estratégia de produção;
- optimização do sequenciamento da Produção e diminuição dos ciclo produtivos;
- automatização dos processos contabilísticos da empresa;
- implementação da Contabilidade Analítica e da Análise de Rentabilidade.
Para o projecto SAP foram também determinados objectivos a serem atingidos, nomeadamente:
- garantir uma formação inicial adequada, como forma de dar a conhecer aos Key-Users as principais funcionalidades do sistema SAP R/3, permitindo a sua participação activa na escolha das funcionalidades a implementar e na construção do Protótipo Funcional;
- aproveitamento e análise da possível utilização das diversas funcionalidades e ferramentas de gestão disponíveis em cada um dos módulos do sistema SAP R/3;
- reformulação e reengenharia de processos, sempre que o funcionamento do sistema assim o potenciasse;
- optimização das funcionalidades SAP R/3, que foram escolhidas para a gestão dos vários departamentos e da Rall, na sequência dos resultados dos levantamentos de processos;
- constituição de equipas de trabalho efectivas, formadas por Consultores Funcionais de cada um dos módulos e pelos Key-Users escolhidos para cada um dos sub projectos, como forma de garantir um adequado grau de acompanhamento no desenvolvimento do Protótipo, bem como a adaptabilidade do sistema final à realidade da Empresa;
- passagem de conhecimentos funcionais e de parametrização do Consultor Funcional para o Key-User, como forma de garantir, na fase pós-projecto, um grau de autonomia permitindo ao Key-User assegurar a gestão corrente do sistema;
- arranque para o Produtivo no dia 6 de Janeiro do ano 2000.
Relativamente a medidas de desempenho relacionadas com o projecto consideraram-se as seguintes:
- níveis de stocks mais baixos;
- crescente preponderância da estratégia de produção e comercial “Make-to-Order” ;
- diminuição dos ciclos produtivos ;
- diminuição dos ciclos logísticos;
- implementação da análise de rentabilidade por segmentos de negócio;
- implementação do controlo orçamental dos departamentos;
- ganhos de produtividade resultantes de um mais fácil acesso à informação de gestão e do fluxo on-line de informação entre os vários departamentos;
- extracção rápida e inteligente de análises de gestão.

IV.2.2 O Projecto SAP
Constatando-se que a anterior estrutura de hardware estava incapaz, tornou-se inevitável por razões de padrão da própria SAP transformar a rede informática em algo distinto do passado. Nesse sentido, temos concomitantes, 3 realidades no que respeita ao hardware: os servidores anteriores ao SAP; os servidores SAP; os novos elementos activos de rede, servindo estes para dar corpo à Política de Sistemas de Informação . Esta política, nova na organização, alterou o paradigma até então vigente, passando-se assim, do ponto de vista do utilizador a:
- conceder-se uma identificação única e individual aos utilizadores ;
- permitir o acesso aos recursos informáticos, unicamente através dessa identificação autenticada pela palavra chave, detida apenas pelo utilizador;
- possibilitar esse acesso em qualquer computador da organização;
- ser obrigatório o arquivamento de ficheiros no Servidor de Ficheiros Rall01.
Do ponto de vista de arquitectura de rede, elementos passivos e activos de rede, esta foi completamente redesenhada, passando-se para uma rede totalmente a 100 Mbits, tendo-se construído um servidor exclusivamente para Exchange e um outro para Ficheiros (cada departamento e cada indivíduo sem acesso a áreas estranhas). Do ponto de vista de fiabilidade do sistema, este passou a estar disponível 24 horas por dia com uma curta paragem semanal. Os backups passaram a ser diários, o que não acontecia até então. Mantiveram-se os anteriores servidores de aplicação comercial/financeira e produção. Ainda do ponto de vista do utilizador, a panóplia de sistemas operativos cessou, procedendo-se a uma uniformização e legalização de software. A equipa de Sistemas de Informação completou ainda a Política de Sistemas de Informação com um Plano de Recuperação de Dados.
Estava assim pronto o terreno para se proceder à montagem do “Hardware SAP”. Este foi obrigatoriamente novo, sendo constituído por dois Proliant da Compaq, um deles Proliant 600, com 2 PII Xeon 450 e 1GB de RAM, sendo o disco de 36GB . Esta máquina funcionava com NT4.0 e possuía Oracle como base de dados de suporte ao SAP. De acordo com as prerrogativas da SAP, este foi considerado como o servidor de produção. A segunda máquina, menos potente, servia somente para manter uma cópia da anterior e proceder a testes e alterações. Apenas depois dos testes validados se procedia à cópia para a máquina de Produção SAP.
O projecto SAP, do caso estudado, restringiu-se à implementação dos módulos de:
- PP (Planeamento de Produção);
- MM (Gestão de Materiais);
- FI e CO (Contabilidade Financeira e de Gestão) e TR (Tesouraria);
- SD (Vendas e Distribuição).

Fig.IV.2 – SAP, módulos instalados na Rall.

Destes módulos, nem todos os diversos componentes de cada um fizeram parte da implementação, de maneira a não prejudicar o tempo útil do projecto. A análise do Gantt do projecto (anexo E) permite perceber que o tempo foi perfeitamente controlado para que o produtivo tivesse início na data marcada: 6 de Janeiro de 2000. Esta data não foi escolhida aleatoriamente; é a data para a qual se apontava a necessidade de ultrapassar temores com a mudança do número de dígitos das aplicações existentes (o bug do ano 2000). Desta forma calendarizaram-se, num software de projecto, as diferentes fases de implementação:
- Fase I: preparação do projecto;
- Fase II: desenho conceptual;
- Fase III: realização do projecto;
- Fase IV: preparação final do projecto;
- Fase V: Going Live a apoio ao produtivo.
Cada uma das fases estava subdividida em diversas tarefas, todas elas importantes para a prossecução do projecto com sucesso; como será natural, algumas seriam simultâneas e acompanhadas de uma maior ou menor complexidade de tarefas.

IV.2.2.1 Estrutura da Equipa
O princípio fundamental passou pela determinação rigorosa do âmbito do projecto. Sendo um projecto R/3, pela sua extensão e pelo elevado número de funcionalidades a adaptar à especificidade de cada empresa, teve que ser realizado por uma equipa mista, constituída por utilizadores do cliente e contando com o contributo de “implementadores” com um forte conhecimento do produto, habilitados a prestar um serviço profissional de consultoria. Este serviço de consultoria constituiu o núcleo do conjunto de serviços que se estendeu à administração técnica do sistema R/3 durante a fase de projecto, ao desenvolvimento de funcionalidades adicionais, à preparação do carregamento inicial de dados, à adaptação de formulários e reports, à formação dos utilizadores e à coordenação do projecto.
Trata-se de uma vantagem adicional se, na escolha da empresa consultora, for tido em conta a garantia da disponibilização de recursos nas fases subsequentes do projecto, o suporte continuado à exploração, a manutenção e optimização do sistema. O suporte deve ser constituído por especialistas dos vários domínios técnicos envolvidos: administração e upgrading do sistema, serviços de formação, administração de bases de dados, conectividade e sistemas de comunicação, desenvolvimento de add-ons e interfaces, serviço de help-desk, etc.
No caso presente, a estruturação da equipa de projecto passou por dois níveis de responsabilidades:
(i) uma Direcção de Projecto: constituída por (i) Chefe de Projecto (Gestor de Informação), (ii) Consultor-coordenador. As esta direcção estavam acometidas as seguintes competências:
- planeamento e controlo do projecto;
- gestão da mudança;
- coordenação integrada do trabalho de cada Grupo de implementação;
- definição e implementação dos standards de projecto.
(ii) Grupos de Implementação: foi constituído um grupo de implementação, por cada sub-projecto, constituído por um utilizador (key user) e um consultor. Foi ainda constituído um grupo de implementação por cada área, a saber:
- Área Financeira:
- área de contabilidade geral, contas a receber, contas a pagar – FI;
- área de controlo orçamental (controlo orçamental, contabilidade analítica e controlo de gestão) – CO;
- área de gestão de tesouraria e financiamentos – TR.
- Área de Aprovisionamento (compras, materiais, armazéns e recepção/conferência de facturas de fornecedores) – MM;
- Área de Vendas e Distribuição – SD;
- Área de Produção – PP.
Foi também formado um Grupo de Acompanhamento, sponsor do projecto, com um membro da Gerência da Empresa estudada que, em conjunto com um Administrador da Empresa se reuniam mensalmente com a Direcção do Projecto.
Por último constituiu-se um grupo de Suporte Técnico, composto por quadros informáticos da Rall e os consultores BC, na dependência da Direcção do Projecto.
Esta estrutura apresenta-se na Fig.IV.3:













Fig.IV.3 – Configuração da equipa do projecto.

IV.2.2.2 Metodologia de Implementação
A metodologia usada foi entendida como sendo apropriada a projectos de implementação do R/3, tendo como base a experiência da equipa consultora, sendo balizada pelas recomendações e orientações da própria SAP. Dispôs-se, assim, de um Guia Metodológico próprio para uso no projecto.
Para cada uma das fases do projecto, o Guia identificava os objectivos, requisitos, intervenientes, produtos finais e validação; para além disso, decompunha cada fase nas diversas actividades, descrevendo-as e identificando as relações de interdependência e a documentação de suporte. Finalmente, o Guia contemplava ainda algumas normas de gestão do projecto, recomendações para a Gestão da Mudança e estimativas de tempos de realização das várias actividades do projecto. Foi com base nestas e tendo em conta a dimensão da equipa proposta, os recursos internos e externos considerados, que se elaborou o plano de projecto e se estimou o esforço de realização necessário.
No pressuposto da constituição dos Grupos de Implementação com a dimensão e envolvimento previstos no Estudo de Implementação e tendo em conta o Plano Global que o integra, o esforço de consultoria funcional encontrava-se previsto da seguinte forma, Tab.IV.1:


SUB-PROJECTO DURAÇÃO
(dias) Envolvimento do consultor Total de dias
FI/TR/CO 110 86% 95
MM 110 98% 108
SD 110 84% 92
PP – dados básicos 130 35% 45
PP – planeamento de produção 130 92% 120
Esforço de consultoria 460
Tab.IV.1 – Plano de consultoria.

Num projecto R/3, é recomendável a afectação de um consultor BC (Sistema Básico) para suportar a Equipa de Projecto nas tarefas de administração do sistema e de um programador ABAP que vai apoiar os elementos informáticos das equipas de implementação na realização da programação. No âmbito da sua actividade, estes consultores colaborariam, entre outras, nas seguintes tarefas específicas:
- implementação do sistema de autorizações;
- vigilância dos tablespaces da Base de Dados, de ficheiros de login e de outros ficheiros do sistema e do funcionamento das interfaces;
- tuning do sistema;
- instalação de novas versões do R/3 e inserção de correcções no software standard;
- registo e reporting à SAP dos erros e anomalias de software e acompanhamento da sua resolução (recurso ao On-line Support System );
- realização de backups;
- operações de arquivo, limpeza e reorganização de ficheiros;
- operações de recuperação de dados;
- desenvolvimento de software à medida, como por exemplo interfaces de carregamento inicial de dados.
Para o consultor BC foi previsto um envolvimento médio de 5% do tempo de duração efectiva do projecto. A sua colaboração iria diminuindo à medida que os informáticos da empresa fossem adquirindo o know-how necessário à completa administração do sistema. Para o programador ABAP, previa-se um envolvimento de 30% a partir do início da construção do protótipo global e até ao arranque do sistema. Em síntese, a carga de trabalho prevista para estes recursos seria de cerca de 31 dias.
Um consultor-coordenador integrante da Direcção do Projecto seria designado para as seguintes tarefas:
- planificação das actividades do projecto;
- definição dos standards técnicos e de gestão do projecto;
- coordenação técnica do trabalho dos grupos de implementação;
- assegurar a integração das várias aplicações do R/3 entre si e destas com os sistemas externos;
- avaliação do esforço dos recursos e medição do progresso do projecto;
- detecção e antecipação dos desvios entre o planeado e o executado;
- promoção de acções de controlo de qualidade do projecto.
O envolvimento do consultor-coordenador seria variável ao longo do projecto mas, em média, previa-se uma intervenção da ordem dos 20%, o que corresponde ao esforço global de cerca de 26 dias.
Uma tarefa de extrema importância é a formação. Face à configuração do software a implementar, a formação prevista teria a duração global de 33 dias úteis, Tab.IV.2:


SUB-PROJECTO DURAÇÃO
(dias)
FI/TR/CO 5
CO 3
MM 5
SD 5
PP 5
BC 10
Esforço total 33
Tab.IV.2 – Tempo previsto para formação.

Estando a metodologia definida, torna-se importante, no sentido de dar cumprimento ao projecto, fazer realçar o plano, o qual tem por base a metodologia ASAP.

IV.2.2.3 Fases do Projecto
Cada uma das fases enunciadas foi calendarizada e caracterizada ao pormenor, evidenciando-se por resultados esperados versus objectivos.
(i) Fase I – preparação do projecto - tarefa 1 :
Objectivos:
- elaborar o planeamento e a preparação iniciais para o projecto (identificar e planear as áreas fulcrais a serem consideradas); tarefa 4;
- definir as linhas orientadoras do projecto (objectivos e metas a alcançar, estratégia de implementação, organização do projecto, alocação de recursos); tarefas 3 a 6.
Resultado esperado:
- deveriam estar concluídos, após a finalização da fase I, os seguintes documentos:
- documento “Linhas orientadoras do projecto”;
- planos do projecto (de trabalho, de orçamento e de recursos);
- documento de âmbito do projecto (processos de negócio que estão dentro e fora do âmbito).
Também se esperavam as seguintes tarefas:
- estratégia de implementação delineada;
- sala de trabalho para a equipa do projecto preparada;
- alocação de pessoas e definição de funções;
- plano de formação da equipa do projecto definido;
- standards e procedimentos da gestão do projecto definidos;
- estratégia de configuração técnica dos sistemas (número de sistemas necessários, estratégia de mandantes e de transportes).
(ii) Fase II – desenho conceptual - tarefa 19:
Objectivos:
- realizar um levantamento exaustivo dos processos da empresa de forma a compreender como a empresa pretende funcionar com o sistema R/3; tarefa 20;
- análise de cobertura R/3; tarefa 23;
- deverá, nesta etapa, se necessário, redefinir-se e confirmar-se os objectivos a alcançar assim como reajustar o planeamento; tarefa 28.
Resultado esperado:
- deveriam estar concluídos, após a finalização da fase II, os seguintes documentos:
- documento “Processos de negócio da empresa”;
- documento “Estrutura organizativa”.
Também se esperava que tivessem acontecido:
- reuniões com a equipa de projecto para apurar as necessidades da empresa;
- validação, por parte do gestor de projecto, do levantamento efectuado;
- verificação de que a formação da equipa do projecto foi bem sucedida;
- confirmação de funções e responsabilidades dos elementos da equipa;
- disponibilização e alocação de recursos da empresa para acompanhamento total e integração do projecto;
- definição do guia de implementação da empresa e do projecto;
- arranque da parametrização do sistema.
(iii) Fase III – realização do projecto - tarefa 34:
Objectivos:
- proceder à implementação total no sistema, acompanhado dos respectivos testes (construção do protótipo total); tarefas 35 a 52.
Resultado esperado:
- validação do protótipo global;
- desenvolvimento de programas de interface;
- definição de autorizações dos utilizadores.
(iv) Fase IV – preparação final do projecto - tarefa 55:
Objectivos:
- preparação do sistema produtivo (testes finais, formação final – funcional e técnica – da equipa de projecto e alinhamento final da administração de sistemas); tarefas 58 a 65.
Resultado esperado:
- reuniões finais com a equipa de projecto com o intuito de rever os últimos pormenores;
- verificação de que a formação final da equipa de projecto foi bem sucedida;
- confirmação de que o sistema responde eficientemente aos testes.
(v) Fase V – Going Live a apoio produtivo - tarefa 66:
Objectivos:
- passagem do sistema para ambiente produtivo; tarefa 67;
- suporte e acompanhamento dos utilizadores finais; tarefa 71.
Resultado esperado:
- garantir a auto-gestão a longo prazo dos utilizadores finais; tarefa 71.

IV.2.2.4 Padrões e procedimentos da gestão do projecto
Num projecto desta envergadura, a ausência de uma linha orientadora para o trabalho de equipa seria um princípio desastroso. Nesse sentido, procedeu-se ao desenvolvimento de padrões de conduta para os membros da equipa se guiarem. Um plano de comunicação do projecto, da documentação a ser usada, bem como dos seus templates, e localização tornou-se muito importante.
Os elementos que se seguem são demonstrativos do que foi feito no sentido de estabelecer uma grande ligação entre a equipa interna e externa, por forma a minimizar os desvios e também para servir de orientação, digamos que de linguagem uniforme para todos . Apresenta-se, de seguida, o chamado Plano de comunicação do projecto.

IV.2.2.4.1 Plano de Comunicação do Projecto
Calendarização de reuniões:
A Comissão de Controlo do projecto reúne mensalmente, à quarta-feira da quarta semana de cada mês (data sujeita a confirmação). Todas as reuniões terão acta feita por uma pessoa a designar na convocatória. Esta acta será enviada a todos os participantes bem como outras pessoas a designar. Os Chefes de Projecto reúnem uma vez por semana em data não fixa. A acta de reunião será facultativa, sendo apenas elaborada caso se justifique. Mensalmente, será realizada reunião de coordenação de sub-projectos com a presença do Chefe de Projecto da Empresa Consultora e de todos os Consultores Funcionais.
Documentação de apoio:
Sempre que necessário, deverá ser utilizada a documentação prevista para o efeito na tabela de documentação do projecto .
Relatório de status:
Trata-se de um relatório mensal, elaborado pelo Chefe de Projecto da Empresa Consultora, a ser apresentado na reunião da comissão de controlo.

IV.2.2.4.2 Utilização de standards SAP
Configuração do sistema:
Todos os elementos da equipa de consultores tiveram plena autorização para configurar as suas áreas funcionais ou outras. A responsabilização e controlo foi assumida por cada um deles, e assim se manteve até que se notasse a necessidade de impor regras mais restritivas. Contudo esta configuração obedecia a um princípio: sempre que possível utilizou-se o standard SAP. Quando a regra anterior não fosse possível a configuração era feita em elementos resultantes da cópia do standard onde se faziam as alterações (primeiro na máquina de testes e somente depois na máquina produtiva). As alterações directas ao standard só foram feitas em casos esporádicos e aprovados pelo Chefe de Projecto (Rall).
Existiam dois perfis distintos no sistema. Aos consultores foram atribuídos perfis com todas as autorizações, tendo portanto acesso a todas as funções do sistema. Os utilizadores terão um outro perfil o qual lhes dará todas as autorizações funcionais, mas lhes restringirá o acesso a funções de parametrização e de Administração Básica (manutenção de utilizadores, por exemplo). Estes perfis, sendo fechados, podem ser redefinidos pelo responsável interno do sistema, o Administrador do Sistema.
Comunicação entre mandantes:
A customização teste, incluída em ordens de transporte específicas para o efeito, não necessitou de documentação. Toda a customização considerada final, incluída em ordens de transporte próprias, foi documentada. Existiu um documento, manual de parametrização por módulo.
Documentação:
Cada fase, referida, teve documentação própria, a qual teve como propósito fazer corresponder as actividades planeadas no projecto por forma a atingir os resultados esperados e, portanto, relacionados a cada um dos diversos objectivos elencados. Uma vez mais se reforça a ideia de uma enorme pressão formal por parte do projecto na organização.
Testes:
A parametrização em cada módulo foi delineada em 2 ciclos, nos quais se inserem os testes para cada um dos módulos. Assim, após um ciclo de parametrização haverá um ciclo de testes do respectivo módulo. Com esta definição, parte-se do princípio de que cada módulo é responsável pelos testes da sua configuração e que estes testes permitem uma verificação contínua da qualidade da parametrização.
Relativamente aos testes de integração, têm lugar após o final da parametrização, bem como de todo o trabalho de ABAP (layouts, modificações ao standard, implementação de notas OSS ). Previu-se uma semana inteira de trabalho de testes de integração a qual abrangeria desde a definição dos cenários até à detecção das falhas dos processos, passando pela realização propriamente dita dos testes.
Apoio pós-implementação:
O apoio pós-implementação foi organizado por forma a ser, numa primeira fase efectuado “in-loco”. Uma vez terminado o tempo previsto de Projecto para acompanhamento do Produtivo, corresponderia ao Cliente definir qual a estratégia a seguir.
Resolução de problemas:
A resolução dos problemas de hardware, rede, administração básica do sistema SAP e outro software estão todos centralizados na mesma pessoa, o Administrador de Sistema do projecto. O procedimento começa com o preenchimento, por parte de quem detecta o erro, da folha existente para o efeito a qual é então enviada ao Chefe de Projecto. Este, depois de aceitar o erro como tal, encaminhava-o para o responsável respectivo.

IV.2.2.4.3 Melhoramentos e modificações
O procedimento para melhorias e modificações no sistema começa com o preenchimento, por parte do proponente, da folha existente para o efeito, a qual é então enviada ao Chefe de Projecto para aprovação. Este, depois de aceitar a melhoria ou modificação, reencaminha o documento ao proponente que, a partir daí, é responsável pela gestão do tempo, das prioridades e por acompanhar o programador no seu trabalho. Sem esta tarefa de organização prévia de duas equipas que não se conheciam, seria impensável iniciar, sequer o projecto. Estas linhas orientadoras mostraram-se vitais para que, dentro das duas equipas, o nível de comunicação fosse quase empático.
Em termos das áreas funcionais que cabem no âmbito de implementação, anteriormente referidas como PP, MM, SD e FI/CO , o grau de pormenor considerado é extenso e resulta das conclusões da tarefa 2 (organização e âmbito do projecto) da Fase I. Por essa razão, optou-se pela sua colocação em anexo. Contudo, recomenda-se a sua recomenda-se a sua consulta no sentido de melhor se poder compreender, de que forma o tomou forma, em cada uma das diversas áreas. O anexo F encerra uma linguagem mais comercial, mas nem por isso menos própria, pois confere, com clareza uma panorâmica geral dos módulos MM, SD e FI/CO, contendo o anexo G uma descrição específica sobre cada componente dos diversos módulos, recomendando-se vivamente, por este facto, a sua leitura.
Em termos esquemáticos, encontramos, no que respeita a cada módulo, os diversos itens incluídos ou não na implementação SAP da Rall na tabela seguinte, Tab.IV.3, que permite, também, compreender a complexidade de itens a serem trabalhados em cada uma das grandes áreas incluídas no âmbito, pois de cada uma das funções (FI – Finanças, que inclui CO – Controlo de Gestão e TR – Tesouraria; MM – Logística de materiais e compras; SD – Vendas e Distribuição e PP – Planeamento e Controlo da Produção) alguns itens não viriam a ser considerados, quer por razões de projecto – ou seja, a escassez de tempo -, quer por razões de não aplicabilidade, como seja o sistema de lotes, por exemplo.

Ambito do Projecto da Rall (tem 2 da fase 1)
NO ÂMBITO FORA DE ÂMBITO
FI - Finanças X
Consolidação X
TR - TESOURARIA X
CO - CONTROLO DE GESTÃO X
AM – GESTÃO DE ACTIVOS FIXOS X
MM - LOGÍSTICA DE MATERIAIS E COMPRAS
Estrutura Organizativa X
Dados Mestres X
Processo de Compra X
Gestão de Inventário X
MRP - Sistema de Gestão de Necessidades de Materiais X
WM - Sistema de Gestão de Armazém X
Sistema de Gestão de Lotes X
Sistema de Valorização e Contabilização de Materiais X
Sistema de Classificação de Materiais X
Sistema de Avaliação de Fornecedores X
Sistema de Gestão de Contratos de Rappel X
Sistema de Estatísticas Comunitárias X
Sistema de Informação Logística X
SD – VENDAS E DISTRIBUIÇÃO
Estruturas Organizativas X
Suporte de Vendas X
Dados Mestres X
Hierarquia de Clientes X
Determinação de Materiais e Listas Técnicas X
Processos de Negócio em Vendas X
Expedição X
Facturação X
Verificação de Disponibilidades X
Layout’s X
Inserção de textos nos documentos X
Estrutura de Preços X
Produção sob Encomenda (Make-to-Order) X
Rappel X
Processamento Comercial entre Empresas do Grupo X
Transportes e Distribuição X
Comércio com o Exterior (Exportação) X
Gestão de Créditos X
Informação e Análise X
PP – PLANEAMENTO E CONTROLO DA PRODUÇÃO
PP-BD (Basic Data) Dados Básicos para Produção
 Listas Técnicas X
 Materiais Configuráveis X
 Roteiros de Produção X
 Centros de Trabalho X
PP - SOP (Sales and Operations Planning) Planeamento Geral de Vendas e Operações X
PP – DM/MPS (Demand Management - Master Production Schedulling) Planeamento Mestre da Produção e Estratégias
X
PP – MRP (Material Requirements Planning) Planeamento Necessidades Materiais X
PP – CP (Capacity Planning) Planeamento de Capacidades X
PP – SFC (Shop-floor Control) Controlo da Produção X
PP – PC (Product Costing) Custeio da Produção X
PP – IS (Information System) Sistemas de Informação para a Produção
 Sistema de Informação Logístico (SFC) X
 Sistema Controlo Ordens Produção X
 Sistema Info Materiais em Atraso X
PP – REM (Repetitive Manufactoring) Produção Repetitiva X
PP – PI (Process Industries) Indústrias de Processo X
PP – KAN (KANBAN) Produção Sistema KANBAN X
Tab.IV.3 – Âmbito do projecto.

IV.2.3 Desenvolvimento e parametrização
Uma vez conhecido o âmbito do projecto, quer de forma intensiva (anexos F e G), quer de forma esquemática como acabámos de ver na tabela IV.3 pode-se verificar qual a cobertura oferecida pelo chamado PCC - sistema pré-configurado – e que consta do anexo I . Ou seja, estão definidos, teoricamente, no que diz respeito a cada uma das diversas áreas do projecto, os itens incluídos ou excluídos e conhece-se, também, aquilo que em termos do SAP já se encontra a priori parametrizado, pelo que a diferença entre um e outro resulta no âmbito de parametrização que a implementação SAP requer.
As tarefas em causa, são sobretudo realizadas pela equipa consultora, que preparam, personalizadamente o software para o seu cliente. O tipo de tarefas que este “talhar” de software “à medida” do cliente compreende, abrange sobretudo duas áreas :
1) desenvolvimento;
2) parametrização.
A primeira área assume-se como programação, que saindo fora do standard, pode ser realizada se essa for a necessidade / intenção da implementação. A segunda, não exclui a necessidade de programação, mas, esta, é realizada no âmbito da adaptação de um standard à realidade da empresa cliente, digamos de um determinado processo.
A destrinça entre o que deve ser desenvolvido e o que apenas requer parametrização, decorre do chamado grau de cobertura. Se desta análise se constatar que o SAP standard responde às necessidades de determinado processo, então apenas “adaptações” (parametrizações) serão realizadas. Caso contrário, tem que se proceder ao desenvolvimento de programas, dentro do SAP . E este ponto pode ser crucial uma vea que a haver desenvolvimento, então teremos que apelar a uma prerrogativa da casa mãe, fabricante do SAP e que é a seguinte: “ Nos upgrades de software, apenas são assegurados pela SAP os programas standard”. Aqueles programas, desenvolvidos à medida, não estão assegurados, pelo que podem requerer novos desenvolvimentos. Apesar de não parecer, esta prerrogativa impõe, de certo modo, e indirectamente, as chamadas “melhores práticas” à generalidade dos clientes. Admitindo, a título de exemplo, que determinado processo não está coberto pelo SAP standard, a empresa encontra-se no dilema de, continuando com o processo, este necessitar de desenvolvimento e, como tal não ver assegurado um eventual upgrade, a menos que proceda a novo desenvolvimento ou, em alternativa, ajustar o seu processo “a um” dos standard da SAP para que o anterior problema não se verifique. Esta opção, a existir, é um alinhar da organização pelas normas “impostas” pelas melhores práticas.
A parametrização é feita a título comum em determinadas tarefas, como sejam:
- gestão de utilizadores;
- parametrização de autorizações funcionais;
- parametrização da área de Contabilidade Financeira e Controlo de Gestão;
- parametrização da área de Gestão de Materiais e Compras;
- parametrização da área de Gestão de Encomendas e Facturação;
- parametrização da área de Gestão de Produção.
A definição das autorizações funcionais a atribuir aos utilizadores do sistema R/3 para a Rall, compreendeu a criação de níveis de autorização específicos para cada um dos módulos acima referidos, para responder às necessidades específicas de cada processo. Este tipo de parametrização é, de certo modo, comum a todas as implementações, sendo, por essa razão, de enorme importância, pois definindo os níveis de acesso, limita-se ou permite-se que determinado utilizador do sistema tenha ou não acesso a esta ou aquela funcionalidade.
Dando como exemplo uma pequena parte de um processo de compra, pode-se definir o limite de autorização de compra para o comprador A, e outro limite completamente distinto para o comprador B, impondo, ainda a título de exemplo, a necessidade ou não de aprovação superior, por parte do responsável do departamento. O comprador A e o comprador B não poderão ter igual nível de autorizações. Os perfis são assim, tendencialmente, em maior número numa organização onde as funções se distinguem (caso dos compradores A e B), e em menor número nas organizações onde as distinções funcionais são menores (todos os compradores com igual orçamento de compra, significa um só perfil de comprador). Este foi o caso da Rall; inicialmente foram atribuídos perfis genéricos a cada tipo de função.
A configuração de autorizações, a ter em conta, deve resultar directamente do levantamento dos processos, sendo o desenvolvimento (em sentido lato de parametrização, e sentido estrito de desenvolvimento), maior ou menor, de acordo com o grau de cobertura. No caso de determinada funcionalidade já existir pré-configurada, pode decorrer uma simples alteração (parametrização menos consumidora de tempo).
Uma outra vertente não desprezível do projecto corresponde ao desenho de layouts de Documentos (SAPScript). É a vertente que corresponde à criação de visibilidade do SAP (do sistema), pois é pelos documentos que a empresa comunica com o exterior. Os documentos para os quais se procedeu à configuração dos layouts de documentos, para a área de Compras e Inventário, foram: a nota de encomenda; contratos de fornecimento e de entrega planeada; as ordem de “aviamento” (Picking); e a lista de recepção de mercadorias; configuraram-se os layouts dos seguintes documentos para a área de Vendas e Distribuição: guia de remessa, picking list, factura, notas de débito/crédito. A configuração dos layouts dos documentos acima referidos teve como base a alteração dos layouts standards do sistema R/3-PCC, isto é, considerou-se não ser necessário a construção “de raiz” de layouts. Os layouts dos documentos financeiros encontram-se pré-definidos no sistema Pré Configurado, de acordo com a legislação nacional em vigor e com as práticas correntes do mercado, resultando num processo mais simples .
A construção de Programas de Carregamento de Dados para as áreas de: Módulo Financeira (FI-CO), Módulo de Logística de Materiais de Compras (MM) e Módulo de Vendas e Distribuição (SD), inclui-se no chamado desenvolvimento específico , o qual corresponde à necessidade de criar uma interface capaz de traduzir os dados do cliente para um formato inteligível para o SAP R/3. A responsabilidade desta construção continua a pertencer ao grupo de consultores. O desenvolvimento específico não incluiu, no caso da Rall, a área funcional de PP, pois esta área sofreu grandes alterações ao nível das estruturas de fabrico. Na área de produção, com a entrada do SAP e em termos de desenho dos processos, adoptou-se uma alteração processual de fabricação, passando de “fabricação para stock” (make to stock) para um processo do tipo “fabricação à encomenda” (assemble to order), tendo tido como consequência uma reformulação das estruturas e dos roteiros de fabrico.
Se na questão parametrização e layouts anteriormente referidos os elementos da empresa têm um contributo diminuto, cabendo assim o papel mais importante aos consultores, uma outra questão se levanta em termos do projecto, e esta diz respeito ao Programa de Conversão e Carregamentos de Dados, uma tarefa que compreende três etapas: (i) Transferência de Dados Mestre; (ii) Documentos em Aberto; (iii) Saldos Contabilísticos. A equipa interna é, necessariamente, envolvida, em virtude de se tornar necessário disponibilizar dados referentes a cada uma das etapas consideradas.
Será importante fazermos notar que, em qualquer projecto de implementação de um sistema ERP, este momento deve ser extremamente bem avaliado, tão cedo quanto possível, pois ele determina o maior ou menor grau de carga de trabalho para dar cumprimento às necessidades do sistema R/3. O SAP tem que se encontrar alimentado de dados (confiáveis, correctos e actuais) e, no caso do projecto Rall partiu-se de um pressuposto, tácito, de que os dados a “importar” se encontravam “tratados” e organizados, em formato informático do tipo ASCII , bem como, de acordo com a estrutura pré-definida (standard) dos programas de carregamento do SAP.
É importante sublinhar o facto de que a existência e configuração dos ficheiros de dados (a alimentar), conforme acima indicado, é essencial para não ter que se verificar a construção específica de programas de carregamentos de dados e, não menos importante, bem pelo contrário, para que não haja trabalho manual de tradução de dados para um formato adequado ao novo sistema. Na verdade, no caso da Rall, os dados dos anteriores sistemas não eram dados confiáveis, em virtude de:
- o sistema EDEF (Comercial) não exportar em ASCII grande parte dos seus dados;
- os dados pretendidos serem inexistentes no anterior sistema;
- o sistema de produção se mostrar, igualmente, desadequado perante a reformulação das listas técnicas (com a alteração do número de níveis das mesmas e de alguns roteiros de produção).
Este inesperado contratempo impediu o projecto de prosseguir à velocidade de cruzeiro pretendida, mostrando-se o calcanhar de Aquiles de todo o projecto.
A vertente prática corresponde ao momento em que temos uma excelente oportunidade “entre mãos”: poder-se experimentar, ao vivo, a Gestão da Mudança. De certo modo, o simples desejo de mudar de Sistema de Informação, é em si uma demonstração da vontade de mudar. Mas esta mudança pode revelar-se um logro, se o suporte dado à mudança por parte da Direcção da empresa não se mostrar incondicionalmente como garante e apoiante dos actores que realizam a mudança. No que concerne à Rall, a Gerência pretendia a mudança. Aliás, aquando da escolha do software SAP procurou, junto do seu staff, o comprometimento com a decisão tida, pelo que é seguindo esse postulado que iremos apresentar a implementação que se realizou, contra um plano anteriormente apresentado (vide Anexo E).
Possuímos directrizes sobre o que o que implementar (o âmbito é conhecido); sabemos o que está pré-formatado, vamos, então, para o terreno, para a prática. Esta, tem de ser muito bem articulada ao nível da equipa ligada ao projecto, pois não podemos esquecer que a implementação de um projecto ERP tem lugar numa empresa em movimento, que continua a laborar, na sua normalidade e, ao mesmo tempo, de certo modo, a implementação do ERP é uma perturbação no normal funcionamento da empresa, exigindo um esforço acrescido, durante o tempo de implementação, a muitos colaboradores. É neste contexto, que o projecto de implementação do sistema ERP na Rall foi realizado, com a envolvente interna em plena laboração, com recursos escassos, auxiliada por uma equipa de projecto que envolveu mais de uma dezena de consultores e com o negócio a decorrer. A envolvente externa, principalmente ao nível de clientes e fornecedores, não podia, de todo, ser afectada, pois o nível de serviço apenas pode melhorar, não o contrário.
IV.2.3.1 A implementação
O plano de trabalho (anexo E) é de primordial importância, pois ele é o guia que articula e compromete todo o projecto e aqueles que nele estão envolvidos. Nesse sentido, fazemos acompanhar a explanação sobre as diversas fases de implementação, com as tarefas mais importantes de cada fase.
IV.2.3.1.1 Fase 1
A fase 1, sendo um momento de preparação, é uma fase de bastidores, havendo apenas uma grande tarefa com impacto para os utilizadores: a formação. Esta formação inicial, é uma preparação dos futuros utilizadores para as funcionalidades do SAP . Todas as outras tarefas, Tabela IV.4, são acometidas à equipa de projecto, e decorrem sem grandes incidentes. Importante será perceber a enorme confusão que a formação inicial, não comprometedora ainda, tem sobre as pessoas, futuros utilizadores. Trata-se de um primeiro impacto, mas cria nas pessoas um sentido de responsabilidade e de inevitabilidade da mudança. A Gestão da Mudança começa a chegar a mais pessoas. Desta vez, ainda sem grande impacto.

Item Tarefa Duração
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 Fase 1: Preparação do Projecto
Organização e Âmbito do Projecto
Def.âmbito e Objectivos Globais Projecto
Planeamento meios Técnicos e Logisticos
Organização e Procedimentos da equipa de Projecto
Definição da Estrat. Mandantes e Autoriz.
Formação
FI
CO
SD
MM
PP
BC - ADM
BC - ABAP4
BC - ADM
Kickoff do Projecto
Aprovação Planeamento do Projecto e Kickoff
Instalação dos meios técnicos de Desenvolvimento 93d
2d
0,5d
0,5d
0,5d
0,5d
93d
6d
2d
5d
5d
8d
2d
5d
3d
23d
1d
2d
Tab.IV.4 – Tarefas do plano de projecto, Fase 1.

Nesta fase, relevante para o projecto são as tarefas de bastidores da equipa de projecto. O anexo J contem uma listagem de documentos do projecto e sua localização. O anexo K refere quais os documentos que são considerados em cada uma das fases. Esta fase é o momento de organização, é o tempo das pessoas se conhecerem e se entrosarem com o projecto.

IV.2.3.1.2 Fase 2
A fase que se segue, fase 2, é de suma importância, fundamentalmente porque é nela que se realiza o chamado levantamento de processos (item 22), Tab.IV.5, o qual consta de entrevistas diversas aos decisores das áreas (vide exemplo no Anexo L) podendo chegar aos detentores das funções que estejam relacionados com determinado processo. Este momento é extremamente importante por diversas razões, mas sobretudo pela oportunidade de Gestão da Mudança que consagra. Nesta fase, é dada oportunidade aos responsáveis pelas áreas das diversas funções a implementar, de desenharem o seu modelo TO BE. A Gerência da Rall deu orientações estratégicas e os responsáveis pelas áreas tiveram em si a oportunidade de fazerem a mudança acontecer.
Item Tarefa Duração
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

Fase 2: Desenho Conceptual
Levantamento de Processos
Preparação dos Questionários
Realização do Levantamento de Processos
Análise de Cobertura
Determinação de Interfaces a Desenvolver
Determinação dos Formulários a Desenvolver
Avaliação de Desenvolvimentos Adicionais
Edição e entrega da documentação para aprovação
Reformulação do Plano de Projecto e Planeamento de Actividades
Inicialização do IMG
Criação do Enterprise IMG
Criação do Project IMG
Aprovação do Desenho Conceptual
Aprovação do Desenho Conceptual
Tab.IV.5 – Tarefas do plano de projecto, Fase 2.
36d
32d
2d
15d
10d
2d
2d
2d
5d
1d
1d
0,5d
0,5d
4d
4d


Este ponto é, por outro lado crítico, pois os consultores que realizam as entrevistas podem ter uma atitude de simples entrevistadores, em que de modo algum interferem sobre o alinhamento que o entrevistado consagre, ou então podem ter um papel activo e orientador, por forma a que todo o projecto possa servir de real mudança para a organização.
Realizadas as diversas entrevistas, pode proceder-se ao desenvolvimento daquilo a que se chama no projecto de análise de cobertura (vide Anexo M, ponto 23, subsequente ao anterior). Nesta, fase, podem verificar-se duas possibilidades: (i) o SAP cobre a 100% as necessidades do cliente e portanto do processo desejado (resultado das anteriores entrevistas); (ii) O SAP (standard) não cobre as necessidades do cliente quanto ao processos analisado. No primeiro caso (100% de cobertura), a acontecer, o consultor funcional está capaz de determinar quais as interfaces a parametrizar, que tipo de formulários deve desenvolver. Pode contar com a ajuda de um consultor de programação ABAP. No segundo caso (cobertura inferior a 100%), o sistema SAP, no que concerne ao processo em causa, carece de desenvolvimentos adicionais e isso é tarefa apenas para o programador de ABAP.
Resultado da análise de cobertura (vide Anexo N), realiza-se o planeamento da parametrização. A exemplificação, tendo por base a área de SD, consta do Anexo O. O planeamento em causa, é de enorme importância, quer para auto-controlo (dos consultores), quer para se poder criar um ritmo intensivo de trabalho. Por outro lado, a direcção de projecto pode, sempre, saber se o projecto está ou não a ser cumprido, nesta vertente. No caso da Rall, o calendário realizado pela equipa consultora foi cumprido escrupulosamente, constituindo uma enorme vantagem para o projecto.
Ainda a título de exemplo anexa-se um processo, da área de vendas e distribuição, respeitante ao processo “Estruturas Organizativas de Vendas” com duas secções distintas: uma com a estrutura de parametrização, outra com a descrição do processo (vide Anexo P) .
A Fase 2 termina, formalmente, com a aprovação dos processos (item 33) por parte do cliente (vide Anexo R-1 - desenho conceptual dos processos). Estes processos e demais formulários, são alvo de parametrização na fase seguinte. O documento final da Fase 2 é de importância vital, para ambas as organizações (cliente e consultora) não só porque carece da assinatura do Gerente da Rall, mas sobretudo porque sistematiza num só documento todo o trabalho de campo realizado até então através de:
- indicação do âmbito organizacional;
- processos, indicando quais os ficheiros dos processos, identificando-os;
- formulários, enumerando-os (a parte da visibilidade).
É, sobretudo e também, um documento que compromete de igual modo a Rall, pois define, claramente, que esta tem de disponibilizar, em datas rigorosas, e formatado em ficheiros fornecidos pela Empresa Consultora dados referentes a um sem número de itens, de todos os sub-projectos (funções), Tab.IV.6.
Descrição
Sub-Projecto data limite de entrega dos ficheiros definitivos
Movimentos contabilísticos em aberto á data de 30/10/99 FI 15/11/99
Movimentos contabilísticos em aberto á data de 31/12/99 FI 4/1/2000
Dados mestres de imobilizado AM 15/11/99
Histórico do imobilizado (valor aquisição e amortizações acumuladas) AM 15/11/99
Histórico de análise de rentabilidade CO 15/11/99
Mestre matérias primas LOG-GERAL 15/11/99
Mestre mercadorias LOG-GERAL 15/11/99
Mestre produtos acabados LOG-GERAL 15/11/99
Mestre produtos semi-acabados LOG-GERAL 15/11/99
Mestre materiais não stockaveis LOG-GERAL 15/11/99
Mestre materiais sem valorização LOG-GERAL 15/11/99
Mestre materiais produtos concorrentes LOG-GERAL 15/11/99
Mestre materiais sucata LOG-GERAL 15/11/99
Mestre embalagens LOG-GERAL 15/11/99
Mestre materiais publicitários LOG-GERAL 15/11/99
Mestre de clientes normais SD 15/11/99
Mestre de clientes potenciais SD 15/11/99
Mestre de clientes esporádicos SD 15/11/99
Mestre de concorrentes SD 15/11/99
Listas técnicas de vendas SD 15/11/99
Tabela de preços de venda ao público SD 15/11/99
Dados históricos de vendas SD 15/11/99
Mestre de Fornecedores MM 15/11/99
Contagem de Stocks MM 3/1/2000
Registos informações de compras MM 15/11/99
Listas técnicas de Produção PP 15/11/99
Roteiros PP 15/11/99
Centros de trabalho PP 15/11/99
Tab.IV.6 – Tipo de documentos e datas para a Rall entregar.

Nenhum dos módulos em causa escapou a esta necessidade acrescida, pois a verdade é que a empresa não começa do zero: tem um historial, tem compromissos a montante e a jusante, tem responsabilidades para com o fisco. Ao mesmo tempo, no caso particular desta instalação , várias áreas, distintas, necessitavam de um esforço adicional, muito rigoroso e exigente. Sendo verdade que o sistema ASAP está fabulosamente desenhado e que em rigor, o planeamento daí resultante (Anexo E) está excelentemente elaborado, a verdade é que neste caso a empresa não estava preparada para disponibilizar todo o manancial de informação a ser gerido e fornecido ao novo SAP.
A implementação do ERP confrontou-se pela primeira vez com a capacidade de mobilização de recursos e de meios na empresa, percebendo-se, então, que o ERP, nesta fase é muito consumidor de tempo e dedicação por parte de todos (cliente e empresa consultora). De repente, os membros ligados. De facto, e só para se referir a área de Produção, a necessidade de reformular as listas técnicas e os roteiros, portanto a estrutura de materiais, fez com que toda uma nova planificação de produção tivesse que ser colocada no sistema. Às outras áreas foi, igualmente exigido reformulações, re-afectações de pessoas / funções, e fornecimento de dados ao novo sistema.
De repente, o projecto deparou-se com a perspectiva de atraso relativo à disponibilização de dados para o sistema começar a ser testado; a Fase 3 e seguintes poderiam estar comprometidas.

IV.2.3.1.3 Fase 3
O envolvimento necessário para a Fase 3 torna-se mais consumidor de tempo para todas as pessoas envolvidas, nomeadamente por se tratar dos primeiros contactos reais com o SAP. Nesta fase, intitulada de Realização do Projecto, a componente que mais se destaca é a parametrização. Esta consiste em configurar no SAP os processos seleccionados e desenhados anteriormente, tornando-os operacionais, Tab.IV.7.
Item Tarefa Duração
34
35
39
40
41
42
43
44
45
46
47
48
49
50
51
53 Fase 3: Realização do Projecto
Estruturas Organizacionais e Configurações Gerais
Configuração Processos
Construção do Protótipo Funcional
Construção do Protótipo Global
Validação e aceitação do Protótipo
Administração de Sistemas
Criação de Users
Configuração de Impressoras
Perfis de Autorização
Desenvolvimentos, Relatórios, Interfaces e Formulários
Construção Interfaces
Configuração de Formulários
Execução dos Desenvolvimentos Previstos
Realização de Testes
Preparação da Formação do Utilizador 85d
5d
63d
37d
23d
3d
5d
0,5d
0,5d
4d
16d
5d
5d
6d
20d
2d
Tab.IV.7 – Tarefas do plano do projecto, fase 3.

Aparentemente, esta fase diz apenas respeito aos consultores e às pessoas mais ligadas ao projecto. Contudo, como atrás foi referido, a Rall tinha que preparar os dados para serem integrados no SAP que, finalmente, vai tomando forma. Nesta fase a empresa consultora disponibiliza matrizes em Excel, nas quais a informação relevante é introduzida para que o SAP possa “beber” num formato pré estabelecido esta informação . No presente caso, a Rall não conseguiu corresponder com a celeridade que as datas apertadas do contrato da fase anterior exigiam e isso causou um atraso irremediável ao projecto.
Na prática, constatou-se o incumprimento de calendário, tendo-se vindo a verificar que aquele incumprimento era o resultado de falta de dados por não terem sido:
- disponibilizados à Direcção de Projecto e, como tal, aos elementos de introdução de dados, por razões diversas;
- introduzidos ou compilados nos diversos departamentos, detentores desses dados;
Ou pela existência de dados inconsistentes, ou seja, dados que aparentemente cumpririam as especificações das matrizes, mas que não eram consistentes do ponto de vista do SAP (por exemplo, um roteiro mal desenhado do ponto de vista das hierarquias de materiais).
As falhas anteriores, cujo ónus se deve rigorosamente ao cliente, comprometeram, inequivocamente, todo o calendário do projecto.

IV.2.3.1.4 Fase 4 e Fase 5
As últimas duas fases são dedicadas à formação dos utilizadores e à preparação do ambiente produtivo, para que, na fase 5, o sistema arranque em ambiente produtivo, com os utilizadores a terem um apoio inicial por parte dos consultores, donde resulta que, chegados a estas fases, se tudo correr bem, então o plano pode ser cumprido; se nem tudo correr bem, então o plano não é cumprido. No caso presente, houve alguns atrasos.
Item Tarefa Duração
55
56
58
62
64
66
67
68
69
70
71 Phase 4: Preparação Final do Projecto
Formação dos Utilizadores
Preparação do ambiente Produtivo
Realização de Verificações ao Produtivo
Aprovação Final para o Going Live
Phase 5: Going Live e Apoio ao Produtivo
Going Live e Suporte ao Produtivo
Going Live
Gestão e Resolução de Problemas
Fecho do projecto
Recepção Definitiva do Projecto 20d
10d
8d
2d
1d
17d
16d
1d
15d
1d
1d
Tab.IV.8 – Tarefas do plano do projecto, fase 4 e 5.

IV.2.3.2 Plano de contingência
Porque não se conseguiu cumprir o calendário, houve necessidade de incluir num plano de contingência uma equipa permanente, a tempo inteiro, inicialmente de 4 depois de 8 operadores de dados, os quais introduziram milhares de dados, ao longo de várias semanas. Esta tarefa tornou-se tanto mais hercúlea, quando o modelo planeado não foi alcançado na plenitude à passagem do ano. Os enormes atrasos por parte dos departamentos tornou inviável a disponibilização em tempo útil dos dados para teste no SAP R/3, e consequentemente atrasou o projecto.
Por outro lado, numa tentativa de evitar o pior, a empresa estudada comprou o desenvolvimento paralelo da solução dos quatro dígitos à software house que desenvolveu o anterior programa da produção. Esta estratégia causou nos utilizadores uma sensação de relaxe, que originou ainda mais atrasos. Assim, entrados no novo ano 2000 e, por isso mesmo no final do projecto original, cada dia que passasse sem o novo sistema operacional representava, cada vez mais, mais dados para serem introduzidos, porquanto se torna necessário introduzir dados básicos no sistema e, ao mesmo tempo, colocar em paralelo o novo sistema; tudo ao mesmo tempo em que o anterior sistema ia dando suporte ao dia a dia da empresa.
Foi como se a 2 de Janeiro do ano 2000, o velho sistema trabalhasse na mesma, e o SAP R/3 estivesse a dar uma vantagem de tempo, em espera, para ter que recuperar posteriormente. Um pequeno atraso de uma semana revelou-se quase fatal para o novo sistema. Na verdade, a velocidade de aproximação que a introdução de dados no novo sistema revelava, era insuficiente para alcançar a “data de hoje”. Foi necessário investir na alocação de recursos humanos, para se atingir , em meados de Março, a (mesma) data em que o velho sistema trabalhava, ou seja, a data real. Para tal tornou-se imperioso que a empresa parasse durante vários dias, para colocar o velho sistema “KO” e para que o novo ficasse “on-line”. Desta forma, a Implementação revelou-se um projecto complexo e avassalador. Finalmente, não obstante um atraso de quase 3 meses, o sistema começou a rolar “ao vivo”.

IV.3. Algumas Conclusões

IV.3.1 Alterações decorrentes dos novos processos
Uma vez que alguns dos processos analisados eram horizontais à organização, destes novos processos decorreram alterações internas, em termos dos processos de trabalho e da estrutura. Referindo, como exemplo, a logística, a qual atravessa desde a função compras até à expedição, o impacto da mudança é bem maior que aquele que à partida se poderia ter imaginado. A breve trecho, o fiel de armazém de recepção, que, anteriormente, apenas realizava a conferência dos materiais, passava a ser um agente [mais] activo na organização, pois a verificação que ele realiza da guia de transporte é agora, efectuada no terminal de computador, confrontando a ordem de compra aí registada. Este simples acto gera um movimento contabilístico, o qual anteriormente era realizado em exclusividade pela área financeira, dando ordem ao sistema para efectuar, de acordo com as condições da ordem de compra, o pagamento ao fornecedor. No final da logística, e no que respeita ao armazém de produto acabado, deixa de fazer sentido estar anexado ao departamento comercial, pois é mais operacional e consequente da produção.
A alteração realizada veio dar maior entrosamento a esta área problemática, colocando-a sob a “alçada” da produção, a qual se responsabiliza por produzir e colocar produto na casa do cliente, pela via da expedição. Não houve uma única área que não tivesse sido abrangida pela mudança (resultado do ERP), mas aquela que revelou mais alterações foi a área comercial. Esta possuía anteriormente uma estrutura exagerada quando comparada com os dias de pós implementação: cinco gestores de conta recebiam por fax ou telefone as encomendas que eram processadas no computador por uma operadora. Respostas on-line poderiam demorar longos minutos pois os operadores não vislumbravam com a celeridade que um telefonema impõe a resposta às solicitações, por mais básicas que fossem (a minha encomenda está processada? Há o material x? Etc.). A mudança permitiu alterar estes procedimentos e o anterior STE (Serviço de Tratamento de Encomendas) acabou. Não a sua função, mas agora já sem o mesmo número de pessoas, e integrado num serviço de vendas. Das anteriores seis pessoas envolvidas no processo de gestão das encomendas, hoje apenas uma pessoa gere os contactos telefónicos e introduz as encomendas no computador, reportando à produção. Por outro lado a disponibilidade de informação é praticamente imediata. Como atrás referido, acabado o STE foi possível organizar uma força de vendas (anteriormente inexistente), a qual trás um enorme valor acrescentado para a organização. Por outro lado, em termos de produção o prazo de execução de uma ordem, que poderia demorar entre 14 e 28 dias (produção para stock), passou para situações médias de 5 dias, havendo casos de 1 dia, pois agora produz-se por encomenda.
Destes poucos exemplos pode-se constatar o grande impacto na organização. Na verdade o funcionamento da organização depende agora de um plano de vendas, o qual se abre num plano de produção, que por sua vez aloca recursos de stock, os quais a não existirem, implicam a realização de um plano de compras. Quando o plano inicial de vendas se concretiza em encomendas, estas são agregadas em ordens de produção, as quais exigem stock, já anteriormente comprado em virtude do inicial planeamento de vendas. É um círculo virtuoso!
A Organização com o ERP passou a funcionar a uma só voz. Apesar disso, algumas opções tomadas em determinada altura pela empresa mostraram-se “contrárias” ao sistema de “melhores práticas” recomendado pela SAP, como é o caso do sistema de custeio. O Anexo S apresenta parte de uma proposta onde seria suporto re-alinhar a Rall num sistema de custeio adequado àquilo que a SAP terá “aprendido” em tantos milhares de instalações pelo mundo fora. As melhores práticas são isso mesmo: quer a SAP, quer a empresa que presta consultoria têm na sua posse os “melhores casos” que integram no software e nas recomendações. Obviamente que a escolha (sistemas flexíveis) é decisão do cliente. No caso da Rall, o cenário implementado foi o da Implementação Compacta; assim muitas das “melhores práticas” foram adiadas para um momento posterior ao de arranque. Relembrando o que atrás se referiu, esta dá maior prioridade à componente técnica que à de reestruturação dos processos de negócio.

IV.3.2 Os aspectos negativos durante a implementação

IV.3.2.1 Key users
Num projecto tão complexo quanto aquele que teve lugar na Rall, a probabilidade de que nem tudo decorra de acordo com o planeado é grande. Também neste projecto houve situações que não correram da melhor maneira. A esse nível podemos referenciar uma falha ao nível da atribuição dos papéis chave. Esta falha, que não era perceptível ao tempo do início da implementação, mostrou-se disruptiva: os directores de departamento prescindiram, com excepção do responsável de compras (não era director departamental), da responsabilidade de se assumirem como Key users. E esta é, analisando este projecto à distância temporal em que nos encontramos, a origem de todas as outras falhas!
Se bem que tenha sido em sede de direcções de departamento que se assumiu o compromisso da mudança, os directores desde cedo prescindiram da responsabilidade do projecto. Este processo, difícil de explicar para quem esteja menos familiarizado com a realidade de algumas PME, pode ser descrito da seguinte forma: em empresas como a Rall, em virtude da sua antiguidade (cerca de 30 anos e onde diferentes gerações convivem), é possível encontrarmos pessoas que pela excelência e mestria como operários, foram sucessivamente alcançando primazia na organização, mas às quais não foi dada nem formação, nem correspondentemente ao crescimento na hierarquia foram realizando uma [auto] adaptação curricular, escolar ou não. Nesse sentido, há em algumas organizações, e a Rall não é excepção, dinossauros muito bem posicionados (na hierarquia). Estes são, na maior parte das vezes, avessos à tecnologia, convivendo com ela na medida do mínimo indispensável e recorrendo a imensos subterfúgios para nela não se imiscuírem.
No presente caso, tanto o Director Comercial, quanto o Director de Produção depositaram em pessoas de sua confiança a responsabilidade pela aprendizagem e muitas vezes o diálogo com a Direcção de projecto ou com os consultores. Esta forma indirecta de controlo, permitiu a ambos não serem tão responsáveis pela implementação nas suas áreas, tendo realizado tarefas de anti-jogo, as quais prejudicaram o bom funcionamento do plano (ora não disponibilizando recursos, ora não cumprindo os prazos que lhes estavam acometidos, ora contestando quase sistematicamente instruções da própria Gerência, por via indirecta, sempre na pessoa da Direcção de projecto ou dos seus consultores funcionais, ora percebendo que um ou outro perdiam poder).
A questão das lutas de poder, aquando da implementação de um sistema ERP será com certeza um excelente campo de estudo. Estamos certos, hoje, ser esta uma peça fundamental no sucesso de qualquer implementação e entendemos que um acompanhamento sociológico deverá ser realizado, pelo que recomendamos a entrada, desde o princípio, do responsável pela área dos Recursos Humanos, quanto mais não seja com um papel de assessor da Direcção de Projecto. Não que tal não tenha ocorrido no presente caso, mas uma atenção redobrada às relações entre os pares, deve ser uma das prioridades.
Uma outra questão, mais sensível ainda, diz respeito ao facto de no presente caso, o Key user da parte da área das finanças, estar entregue ao Gerente. No caso presente, tal não se observou, pelo que a responsabilidade foi depositada num colaborador de base da contabilidade.

IV.3.2.2 Cumprimento dos calendários
No caso presente, há ainda a assinalar o facto do arranque não ter ocorrido no momento desejado e esperado. Isso deve-se, antes de mais, ao facto de:
- no caso do EDEF (Comercial e Financeira), se tratar de um produto “fechado”, não exportador de dados;
- no caso do software da produção, em virtude das anteriores “árvores de materiais” se encontrarem bem desenhadas, se ter optado por realizar tudo desde o “zero”.
Como consequência destes factos, foi necessário proceder à recuperação manual de dados históricos (comercial e financeira) e construir as estruturas de materiais de produção de raiz. Inevitavelmente, isto conduziu ao incumprimento dos prazos e ao incumprimento do projecto.

IV.3.3 Os aspectos positivos durante a implementação
A opção por ter retratado inicialmente os aspectos negativos decorre do facto de agora nos podermos abalançar a aspectos mais interessantes e agradáveis.
Positivo foi o facto de se ter podido proceder a uma limpeza de zonas cinzentas na organização. Mesmo sem a alteração desejada por alguns, o facto de se ter instaurado um novo modelo de processos, em termos formais, veio esclarecer “duplicações” desnecessárias dentro da organização. Isto verificou-se logo à partida, imediatamente a seguir às primeiras reuniões de projecto.
Por outro lado, a simples consciencialização de se pretender um determinado “to be” foi bastante positivo. Apesar dos quid pro quo atrás enunciados como pontos negativos, os trabalhadores dos níveis operacionais sentiram, de facto, um elevado nível de empowerment . Na ausência, ou abstinência de responsabilidade, dos responsáveis, uma estratégia seguida pela Direcção de projecto foi dialogar com os operadores. Neste caso a Gerência mostrou-se bastante empenhada no sucesso da implementação, chamando muitas vezes a atenção dos responsáveis e tomando decisões que a esses caberiam, no sentido de ultrapassar escolhos por eles colocados.
A Gerência teve ainda um papel fundamental no voto de confiança à Direcção do projecto, dirimindo problemas (de poder) entre os responsáveis, sempre que chamada ao projecto.

IV.3.4 O momento posterior à implementação
Depois do sistema ERP estar oficialmente a trabalhar, os problemas não terminaram. Se bem que alguns problemas de desempenho (sistema operativo e base de dados), de consistência surgissem, no que concerne aos problemas técnicos, estes foram resolvidos com relativa facilidade, apenas com um grande senão: o planeamento de capacidades finitas, jamais foi colocado em marcha, e aqui verifica-se uma enorme lacuna por parte da SAP.
Se durante a fase de implementação, o interesse demonstrado por parte dos utilizadores era quase nulo, após a implementação, as pessoas contribuíram activamente com sugestões para a melhoria dos processos. Sendo um aspecto positivo, ele é tardio, pelo que há que motivar atempadamente todos aqueles que venham a ser utilizadores, não só pelo contributo da formação, mas também através da sensibilização realizada pelos seus responsáveis. Como seria de esperar, ao fim de poucos meses ao arranque do SAP, o sistema estabilizou.
O sistema é dinâmico e, como tal, os utilizadores iniciaram um rol de pedidos de melhoria. No caso de uma PME como a Rall, em que grande parte do know-how não foi transferido para esta, a dependência da empresa consultora manteve-se, em virtude das constantes solicitações de alterações / melhorias. Esta questão não tem muitas incógnitas: a transferência de know-how pode ser feita para o departamento de Sistemas de Informação de uma PME ?
É simples a resposta: as rotinas respeitantes à manutenção do sistema, nomeadamente a gestão da base de dados, tuning do sistema, etc, pode ser feita pelos elementos internos à empresa com uma formação de base. Já a aquisição de competências funcionais de parametrização do sistema em cada uma das áreas, não é de todo aconselhável, ou tornar-se-á necessário constituir uma equipa própria e dedicada. Este cenário não é de muito viável, pelo que numa PME que enverede pela implementação de um Sistema ERP com um certo grau de complexidade, como é o caso do SAP, se torna imprescindível manter a relação de parceria com uma empresa consultora, que possua recursos especializados.