domingo, julho 11, 2004
Anexos
Os anexos, de A a T contêm bastante informação, pertinente no caso da tese, mas dispensável no caso do Blog.
Capítulo VI
Conclusões
VI.1 Dos Objectivos
No início do presente trabalho, estabelecemos alguns objectivos, nomeadamente:
a) Contribuir para identificar algumas das actuais ofertas de sistemas ERP presentes no mercado nacional, o seu âmbito e respectivas características.
Apesar desta ser uma vertente muito comercial, pode dizer-se que hoje em dia as diversas plataformas são muito idênticas entre si. As competências do motor central de cada um dos sistemas ERP dependem em muito da forma como cada uma delas cresceu. Algumas nasceram à volta de sistemas de produção , sendo como tal muito fortes nessa área; outros tiveram a sua génese nos processos administrativos , sendo melhores nessa área em detrimento das outras. Com excepção de algum caso que não conhecemos, as aplicações nacionais tiveram a sua génese longe “da produção”, razão pela qual alguns deles não possuem sequer este módulo. As empresas internacionais de software a operar no nosso mercado cobrem, na generalidade, toda a panóplia de processos transaccionais, fazendo, assim, depender a sua escolha mais da capacidade das equipas consultoras que do próprio software. Optámos por retratar o líder, porque é tido como o mais complexo e também porque é o sistema implantado na empresa alvo do nosso estudo.
b) Contribuir para, com recurso a um caso, retratar o processo de escolha de uma aplicação ERP numa PME.
Neste caso, o processo foi muito rápido (um mês para chegar à decisão) e teve em linha de conta pressupostos muito rígidos por parte da Gerência da Rall. A escolha foi, também colegial, pelo que deveria ter imbuído todos com o mesmo espírito. Considerámos, ao longo do trabalho, diversos critérios, os quais podem ser usados numa métrica, de forma a aligeirar e facilitar este processo.
c) Contribuir para, com recurso a um caso, retratar o processo de implementação de uma solução SAP PME.
Este processo é o mais complexo de todo o trabalho e consta do Capítulo IV do presente trabalho. Entendemos que as relações entre os indivíduos são das menos facilmente retratáveis, bem como assim, as consequências das opções tidas ao longo de um projecto como aquele que apresentámos. Esperamos, contudo, ter retratado, um pouco da complexidade que uma implementação pode acarretar.
d) Contribuir para, com recurso a um caso, confrontar a política de melhores práticas do SAP com as políticas/realidade de uma PME.
Porque se torna pouco claro de que forma as chamadas melhores práticas se impõem, em termos práticos, às organizações onde os Sistemas ERP são implementados, optámos por esclarecê-lo através do conteúdo do Anexo S, num exemplo de aconselhamento sobre uma situação específica, neste caso à posteriori, tendente a corrigir uma opção tida pela Rall durante o processo de implementação.
As melhores práticas são um Benchmarking indirecto, por via da experiência acumulada, quer da empresa de software, quer da empresa consultora.
e) Contribuir para, com recurso a um caso, identificar as alterações organizacionais que provocam a implementação de uma solução SAP numa PME, nomeadamente pela realização de um estudo da mudança que a implementação de um ERP provocou.
No caso em apreço, será interessante verificar como a gestão da mudança contribuiu de forma tão evidente para dar uma nova cara à empresa. Num arrojado projecto liderado pelos Recursos Humanos e em muito despoletado pelas necessidades que o sistema ERP veio a mostrar, a Rall passou de uma organização hierarquizada, como foi possível conhecer nos organigramas, para um “Bolograma” (termo criado por Vasco Lopes), um conceito completamente novo e inovador.
No anexo T esquematiza-se o “Bolograma” da Rall, sendo de realçar que sem a introdução do ERP dificilmente teria sido possível chegar a uma estrutura deste tipo.
f) Contribuir para tentar compreender que valor acrescentado pode uma solução SAP trazer a uma PME.
Sem entrar na disciplina de análise de valor , poderemos indicar que à semelhança das normas ISO9000, os ERP permitem alinhar a organização de acordo com práticas internacionalmente tidas como sendo de sucesso. Poderemos, ainda, perceber que o aumento da satisfação dos clientes, o desenvolvimento de novas áreas de negócio, o aumento de competitividade e a eficácia nos processos, são itens expectáveis de melhorar.
No caso presente da Rall, a implementação SAP foi não só uma ferramenta organizadora dos processos , bem como melhorou, de forma sensível, objectivos menos directos como o ciclo de fabrico ou o time to market dos produtos, ou a própria disciplina de operação. Tendo o sistema ERP como charneira não se pode alterar um processo a “nosso bel-prazer”; há que ter disciplina, portanto, organização.
Outro ponto significativo, que não se pode entender como menos nobre, é o facto do ERP instalado (neste caso SAP), ser um bom instrumento de marketing. A presença da Rall nos (melhores) Marketplaces nacionais deveu-se, objectivamente e em grande parte, ao facto de existir o SAP. A presença destes novos canais só foi possível graças à implementação de um reconhecido ERP , pois sem ele, esse caminho (ao longo do eixo do E-Business, Tab.V.1) não teria, com certeza, ocorrido, uma vez que nem a companhia estaria preparada (velho paradigma de “make to stock”) nem, tão pouco, seria reconhecida como tal.
VI.2 Dos Sistemas ERP
Do ponto de vista técnico e tecnológico, um Sistema ERP é uma ferramenta complexa e extraordinária. A sua construção, sendo bastante sólida, em virtude de uma evolução longa e consolidada, permite-lhe uma grande adaptabilidade a, praticamente, qualquer tipo de organização; quer usando os diversos módulos pré-existentes, quer através do desenvolvimento, por programação, de interfaces para cobrir as necessidades dos processos dos destinatários. A experiência contida nos Sistemas ERP, conhecida como melhores práticas, pode, também, muitas vezes, levar, aquando da implementação, a organização a ajustar os seus processos àqueles considerados como a experiência dos melhores. Da implementação base de um ERP decorre, sobretudo, a integração ao nível operacional, tendo por base processos transaccionais, os quais percorrem a organização horizontalmente, facultando um excelente nível de respostas para os seus utilizadores.
Uma vez que a oferta de soluções ERP é vasta, a decisão sobre qual deles escolher não é simples. A melhor regra, pode ser uma parceria com a entidade implementadora mas, o compromisso pessoal de todos os colaboradores envolvidos não pode ser dispensado. Por outro lado, apesar do investimento ser algo avultado, o Sistema ERP pode trazer mais valias importantes para a organização, uma vez que copia as melhores práticas do negócio, e as traduz para a realidade organizacional, ao nível das suas transacções mais básicas. Contudo, um factor não desprezível a tomar em consideração, é o alto grau de complexidade que um ERP pode implicar, seja durante o projecto de implementação, seja na fase de pós-arranque.
Uma pergunta a que este trabalho procurou responder foi: serão os ERP adaptáveis às PME? Deveremos reformular a questão, e esta resulta da nossa experiência; “estarão as PME (e os seus colaboradores) capazes de se adaptar aos processos e às melhores práticas dos ERP?”
Se a resposta for sim, então “o ERP” trará, certamente, valor acrescentado à organização e contribuirá decisivamente para alicerçar o seu presente de forma a garantir o seu futuro. Se a resposta for não, a disrupção resultante pode ser nefasta para essa mesma organização, e convirá pensar melhor sobre o investimento (tempo, recursos financeiros, recursos humanos). No caso analisado, o primeiro impacto da implementação do ERP não foi abonatório da mudança introduzida. A empresa não estava preparada nem parecia querer a mudança! Atrasos iniciais resultantes de uma falta de elasticidade interna provocaram alguns problemas que apenas movimentos contabilísticos exagerados puderam resolver, com atraso e com stress desnecessário. Apesar deste primeiro momento, ainda aquando da fase de implementação, pode-se concluir que a introdução do Sistema ERP veio acrescentar uma (e) forte disciplina de operação. O rigor com que se consegue rastrear qualquer acção dentro do SAP deixa uma porta aberta de verificação sobre qualquer acção nele realizada. Comportamentos desregrados do passado não são hoje possíveis, pois o desenho dos processos não permite grande margem de manobra.
Uma pergunta interessante, por parte de um auditor da qualidade, na Rall, pode caracterizar a mudança mental que se torna necessária introduzir nas organizações: “Como são tratados os dados obsoletos?”
Convirá entretanto esclarecer que, de acordo com as exigências da norma NP EN ISO 9001:1994 a função gestão documental tem que garantir que apenas os dados mais recentes são usados e que todos os outros se encontram segregados. Sendo assim, há um tratamento especial a considerar quanto aos obsoletos. Mas, que acontece com o SAP? Simplesmente, não há dados obsoletos, pois estão todos disponíveis concomitantemente e o sistema assegura que apenas os últimos são usados . Esta nova filosofia de encarar os dados impõe uma grande capacidade de armazenamento, mas esse é um “mal menor”, o qual pode ser garantido com tecnologia.
A introdução do ERP veio, por outro lado, quebrar algumas anteriores barreiras departamentais. Se a informação está toda disponível, e é acessível, de acordo com as permissões, então não há lugar a capelinhas . Por outro lado, verifica-se que o aumento de capacidade de tratamento de informação pelo sistema, conjugado com o tempo ganho por determinado conjunto de funções, implicou um maior cuidado e incremento da necessidade de informação. Este é um ciclo, também ele, virtuoso: há mais informação disponível e as pessoas querem estar mais informadas. É notório o ganho daí resultante, contribuindo para que as reuniões de gestão sejam mais concisas e curtas mas, ao mesmo tempo, mais objectivas e eficazes. Pode-se dizer que no caso da Rall a implementação do ERP a organizou internamente e a preparou para responder aos desafios do mercado. Neste sentido, o ERP escolhido é fundamental para potenciar e responder à estratégia que a organização procura alcançar. Neste caso, a implementação SAP auxiliou na reestruturação dos processos de negócio .
Fruto do estudo realizado, tendo em vista a presente dissertação, deparou-se-nos uma nova realidade: na senda da maturação dos Sistemas ERP e do seu progresso em direcção à Web, evolução dos, ainda, actuais Sistemas Integrados de Gestão, que começa a surgir; o Workplace! O seu leit-motiv não é a integração, mas a colaboração. Apesar de termos procurado entender de que forma o conceito de Workplace toma lugar, nomeadamente como pode ser um instrumento para a gestão da mudança, cremos que seria importante desenvolver estudos mais focalizados e actualizados relativamente a este novo conceito.
Uma outra pista de pesquisa, que deixamos, prende-se com o eventual cruzamento, que cremos ser interessante fazer, do conceito de Workplace com um outro, relativamente recente, de ERP estendido, o ERP II.
Como afirma Patrick Thompson (CIO da Turner Industries Ltd):
“My feeling is that a company without ERP is like a Mercedes without tires – you aren’t going far without it. Extending ERP has proved to be our competitive advantage.”
VI.1 Dos Objectivos
No início do presente trabalho, estabelecemos alguns objectivos, nomeadamente:
a) Contribuir para identificar algumas das actuais ofertas de sistemas ERP presentes no mercado nacional, o seu âmbito e respectivas características.
Apesar desta ser uma vertente muito comercial, pode dizer-se que hoje em dia as diversas plataformas são muito idênticas entre si. As competências do motor central de cada um dos sistemas ERP dependem em muito da forma como cada uma delas cresceu. Algumas nasceram à volta de sistemas de produção , sendo como tal muito fortes nessa área; outros tiveram a sua génese nos processos administrativos , sendo melhores nessa área em detrimento das outras. Com excepção de algum caso que não conhecemos, as aplicações nacionais tiveram a sua génese longe “da produção”, razão pela qual alguns deles não possuem sequer este módulo. As empresas internacionais de software a operar no nosso mercado cobrem, na generalidade, toda a panóplia de processos transaccionais, fazendo, assim, depender a sua escolha mais da capacidade das equipas consultoras que do próprio software. Optámos por retratar o líder, porque é tido como o mais complexo e também porque é o sistema implantado na empresa alvo do nosso estudo.
b) Contribuir para, com recurso a um caso, retratar o processo de escolha de uma aplicação ERP numa PME.
Neste caso, o processo foi muito rápido (um mês para chegar à decisão) e teve em linha de conta pressupostos muito rígidos por parte da Gerência da Rall. A escolha foi, também colegial, pelo que deveria ter imbuído todos com o mesmo espírito. Considerámos, ao longo do trabalho, diversos critérios, os quais podem ser usados numa métrica, de forma a aligeirar e facilitar este processo.
c) Contribuir para, com recurso a um caso, retratar o processo de implementação de uma solução SAP PME.
Este processo é o mais complexo de todo o trabalho e consta do Capítulo IV do presente trabalho. Entendemos que as relações entre os indivíduos são das menos facilmente retratáveis, bem como assim, as consequências das opções tidas ao longo de um projecto como aquele que apresentámos. Esperamos, contudo, ter retratado, um pouco da complexidade que uma implementação pode acarretar.
d) Contribuir para, com recurso a um caso, confrontar a política de melhores práticas do SAP com as políticas/realidade de uma PME.
Porque se torna pouco claro de que forma as chamadas melhores práticas se impõem, em termos práticos, às organizações onde os Sistemas ERP são implementados, optámos por esclarecê-lo através do conteúdo do Anexo S, num exemplo de aconselhamento sobre uma situação específica, neste caso à posteriori, tendente a corrigir uma opção tida pela Rall durante o processo de implementação.
As melhores práticas são um Benchmarking indirecto, por via da experiência acumulada, quer da empresa de software, quer da empresa consultora.
e) Contribuir para, com recurso a um caso, identificar as alterações organizacionais que provocam a implementação de uma solução SAP numa PME, nomeadamente pela realização de um estudo da mudança que a implementação de um ERP provocou.
No caso em apreço, será interessante verificar como a gestão da mudança contribuiu de forma tão evidente para dar uma nova cara à empresa. Num arrojado projecto liderado pelos Recursos Humanos e em muito despoletado pelas necessidades que o sistema ERP veio a mostrar, a Rall passou de uma organização hierarquizada, como foi possível conhecer nos organigramas, para um “Bolograma” (termo criado por Vasco Lopes), um conceito completamente novo e inovador.
No anexo T esquematiza-se o “Bolograma” da Rall, sendo de realçar que sem a introdução do ERP dificilmente teria sido possível chegar a uma estrutura deste tipo.
f) Contribuir para tentar compreender que valor acrescentado pode uma solução SAP trazer a uma PME.
Sem entrar na disciplina de análise de valor , poderemos indicar que à semelhança das normas ISO9000, os ERP permitem alinhar a organização de acordo com práticas internacionalmente tidas como sendo de sucesso. Poderemos, ainda, perceber que o aumento da satisfação dos clientes, o desenvolvimento de novas áreas de negócio, o aumento de competitividade e a eficácia nos processos, são itens expectáveis de melhorar.
No caso presente da Rall, a implementação SAP foi não só uma ferramenta organizadora dos processos , bem como melhorou, de forma sensível, objectivos menos directos como o ciclo de fabrico ou o time to market dos produtos, ou a própria disciplina de operação. Tendo o sistema ERP como charneira não se pode alterar um processo a “nosso bel-prazer”; há que ter disciplina, portanto, organização.
Outro ponto significativo, que não se pode entender como menos nobre, é o facto do ERP instalado (neste caso SAP), ser um bom instrumento de marketing. A presença da Rall nos (melhores) Marketplaces nacionais deveu-se, objectivamente e em grande parte, ao facto de existir o SAP. A presença destes novos canais só foi possível graças à implementação de um reconhecido ERP , pois sem ele, esse caminho (ao longo do eixo do E-Business, Tab.V.1) não teria, com certeza, ocorrido, uma vez que nem a companhia estaria preparada (velho paradigma de “make to stock”) nem, tão pouco, seria reconhecida como tal.
VI.2 Dos Sistemas ERP
Do ponto de vista técnico e tecnológico, um Sistema ERP é uma ferramenta complexa e extraordinária. A sua construção, sendo bastante sólida, em virtude de uma evolução longa e consolidada, permite-lhe uma grande adaptabilidade a, praticamente, qualquer tipo de organização; quer usando os diversos módulos pré-existentes, quer através do desenvolvimento, por programação, de interfaces para cobrir as necessidades dos processos dos destinatários. A experiência contida nos Sistemas ERP, conhecida como melhores práticas, pode, também, muitas vezes, levar, aquando da implementação, a organização a ajustar os seus processos àqueles considerados como a experiência dos melhores. Da implementação base de um ERP decorre, sobretudo, a integração ao nível operacional, tendo por base processos transaccionais, os quais percorrem a organização horizontalmente, facultando um excelente nível de respostas para os seus utilizadores.
Uma vez que a oferta de soluções ERP é vasta, a decisão sobre qual deles escolher não é simples. A melhor regra, pode ser uma parceria com a entidade implementadora mas, o compromisso pessoal de todos os colaboradores envolvidos não pode ser dispensado. Por outro lado, apesar do investimento ser algo avultado, o Sistema ERP pode trazer mais valias importantes para a organização, uma vez que copia as melhores práticas do negócio, e as traduz para a realidade organizacional, ao nível das suas transacções mais básicas. Contudo, um factor não desprezível a tomar em consideração, é o alto grau de complexidade que um ERP pode implicar, seja durante o projecto de implementação, seja na fase de pós-arranque.
Uma pergunta a que este trabalho procurou responder foi: serão os ERP adaptáveis às PME? Deveremos reformular a questão, e esta resulta da nossa experiência; “estarão as PME (e os seus colaboradores) capazes de se adaptar aos processos e às melhores práticas dos ERP?”
Se a resposta for sim, então “o ERP” trará, certamente, valor acrescentado à organização e contribuirá decisivamente para alicerçar o seu presente de forma a garantir o seu futuro. Se a resposta for não, a disrupção resultante pode ser nefasta para essa mesma organização, e convirá pensar melhor sobre o investimento (tempo, recursos financeiros, recursos humanos). No caso analisado, o primeiro impacto da implementação do ERP não foi abonatório da mudança introduzida. A empresa não estava preparada nem parecia querer a mudança! Atrasos iniciais resultantes de uma falta de elasticidade interna provocaram alguns problemas que apenas movimentos contabilísticos exagerados puderam resolver, com atraso e com stress desnecessário. Apesar deste primeiro momento, ainda aquando da fase de implementação, pode-se concluir que a introdução do Sistema ERP veio acrescentar uma (e) forte disciplina de operação. O rigor com que se consegue rastrear qualquer acção dentro do SAP deixa uma porta aberta de verificação sobre qualquer acção nele realizada. Comportamentos desregrados do passado não são hoje possíveis, pois o desenho dos processos não permite grande margem de manobra.
Uma pergunta interessante, por parte de um auditor da qualidade, na Rall, pode caracterizar a mudança mental que se torna necessária introduzir nas organizações: “Como são tratados os dados obsoletos?”
Convirá entretanto esclarecer que, de acordo com as exigências da norma NP EN ISO 9001:1994 a função gestão documental tem que garantir que apenas os dados mais recentes são usados e que todos os outros se encontram segregados. Sendo assim, há um tratamento especial a considerar quanto aos obsoletos. Mas, que acontece com o SAP? Simplesmente, não há dados obsoletos, pois estão todos disponíveis concomitantemente e o sistema assegura que apenas os últimos são usados . Esta nova filosofia de encarar os dados impõe uma grande capacidade de armazenamento, mas esse é um “mal menor”, o qual pode ser garantido com tecnologia.
A introdução do ERP veio, por outro lado, quebrar algumas anteriores barreiras departamentais. Se a informação está toda disponível, e é acessível, de acordo com as permissões, então não há lugar a capelinhas . Por outro lado, verifica-se que o aumento de capacidade de tratamento de informação pelo sistema, conjugado com o tempo ganho por determinado conjunto de funções, implicou um maior cuidado e incremento da necessidade de informação. Este é um ciclo, também ele, virtuoso: há mais informação disponível e as pessoas querem estar mais informadas. É notório o ganho daí resultante, contribuindo para que as reuniões de gestão sejam mais concisas e curtas mas, ao mesmo tempo, mais objectivas e eficazes. Pode-se dizer que no caso da Rall a implementação do ERP a organizou internamente e a preparou para responder aos desafios do mercado. Neste sentido, o ERP escolhido é fundamental para potenciar e responder à estratégia que a organização procura alcançar. Neste caso, a implementação SAP auxiliou na reestruturação dos processos de negócio .
Fruto do estudo realizado, tendo em vista a presente dissertação, deparou-se-nos uma nova realidade: na senda da maturação dos Sistemas ERP e do seu progresso em direcção à Web, evolução dos, ainda, actuais Sistemas Integrados de Gestão, que começa a surgir; o Workplace! O seu leit-motiv não é a integração, mas a colaboração. Apesar de termos procurado entender de que forma o conceito de Workplace toma lugar, nomeadamente como pode ser um instrumento para a gestão da mudança, cremos que seria importante desenvolver estudos mais focalizados e actualizados relativamente a este novo conceito.
Uma outra pista de pesquisa, que deixamos, prende-se com o eventual cruzamento, que cremos ser interessante fazer, do conceito de Workplace com um outro, relativamente recente, de ERP estendido, o ERP II.
Como afirma Patrick Thompson (CIO da Turner Industries Ltd):
“My feeling is that a company without ERP is like a Mercedes without tires – you aren’t going far without it. Extending ERP has proved to be our competitive advantage.”
Capítulo V
Da Integração à Colaboração: o E-Business Workplace
A tecnologia Internet forçou as organizações a repensarem a sua arquitectura tecnológica e a dinâmica organizacional. Se a Integração ainda pode ser considerada a chave do sucesso, as empresas saudáveis, de hoje em dia, procuram a Cooperação estendida da organização. E, sendo verdade que as tecnologias Web continuam a proliferar e a tomar uma posição cada vez mais sólida, os laços desta empresa estendida tornar-se-ão mais apertados, criando modelos de negócio baseados na Colaboração, em vez da Cooperação. O movimento da integração à cooperação e à colaboração, está reflectido na evolução das diversas tecnologias que as empresas de sucesso têm vindo a abraçar. As tecnologias dos ERP integram toda a informação de cada empresa.
O que são Workplaces? Literalmente, representam uma tradução livre de algo como ‘Locais de Trabalho’. O Workplace é um local de entrada no qual um indivíduo pode aceder a informações, aplicações e serviços necessários para realizar o seu trabalho. Estes super-locais de trabalho possuem interfaces baseadas na Web, por forma a providenciarem a estes colaboradores todo o acesso que lhes permita realizarem as tarefas de um dado dia de trabalho. O colaborador não precisa de saber de onde vem e como vem a informação. Esta vem directamente até à sua ‘super’ estação de trabalho. O acesso é realizado através de um Web browser. Como afirma Hasso Plattne, co-chairman da SAP AG:
“À medida que chegamos a novas comunidades de utilizadores, esforçamo-nos cada vez mais para melhorar os aspectos de utilização dos nossos clientes. A nossa intenção é adquirir o máximo de conhecimentos sobre a experiência dos nossos clientes e dos programas para desenvolver um software que possa ser utilizado de uma forma mais fácil e intuitiva, e possa ser considerado como uma extensão natural da sua forma de trabalhar.”
Este capítulo pretende apresentar um novo conceito, o Workplace, mostrando a sua relação com o E-Business e os ERP. Assim, discute-se inicialmente a Gestão da Mudança e a sua evolução, bem como os conceitos de integração, cooperação e colaboração. No final defende-se a aliança ERP/E-Business.
V.1 A Gestão da Mudança na Era do E-Business
O conceito original de portal surge no mundo do Business to Consumer (B2C). Libertados das amarras da pesquisa de sites específicos, o portal é o ponto de partida, uma HomePage, para quando o utilizador se conecta com a Web. Um portal, pode ser ainda, uma rampa de lançamento para as auto-estradas da informação, ou uma abertura para um “sistema de cavernas”. Desde o portal, o indivíduo pode ir em diversas direcções, desde cada câmara, para um nível mais profundo ou para uma série de sub-câmeras. O próprio portal providencia chaves de como realizar a sua navegação e alguns portais podem ser, ainda, personalizados. Cada indivíduo pode modelar o seu ecrã à vontade por forma a que contenha somente a informação desejada .
Os portais empresariais são os Business to Business (B2B), equivalentes empresariais dos portais de consumo. A diferença é que, naqueles o utilizador tem uma visão única da empresa que providencia o portal. Através destes ‘Locais Virtuais de Trabalho’ (Workplaces) os indivíduos têm acesso a todas as informações, aplicações e serviços necessários para dar cumprimento ao seu trabalho. Assim:
- a Informação consiste em dados consolidados pelo sistema interno da organização, bem como de eventuais informações externas;
- as Aplicações consistem em ferramentas específicas da função;
- os Serviços consistem em assistência, providenciada e relacionada com a função, interna ou externa à organização.
Tal como se organizasse a sua secretária, também o indivíduo pode personalizar este Workplace. Apesar de poderem ser o mesmo que portais empresariais, os Workplaces exibem um certo nível de business intelligence. No Workplace os papéis de cada um definem a informação, as aplicações e os serviços disponíveis para cada indivíduo, em particular.
Na nova economia, onde a mudança é persistente, a gestão da mudança é um aspecto essencial dos negócios. Este ambiente propicia uma Gestão da Mudança a um nível distinto: a mudança está embebida no ambiente diário de trabalho. Por isso a Gestão da Mudança deve ser uma rotina diária de cada gestor e colaborador. O Workplace facilita a concretização desta visão em realidade.
Tradicionalmente, a gestão da mudança envolve mover uma organização de um ambiente para outro, tomando o caminho de menor resistência na perspectiva dos afectados pela mudança. No ambiente da tecnologia, por exemplo, uma componente chave da implementação de um sistema ERP é um programa de Gestão de Mudança concomitante desenhado por forma a fazer os utilizadores passarem de um ambiente tecnológico para outro, enquanto, ao mesmo tempo se alisam os receios acerca de como o novo sistema afectará o seu trabalho diário. Um programa destes requer conhecimento, educação e treino, PriceWaterHouseCoopers (2001).
A Gestão da Mudança focaliza-se na ajuda emocional aos utilizadores sobre a mudança de um ambiente de ‘as is’ para ‘to be’, o qual no princípio não passa de uma visão. Por tal, um programa de Gestão de Mudança requer um número apreciável de recursos, incluindo especialistas na área de Recursos Humanos, Qualidade, Marketing, Formação e, no caso de implementação de sistemas, Tecnologias de Informação, sendo composto por quatro momentos:
- mudança organizacional;
- treino;
- comunicações;
- recompensa e reconhecimento.
Para comunicar a mudança, a Gestão realiza por vezes apresentações formais, estáticas (comunicações por Email, por exemplo). Esta informação não vive muito mais que o tempo que demora a enviar, e esse não é o caminho.
V.2 Da Integração à Colaboração
As tecnologias de SCM aumentam a cooperação, através de comunicações baseadas na Internet. Os Workplaces dão lugar, às organizações, a capacidade de colaboração dentro de “redes de valor”, as quais permitem a melhoria de produtos e serviços para os seus clientes ao longo da cadeia de valor chegando, ultimamente, aos consumidores finais.
V.2.1 Fase I – Integração através dos ERP
A Integração reduz custos, à medida que os processos se estabelecem e se tornam predictíveis. Ao fundir dados, os sistemas ERP integram, levemente, toda a informação e processos dentro de uma organização. O ERP providencia dados em tempo real, normalizando um modelo central e num processo central. A integração externa com clientes e fornecedores faz-se por comunicações ponto a ponto, usando a tecnologia EDI (Electronic Data Interchange).
A implementação de um ERP pode envolver muitas alterações estruturais que podem requerer um investimento inicial apreciável. A optimização de processos e as funções do negócio requerem alterações de sistema e de configuração. Em suma, a implementação de um ERP tem o seu foco no interior, nos processos da organização.
V.2.2 Fase II – Cooperação pela SCM e comunicações baseadas na Internet
A Cooperação reduz os custos e aumenta a velocidade dos processos através da ‘empresa alargada’ e ao longo da cadeia de valor dos produtos. A cooperação aumenta a comunicação entre departamentos. Mas a cooperação requer um planeamento centralizado e uma atenção especial à gestão da cadeia de fornecimento. Se nem todos os participantes da cadeia de valor usarem o mesmo ERP e realizarem os seus processos comuns por um standard comum, muito esforço extra terá que ser feiro para ligar em conjunto, nesta empresa estendida desde fornecedores a clientes.
V.2.3 Fase III – Cooperação através de Tecnologias Avançadas
A grande diferença entre cooperação e colaboração reside no facto de, apesar de ambas poderem ocorrer em tempo real, a colaboração abrange fluxos multidireccionais e ad-hoc de dados e informação, em vez de fluxos sequenciais. A tecnologia colaborativa permite a integração aberta e flexível com comunidades de negócio. As ferramentas de colaboração são flexíveis e baseadas nos Workflows, em vez de serem rígidas e baseadas nos processos.
A Tecnologia Colaborativa – o próximo passo da revolução tecnológica do E-Business – é pedra de toque do Workplace. De certo modo impõe uma espécie de gestão centralizada da informação trocada entre os diversos actores da cadeia de valor. Aumenta o retorno pelo facto de aumentar a proximidade de relações entre os clientes, consumidores finais e outros membros da cadeia de valor, que trabalham em conjunto para o fornecimento de produtos e serviços.
V.3 A Evolução da Gestão da Mudança
No mundo dos portais empresariais e das tecnologias dos Workplaces, a Gestão da Mudança está a evoluir do especificamente orientado ao projecto em si, para uma orientação holística . Três factores contribuem para esta alteração:
- uma nova geração de utilizadores do sistema;
- a constante natureza da mudança;
- a necessidade de mudança de baixo para cima, bem como de cima para baixo.
Hoje vivemos num mundo em que a informação duplica em menos de um ano. Para aqueles da geração digital (os que estão relativamente confortáveis com a tecnologia) os ciclos de trabalho são mais curtos e mais rápidos, intensos. Para estes, a mudança tecnológica não causa um impacto tão grande quanto para com aqueles que tinha anteriormente. O medo da mudança e a apreensão quanto à solução que daí advenha é menor. Para estes colaboradores, a mudança já não representa mais ajustamentos tediosos a novos sistemas. Pelo contrário, vêem a mudança como a oportunidade para adquirirem novo pacote de qualificações. Esta nova geração de utilizadores das tecnologias de informação está por outro lado muito menos talhado para receber uma formação com um formador, no sentido clássico do termo. O método de treino passo a passo não é adequado para pessoas que desde muito novas fizeram auto-aprendizagem sobre as aplicações do computador. Torna-se necessário ter alguma atenção à formação para que se possa oferecer mais que um método de aprendizagem.
A Mudança nos dias de hoje raramente é um acontecimento único. É constante e contínua. Uma vez que a mudança é constante, as organizações deverão proporcionar um fluxo constante de informação relacionada com a mudança. A focalização da Gestão da Mudança não deve ser mais o resultado da mudança (de ‘as-is’ para ‘to-be’). Em alternativa a mudança deve ser encarada como uma característica permanente do ambiente empresarial. De facto, é “menor se se tem como objectivo atingir o ‘to-be’. Hoje em dia, assim que uma organização atinge um ‘to-be’ específico, um outro aparece no horizonte . Olhar para esta mudança contínua pelo prisma do velho paradigma pode ser stressante. Se a mudança pode ser emocionalmente esgotante, verificar constantemente que não se sai desta montanha russa pode levar as pessoas ao ponto de ruptura. Torna-se, então, necessária uma nova perspectiva, em que se olhem os negócios e as mudanças como uma célula, um organismo que se move em direcção a um estímulo (no mundo dos negócios, as oportunidades). Deste modo torna-se mais simples saber de que forma os indivíduos devem mudar, ajustar, trocar, ao mesmo tempo que a empresa aborda o próximo estímulo que se aproxima.
O modelo da mudança “de cima para baixo” já não funciona. Na nova economia os gestores devem alterar comportamentos tanto quanto aqueles que trabalham a outros níveis organizativos, devendo confiar nos seus colaboradores para gerirem as suas próprias mudanças. A inovação deve ser recompensada, e as hierarquias devem deixar de ser tão rígidas. A informação circula tão depressa que os altos responsáveis devem rejeitar a ideia de que conhecimento é poder pelo facto de ser detentor da informação. Por forma a que se alcancem os melhores resultados a informação deve ser disseminada com precisão e rapidez. Este é o sinal de inteligência empresarial. “Dar a volta” ao fluxo de informação é passá-lo para o sentido “de baixo para cima”. Este tipo de comunicação é necessário por dois motivos:
- por um lado para dar voz aqueles que pretendem contribuir para o conhecimento na organização;
- por outro, para assegurar que o topo da organização tem uma boa imagem das actividades que se passam nesta.
V.4 Nova Faceta da Mudança
A mudança é, hoje em dia, muito rápida, muito complexa e assíncrona. Cada indivíduo definido por um papel ou conjunto de papéis é afectado pela mudança de modo diverso. Assim uns mudam rapidamente e outros mais lentamente. No novo modelo de mudança, o papel de cada um muda individualmente, e os passos de mudança de cada um não são necessariamente iguais aos passos de outros. Um programa de Gestão da Mudança deverá consistir em três componentes:
- mudança organizacional;
- aprendizagem;
- comunicação.
O antigo paradigma de mudança ainda não desapareceu. A mudança ainda requer que os recursos casem com os objectivos organizacionais e suas tarefas. Contudo o Workplace oferece novas ferramentas e oportunidades para implementação da mudança. A implementação através de Workplace não só contribui com as melhores práticas (tal como o ERP), mas também fornece um entendimento dos papéis e das responsabilidades organizacionais (algo que o ERP não faz). Um papel adequa-se ao acompanhamento de um objectivo e é suportado pelos sistemas em vez de gerir processos. Cada qual deve ser convidado a tirar o maior partido da informação. Aplicações e serviços disponibilizados, para que em retorno forneça ao máximo o acompanhamento e a prossecução dos objectivos, atribuídos aos seus papéis.
A aprendizagem é um conceito muito mais alargado no ambiente dos Workplaces. Nestes, os indivíduos são alertados para o facto de a aprendizagem ser um processo contínuo ao longo da vida, e não treinos ou formações empacotadas sobre como utilizar determinada ferramenta ou aplicação. Com o ambiente de Workplace, aprender a navegar no ERP é bem mais simples que no passado, pois a navegação num ambiente Web é mais intuitivo. Neste caso a informação e a documentação estão muito mais ligadas ao treino e à formação, pois ambos focalizam num papel.
Qualquer programa de comunicação de um colaborador deve ser continuado, não deve existir somente para o momento da mudança. A comunicação não se faz projecto a projecto, mas em mecanismos de comunicação continuada. O Workplace continua a ser uma excelente ferramenta, pois permite um fluxo contínuo de informação; note-se que se torna necessária uma enorme comunicação efectiva entre a gestão e os colaboradores. E ao contrário de uma implementação de um sistema ERP, o Workplace pode estar disponível para ser usado como um mecanismo de comunicação, mesmo antes de estar configurado como o ponto de acesso à informação e aplicações ou serviços. Permite ambientar aqueles que virão a usar esta ferramenta
V.5 E-Business e o Workplace
O mundo do E-Business requer uma visão holística para ajudar as organizações a entenderem e a implementarem as mudanças necessárias para prosperarem desde um determinado ponto naquilo a que se pode chamar de panorama de E-Business.
De acordo com o modelo das “4caixas” da PriceWaterHouseCoopers, as organizações entram no E-Business usando a tecnologia baseada na Web de uma das quatro formas:
- para criarem um novo canal de vendas e marketing;
- para integrarem a Cadeia de Valor, forjando laços estreitos com parceiros caminhando no sentido da criação de redes de valor;
- para transformarem as indústrias pela criação de consórcios, marketplaces e organizações virtuais;
- para fundirem indústrias.
Na primeira, o realce do canal, a organização começa por utilizar as tecnologias Web para vender produtos e serviços beneficiando pelo aumento de competências.
Na segunda, a integração da Cadeia de Valor, as organizações colaboram com alguns dos parceiros de negócio na Web, tendo desenvolvido um nível de conhecimento com as tecnologias Web que lhes permite trabalhar diferentemente, beneficiando pela diminuição de custos e eficiências de processo.
Na terceira, a Transformação de Indústria, as organizações podem criar novos negócios e modelos organizacionais porque trabalham de outro modo. Beneficiam pela vantagem competitiva.
Na quarta, a Convergência, as organizações podem responder de forma diversa a oportunidades novas ou existentes, pois estão organizadas de forma diferente. Elas beneficiam das mudanças que elas lideram nelas mesmas.
Haverá, então, quatro respostas, ou opções estratégicas para que uma empresa actual se direccione para o E-Business :
- integrando o E-Business dentro da empresa;
- encontrando um parceiro cujo core business seja este mesmo, e como tal, que integre os produtos neste modelo;
- criando um negócio autónomo e complementar de E-Business;
- transformar completamente a empresa.
Qualquer destes modelos pode oferecer oportunidades de negócio em oito áreas diferentes de melhoria competitiva:
- aumento de eficácia;
- integração de processos;
- redução de custos;
- aumento de extensão da empresa (gama, marca, vendas);
- redução do ciclo de fabrico;
- aumento da satisfação dos clientes/consumidores;
- redução do custo das pessoas;
- aumento do retorno.
O recurso à tecnologia de Workplace numa empresa que produza bens físicos, bem como serviços, pode fazer-se em algumas etapas por forma a levá-la ao E-Business.
V.6 ERP e E-Business uma aliança com fortalecimento mútuo
Enquanto as aplicações de E-Business oferecem às organizações ferramentas para comunicar com os colaboradores e os parceiros de negócio, as aplicações ERP providenciam à organização a consolidação de dados necessários. Os ERP fornecem dados internos dos processos e operações consistentes, confiáveis, atempados e precisos. Permitem que a organização funcione efectiva e eficazmente.
A Matriz E-Business/ERP, Tabela V-1, ilustra os diferentes graus de integração interna (eixo vertical) e o panorama de E-Business (eixo horizontal). Às “4caixas” acrescentou-se um momento prévio, que é o de não ter quaisquer capacidades relativamente ao E-Business.
E-Business
Sem capacidade Realce de Integração da Transformação Convergência
de E-business canal cadeia de valor de indústria
Terreno virgem I - Começo II – Crescimento empresarial
Sistemas não integrados
Funções ERP limitadas III- Benefício do consumidor limitado IV – Alto custo versus benefício
ERP totalmente integrado Poucas opções V – Optimização do negócio
Relações empresariais ERP Pequena flexibilidade VI – Optimização empresarial
Tab.V.1 – Matriz E-Business/ERP.
Os campos que uma empresa pode ocupar ao longo da evolução do eixo dos ERP vão desde:
- o terreno virgem, i.e., numa perspectiva de Tecnologias da Informação a empresa está em branco. Pode, com sentido de oportunidade, mas com risco, fazer o caminho ao longo do eixo das “4caixas”;
- sistemas não integrados, em que a empresa não possui formas de rapidamente trocar dados entre sistemas. Este tipo de empresa está dentro de uma “caixa negra” e em processos manuais;
- funções de ERP limitadas, onde apenas alguns dos módulos do ERP terão sido instalados, mas a cadeia de valor interna ainda requer intervenção manual;
- ERP totalmente instalado; neste caso a empresa tem um potencial acrescentado ao longo do eixo de E-business para transaccionar quer com clientes, quer com fornecedores;
- Relações empresariais com base no ERP. Neste caso a empresa é capaz, através de um único interface, colocar o seu motor interno de transacções a funcionar na exacta necessidade dos conteúdos das páginas Web, por forma a não ter só um front end de fachada, mas algo que realmente interaja com as actividades de back-office.
O agrupamento na matriz em seis áreas com características similares (eixo E-business) corresponde:
I – Organizações novas, sem grandes sistemas;
II – Estas organizações ainda não investiram o suficiente em back-office, pelo que o seu crescimento é limitado;
III – Estas empresas investem mais nas aplicações de back-office, pelo que limitarão as suas opções e como tal limitam os ganhos que poderiam advir da Web, quer para eles quer para os seus parceiros;
IV – Neste caso trata-se de empresas que explorando as tecnologias Web, ainda não dispõem de um bom sistema de back-office, pelo que a informação, dentro da empresa ou para com os parceiros não flui;
V e VI – A sua Internet e o back-office estão optimizados, “conversando” entre si em benefício da empresa e parceiros.
Assim sendo qual o caminho a tomar, para aquelas empresas que pretendam vir a atingir um estado de colaboração com os seus parceiros, e porque não referí-lo como os seus colaboradores?
De acordo com a PriceWaterHouseCoopers, o caminho que deve ser tido em conta requer quatro passos:
- Passo 1: começar por determinar qual o posicionamento actual da empresa, com base na estratégia de negócio e as suas opções tecnológicas;
- Passo 2: incrementar capacidades à empresa relativamente à tecnologia, processos, colaboradores e parceiros de negócio;
- Passo 3: compreender que existem múltiplos caminhos de migração (eixo do ERP ou eixo do E-business, ou ambos);
- Passo 4: escolher o melhor caminho para realizar o passo anterior (realista, claro e que se possa gerir).
V.7 Conclusão
O Workplace pode ser um factor distintivo e, sobretudo capaz de fornecer vantagem competitiva. Por outro lado, o front end não distingue grandes ou pequenas empresas, sendo por tal um factor unificador do ponto de vista do consumidor. Para este, tanto as grandes como as pequenas empresas são vistas, transparentemente, idênticas.
Se bem que estejamos cientes que muitas vezes estes modelos se direccionam mais às grandes organizações, de nível global, que às PME portuguesas, é nosso entendimento que grande parte da lição dever ser tomada em conta, peso e medida, atendendo a factores pragmáticos, de mais curto prazo mas também a factores estratégicos, de mais longo alcance.
Ao contrário de soluções anteriores, o Workplace é uma oportunidade de ouro de fazer chegar informação pertinente ao proprietário de um determinado papel na organização: filtrando a informação, pois elimina a necessidade do indivíduo se perder em montanhas de informação; sendo flexível, uma vez que mesmo que os papéis se alterem, o sistema continua a ser relevante, fácil de navegar e útil.
Em resumo, o Workplace coloca o indivíduo verdadeiramente informado pelo sistema que usa, tornando o seu trabalho mais interessante, produtivo e satisfatório; assim, melhora a vida daqueles que o usam.
Parafraseando Miguel Costa (presidente da Siemens Business Service), em entrevista recentemente publicada e, relativamente à gestão do conhecimento:
“Ao longo de muitos anos, grande tem sido o investimento ao nível monetário, de tempo e de energia por forma a melhorar a informação que as pessoas necessitam para a realização dos seus trabalhos.”
Façamos, pois, desse investimento, um investimento de sucesso.
A tecnologia Internet forçou as organizações a repensarem a sua arquitectura tecnológica e a dinâmica organizacional. Se a Integração ainda pode ser considerada a chave do sucesso, as empresas saudáveis, de hoje em dia, procuram a Cooperação estendida da organização. E, sendo verdade que as tecnologias Web continuam a proliferar e a tomar uma posição cada vez mais sólida, os laços desta empresa estendida tornar-se-ão mais apertados, criando modelos de negócio baseados na Colaboração, em vez da Cooperação. O movimento da integração à cooperação e à colaboração, está reflectido na evolução das diversas tecnologias que as empresas de sucesso têm vindo a abraçar. As tecnologias dos ERP integram toda a informação de cada empresa.
O que são Workplaces? Literalmente, representam uma tradução livre de algo como ‘Locais de Trabalho’. O Workplace é um local de entrada no qual um indivíduo pode aceder a informações, aplicações e serviços necessários para realizar o seu trabalho. Estes super-locais de trabalho possuem interfaces baseadas na Web, por forma a providenciarem a estes colaboradores todo o acesso que lhes permita realizarem as tarefas de um dado dia de trabalho. O colaborador não precisa de saber de onde vem e como vem a informação. Esta vem directamente até à sua ‘super’ estação de trabalho. O acesso é realizado através de um Web browser. Como afirma Hasso Plattne, co-chairman da SAP AG:
“À medida que chegamos a novas comunidades de utilizadores, esforçamo-nos cada vez mais para melhorar os aspectos de utilização dos nossos clientes. A nossa intenção é adquirir o máximo de conhecimentos sobre a experiência dos nossos clientes e dos programas para desenvolver um software que possa ser utilizado de uma forma mais fácil e intuitiva, e possa ser considerado como uma extensão natural da sua forma de trabalhar.”
Este capítulo pretende apresentar um novo conceito, o Workplace, mostrando a sua relação com o E-Business e os ERP. Assim, discute-se inicialmente a Gestão da Mudança e a sua evolução, bem como os conceitos de integração, cooperação e colaboração. No final defende-se a aliança ERP/E-Business.
V.1 A Gestão da Mudança na Era do E-Business
O conceito original de portal surge no mundo do Business to Consumer (B2C). Libertados das amarras da pesquisa de sites específicos, o portal é o ponto de partida, uma HomePage, para quando o utilizador se conecta com a Web. Um portal, pode ser ainda, uma rampa de lançamento para as auto-estradas da informação, ou uma abertura para um “sistema de cavernas”. Desde o portal, o indivíduo pode ir em diversas direcções, desde cada câmara, para um nível mais profundo ou para uma série de sub-câmeras. O próprio portal providencia chaves de como realizar a sua navegação e alguns portais podem ser, ainda, personalizados. Cada indivíduo pode modelar o seu ecrã à vontade por forma a que contenha somente a informação desejada .
Os portais empresariais são os Business to Business (B2B), equivalentes empresariais dos portais de consumo. A diferença é que, naqueles o utilizador tem uma visão única da empresa que providencia o portal. Através destes ‘Locais Virtuais de Trabalho’ (Workplaces) os indivíduos têm acesso a todas as informações, aplicações e serviços necessários para dar cumprimento ao seu trabalho. Assim:
- a Informação consiste em dados consolidados pelo sistema interno da organização, bem como de eventuais informações externas;
- as Aplicações consistem em ferramentas específicas da função;
- os Serviços consistem em assistência, providenciada e relacionada com a função, interna ou externa à organização.
Tal como se organizasse a sua secretária, também o indivíduo pode personalizar este Workplace. Apesar de poderem ser o mesmo que portais empresariais, os Workplaces exibem um certo nível de business intelligence. No Workplace os papéis de cada um definem a informação, as aplicações e os serviços disponíveis para cada indivíduo, em particular.
Na nova economia, onde a mudança é persistente, a gestão da mudança é um aspecto essencial dos negócios. Este ambiente propicia uma Gestão da Mudança a um nível distinto: a mudança está embebida no ambiente diário de trabalho. Por isso a Gestão da Mudança deve ser uma rotina diária de cada gestor e colaborador. O Workplace facilita a concretização desta visão em realidade.
Tradicionalmente, a gestão da mudança envolve mover uma organização de um ambiente para outro, tomando o caminho de menor resistência na perspectiva dos afectados pela mudança. No ambiente da tecnologia, por exemplo, uma componente chave da implementação de um sistema ERP é um programa de Gestão de Mudança concomitante desenhado por forma a fazer os utilizadores passarem de um ambiente tecnológico para outro, enquanto, ao mesmo tempo se alisam os receios acerca de como o novo sistema afectará o seu trabalho diário. Um programa destes requer conhecimento, educação e treino, PriceWaterHouseCoopers (2001).
A Gestão da Mudança focaliza-se na ajuda emocional aos utilizadores sobre a mudança de um ambiente de ‘as is’ para ‘to be’, o qual no princípio não passa de uma visão. Por tal, um programa de Gestão de Mudança requer um número apreciável de recursos, incluindo especialistas na área de Recursos Humanos, Qualidade, Marketing, Formação e, no caso de implementação de sistemas, Tecnologias de Informação, sendo composto por quatro momentos:
- mudança organizacional;
- treino;
- comunicações;
- recompensa e reconhecimento.
Para comunicar a mudança, a Gestão realiza por vezes apresentações formais, estáticas (comunicações por Email, por exemplo). Esta informação não vive muito mais que o tempo que demora a enviar, e esse não é o caminho.
V.2 Da Integração à Colaboração
As tecnologias de SCM aumentam a cooperação, através de comunicações baseadas na Internet. Os Workplaces dão lugar, às organizações, a capacidade de colaboração dentro de “redes de valor”, as quais permitem a melhoria de produtos e serviços para os seus clientes ao longo da cadeia de valor chegando, ultimamente, aos consumidores finais.
V.2.1 Fase I – Integração através dos ERP
A Integração reduz custos, à medida que os processos se estabelecem e se tornam predictíveis. Ao fundir dados, os sistemas ERP integram, levemente, toda a informação e processos dentro de uma organização. O ERP providencia dados em tempo real, normalizando um modelo central e num processo central. A integração externa com clientes e fornecedores faz-se por comunicações ponto a ponto, usando a tecnologia EDI (Electronic Data Interchange).
A implementação de um ERP pode envolver muitas alterações estruturais que podem requerer um investimento inicial apreciável. A optimização de processos e as funções do negócio requerem alterações de sistema e de configuração. Em suma, a implementação de um ERP tem o seu foco no interior, nos processos da organização.
V.2.2 Fase II – Cooperação pela SCM e comunicações baseadas na Internet
A Cooperação reduz os custos e aumenta a velocidade dos processos através da ‘empresa alargada’ e ao longo da cadeia de valor dos produtos. A cooperação aumenta a comunicação entre departamentos. Mas a cooperação requer um planeamento centralizado e uma atenção especial à gestão da cadeia de fornecimento. Se nem todos os participantes da cadeia de valor usarem o mesmo ERP e realizarem os seus processos comuns por um standard comum, muito esforço extra terá que ser feiro para ligar em conjunto, nesta empresa estendida desde fornecedores a clientes.
V.2.3 Fase III – Cooperação através de Tecnologias Avançadas
A grande diferença entre cooperação e colaboração reside no facto de, apesar de ambas poderem ocorrer em tempo real, a colaboração abrange fluxos multidireccionais e ad-hoc de dados e informação, em vez de fluxos sequenciais. A tecnologia colaborativa permite a integração aberta e flexível com comunidades de negócio. As ferramentas de colaboração são flexíveis e baseadas nos Workflows, em vez de serem rígidas e baseadas nos processos.
A Tecnologia Colaborativa – o próximo passo da revolução tecnológica do E-Business – é pedra de toque do Workplace. De certo modo impõe uma espécie de gestão centralizada da informação trocada entre os diversos actores da cadeia de valor. Aumenta o retorno pelo facto de aumentar a proximidade de relações entre os clientes, consumidores finais e outros membros da cadeia de valor, que trabalham em conjunto para o fornecimento de produtos e serviços.
V.3 A Evolução da Gestão da Mudança
No mundo dos portais empresariais e das tecnologias dos Workplaces, a Gestão da Mudança está a evoluir do especificamente orientado ao projecto em si, para uma orientação holística . Três factores contribuem para esta alteração:
- uma nova geração de utilizadores do sistema;
- a constante natureza da mudança;
- a necessidade de mudança de baixo para cima, bem como de cima para baixo.
Hoje vivemos num mundo em que a informação duplica em menos de um ano. Para aqueles da geração digital (os que estão relativamente confortáveis com a tecnologia) os ciclos de trabalho são mais curtos e mais rápidos, intensos. Para estes, a mudança tecnológica não causa um impacto tão grande quanto para com aqueles que tinha anteriormente. O medo da mudança e a apreensão quanto à solução que daí advenha é menor. Para estes colaboradores, a mudança já não representa mais ajustamentos tediosos a novos sistemas. Pelo contrário, vêem a mudança como a oportunidade para adquirirem novo pacote de qualificações. Esta nova geração de utilizadores das tecnologias de informação está por outro lado muito menos talhado para receber uma formação com um formador, no sentido clássico do termo. O método de treino passo a passo não é adequado para pessoas que desde muito novas fizeram auto-aprendizagem sobre as aplicações do computador. Torna-se necessário ter alguma atenção à formação para que se possa oferecer mais que um método de aprendizagem.
A Mudança nos dias de hoje raramente é um acontecimento único. É constante e contínua. Uma vez que a mudança é constante, as organizações deverão proporcionar um fluxo constante de informação relacionada com a mudança. A focalização da Gestão da Mudança não deve ser mais o resultado da mudança (de ‘as-is’ para ‘to-be’). Em alternativa a mudança deve ser encarada como uma característica permanente do ambiente empresarial. De facto, é “menor se se tem como objectivo atingir o ‘to-be’. Hoje em dia, assim que uma organização atinge um ‘to-be’ específico, um outro aparece no horizonte . Olhar para esta mudança contínua pelo prisma do velho paradigma pode ser stressante. Se a mudança pode ser emocionalmente esgotante, verificar constantemente que não se sai desta montanha russa pode levar as pessoas ao ponto de ruptura. Torna-se, então, necessária uma nova perspectiva, em que se olhem os negócios e as mudanças como uma célula, um organismo que se move em direcção a um estímulo (no mundo dos negócios, as oportunidades). Deste modo torna-se mais simples saber de que forma os indivíduos devem mudar, ajustar, trocar, ao mesmo tempo que a empresa aborda o próximo estímulo que se aproxima.
O modelo da mudança “de cima para baixo” já não funciona. Na nova economia os gestores devem alterar comportamentos tanto quanto aqueles que trabalham a outros níveis organizativos, devendo confiar nos seus colaboradores para gerirem as suas próprias mudanças. A inovação deve ser recompensada, e as hierarquias devem deixar de ser tão rígidas. A informação circula tão depressa que os altos responsáveis devem rejeitar a ideia de que conhecimento é poder pelo facto de ser detentor da informação. Por forma a que se alcancem os melhores resultados a informação deve ser disseminada com precisão e rapidez. Este é o sinal de inteligência empresarial. “Dar a volta” ao fluxo de informação é passá-lo para o sentido “de baixo para cima”. Este tipo de comunicação é necessário por dois motivos:
- por um lado para dar voz aqueles que pretendem contribuir para o conhecimento na organização;
- por outro, para assegurar que o topo da organização tem uma boa imagem das actividades que se passam nesta.
V.4 Nova Faceta da Mudança
A mudança é, hoje em dia, muito rápida, muito complexa e assíncrona. Cada indivíduo definido por um papel ou conjunto de papéis é afectado pela mudança de modo diverso. Assim uns mudam rapidamente e outros mais lentamente. No novo modelo de mudança, o papel de cada um muda individualmente, e os passos de mudança de cada um não são necessariamente iguais aos passos de outros. Um programa de Gestão da Mudança deverá consistir em três componentes:
- mudança organizacional;
- aprendizagem;
- comunicação.
O antigo paradigma de mudança ainda não desapareceu. A mudança ainda requer que os recursos casem com os objectivos organizacionais e suas tarefas. Contudo o Workplace oferece novas ferramentas e oportunidades para implementação da mudança. A implementação através de Workplace não só contribui com as melhores práticas (tal como o ERP), mas também fornece um entendimento dos papéis e das responsabilidades organizacionais (algo que o ERP não faz). Um papel adequa-se ao acompanhamento de um objectivo e é suportado pelos sistemas em vez de gerir processos. Cada qual deve ser convidado a tirar o maior partido da informação. Aplicações e serviços disponibilizados, para que em retorno forneça ao máximo o acompanhamento e a prossecução dos objectivos, atribuídos aos seus papéis.
A aprendizagem é um conceito muito mais alargado no ambiente dos Workplaces. Nestes, os indivíduos são alertados para o facto de a aprendizagem ser um processo contínuo ao longo da vida, e não treinos ou formações empacotadas sobre como utilizar determinada ferramenta ou aplicação. Com o ambiente de Workplace, aprender a navegar no ERP é bem mais simples que no passado, pois a navegação num ambiente Web é mais intuitivo. Neste caso a informação e a documentação estão muito mais ligadas ao treino e à formação, pois ambos focalizam num papel.
Qualquer programa de comunicação de um colaborador deve ser continuado, não deve existir somente para o momento da mudança. A comunicação não se faz projecto a projecto, mas em mecanismos de comunicação continuada. O Workplace continua a ser uma excelente ferramenta, pois permite um fluxo contínuo de informação; note-se que se torna necessária uma enorme comunicação efectiva entre a gestão e os colaboradores. E ao contrário de uma implementação de um sistema ERP, o Workplace pode estar disponível para ser usado como um mecanismo de comunicação, mesmo antes de estar configurado como o ponto de acesso à informação e aplicações ou serviços. Permite ambientar aqueles que virão a usar esta ferramenta
V.5 E-Business e o Workplace
O mundo do E-Business requer uma visão holística para ajudar as organizações a entenderem e a implementarem as mudanças necessárias para prosperarem desde um determinado ponto naquilo a que se pode chamar de panorama de E-Business.
De acordo com o modelo das “4caixas” da PriceWaterHouseCoopers, as organizações entram no E-Business usando a tecnologia baseada na Web de uma das quatro formas:
- para criarem um novo canal de vendas e marketing;
- para integrarem a Cadeia de Valor, forjando laços estreitos com parceiros caminhando no sentido da criação de redes de valor;
- para transformarem as indústrias pela criação de consórcios, marketplaces e organizações virtuais;
- para fundirem indústrias.
Na primeira, o realce do canal, a organização começa por utilizar as tecnologias Web para vender produtos e serviços beneficiando pelo aumento de competências.
Na segunda, a integração da Cadeia de Valor, as organizações colaboram com alguns dos parceiros de negócio na Web, tendo desenvolvido um nível de conhecimento com as tecnologias Web que lhes permite trabalhar diferentemente, beneficiando pela diminuição de custos e eficiências de processo.
Na terceira, a Transformação de Indústria, as organizações podem criar novos negócios e modelos organizacionais porque trabalham de outro modo. Beneficiam pela vantagem competitiva.
Na quarta, a Convergência, as organizações podem responder de forma diversa a oportunidades novas ou existentes, pois estão organizadas de forma diferente. Elas beneficiam das mudanças que elas lideram nelas mesmas.
Haverá, então, quatro respostas, ou opções estratégicas para que uma empresa actual se direccione para o E-Business :
- integrando o E-Business dentro da empresa;
- encontrando um parceiro cujo core business seja este mesmo, e como tal, que integre os produtos neste modelo;
- criando um negócio autónomo e complementar de E-Business;
- transformar completamente a empresa.
Qualquer destes modelos pode oferecer oportunidades de negócio em oito áreas diferentes de melhoria competitiva:
- aumento de eficácia;
- integração de processos;
- redução de custos;
- aumento de extensão da empresa (gama, marca, vendas);
- redução do ciclo de fabrico;
- aumento da satisfação dos clientes/consumidores;
- redução do custo das pessoas;
- aumento do retorno.
O recurso à tecnologia de Workplace numa empresa que produza bens físicos, bem como serviços, pode fazer-se em algumas etapas por forma a levá-la ao E-Business.
V.6 ERP e E-Business uma aliança com fortalecimento mútuo
Enquanto as aplicações de E-Business oferecem às organizações ferramentas para comunicar com os colaboradores e os parceiros de negócio, as aplicações ERP providenciam à organização a consolidação de dados necessários. Os ERP fornecem dados internos dos processos e operações consistentes, confiáveis, atempados e precisos. Permitem que a organização funcione efectiva e eficazmente.
A Matriz E-Business/ERP, Tabela V-1, ilustra os diferentes graus de integração interna (eixo vertical) e o panorama de E-Business (eixo horizontal). Às “4caixas” acrescentou-se um momento prévio, que é o de não ter quaisquer capacidades relativamente ao E-Business.
E-Business
Sem capacidade Realce de Integração da Transformação Convergência
de E-business canal cadeia de valor de indústria
Terreno virgem I - Começo II – Crescimento empresarial
Sistemas não integrados
Funções ERP limitadas III- Benefício do consumidor limitado IV – Alto custo versus benefício
ERP totalmente integrado Poucas opções V – Optimização do negócio
Relações empresariais ERP Pequena flexibilidade VI – Optimização empresarial
Tab.V.1 – Matriz E-Business/ERP.
Os campos que uma empresa pode ocupar ao longo da evolução do eixo dos ERP vão desde:
- o terreno virgem, i.e., numa perspectiva de Tecnologias da Informação a empresa está em branco. Pode, com sentido de oportunidade, mas com risco, fazer o caminho ao longo do eixo das “4caixas”;
- sistemas não integrados, em que a empresa não possui formas de rapidamente trocar dados entre sistemas. Este tipo de empresa está dentro de uma “caixa negra” e em processos manuais;
- funções de ERP limitadas, onde apenas alguns dos módulos do ERP terão sido instalados, mas a cadeia de valor interna ainda requer intervenção manual;
- ERP totalmente instalado; neste caso a empresa tem um potencial acrescentado ao longo do eixo de E-business para transaccionar quer com clientes, quer com fornecedores;
- Relações empresariais com base no ERP. Neste caso a empresa é capaz, através de um único interface, colocar o seu motor interno de transacções a funcionar na exacta necessidade dos conteúdos das páginas Web, por forma a não ter só um front end de fachada, mas algo que realmente interaja com as actividades de back-office.
O agrupamento na matriz em seis áreas com características similares (eixo E-business) corresponde:
I – Organizações novas, sem grandes sistemas;
II – Estas organizações ainda não investiram o suficiente em back-office, pelo que o seu crescimento é limitado;
III – Estas empresas investem mais nas aplicações de back-office, pelo que limitarão as suas opções e como tal limitam os ganhos que poderiam advir da Web, quer para eles quer para os seus parceiros;
IV – Neste caso trata-se de empresas que explorando as tecnologias Web, ainda não dispõem de um bom sistema de back-office, pelo que a informação, dentro da empresa ou para com os parceiros não flui;
V e VI – A sua Internet e o back-office estão optimizados, “conversando” entre si em benefício da empresa e parceiros.
Assim sendo qual o caminho a tomar, para aquelas empresas que pretendam vir a atingir um estado de colaboração com os seus parceiros, e porque não referí-lo como os seus colaboradores?
De acordo com a PriceWaterHouseCoopers, o caminho que deve ser tido em conta requer quatro passos:
- Passo 1: começar por determinar qual o posicionamento actual da empresa, com base na estratégia de negócio e as suas opções tecnológicas;
- Passo 2: incrementar capacidades à empresa relativamente à tecnologia, processos, colaboradores e parceiros de negócio;
- Passo 3: compreender que existem múltiplos caminhos de migração (eixo do ERP ou eixo do E-business, ou ambos);
- Passo 4: escolher o melhor caminho para realizar o passo anterior (realista, claro e que se possa gerir).
V.7 Conclusão
O Workplace pode ser um factor distintivo e, sobretudo capaz de fornecer vantagem competitiva. Por outro lado, o front end não distingue grandes ou pequenas empresas, sendo por tal um factor unificador do ponto de vista do consumidor. Para este, tanto as grandes como as pequenas empresas são vistas, transparentemente, idênticas.
Se bem que estejamos cientes que muitas vezes estes modelos se direccionam mais às grandes organizações, de nível global, que às PME portuguesas, é nosso entendimento que grande parte da lição dever ser tomada em conta, peso e medida, atendendo a factores pragmáticos, de mais curto prazo mas também a factores estratégicos, de mais longo alcance.
Ao contrário de soluções anteriores, o Workplace é uma oportunidade de ouro de fazer chegar informação pertinente ao proprietário de um determinado papel na organização: filtrando a informação, pois elimina a necessidade do indivíduo se perder em montanhas de informação; sendo flexível, uma vez que mesmo que os papéis se alterem, o sistema continua a ser relevante, fácil de navegar e útil.
Em resumo, o Workplace coloca o indivíduo verdadeiramente informado pelo sistema que usa, tornando o seu trabalho mais interessante, produtivo e satisfatório; assim, melhora a vida daqueles que o usam.
Parafraseando Miguel Costa (presidente da Siemens Business Service), em entrevista recentemente publicada e, relativamente à gestão do conhecimento:
“Ao longo de muitos anos, grande tem sido o investimento ao nível monetário, de tempo e de energia por forma a melhorar a informação que as pessoas necessitam para a realização dos seus trabalhos.”
Façamos, pois, desse investimento, um investimento de sucesso.
Capítulo IV
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.
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.
