abordagem para optimização da parametrização de erps em
TRANSCRIPT
Abordagem para Optimizar a Parametrização de ERPs em Projectos
de Rollout
CAPSI’2011
André Barbosa 1, Carlos Costa
2
1) ISCTE-IUL, Lisboa, Portugal
2) ISCTE-IUL, Lisboa, Portugal
Resumo
Embora um projecto de rollout se centre na aplicação de uma solução tecnológica, já
implementada numa organização, a uma das suas subsidiárias ou a uma nova organização
por si adquirida com perfil de actividades semelhante, existem sempre especificidades
destes "novos clientes" que a solução terá de comportar. Estes requisitos podem exigir um
alinhamento entre a empresa e o sistema, quer a nível processual, quer a nível dos dados e
sua estrutura. Dentro desta última vertente, a parametrização é uma forma de adaptação que
garante esse ajustamento, através da determinação de um conjunto de parâmetros no
sistema, sem qualquer intervenção no seu código fonte. É na definição destes valores que
assenta este artigo, no qual é apresentada uma nova abordagem que permite optimizar a
parametrização de dados em ERPs, no âmbito de projectos de rollout. Esta abordagem irá
centrar-se no desenvolvimento de templates, construídos com base em técnicas de
levantamento e análise requisitos, modelação de sistemas e engenharia inversa.
Palavras chave: ERP-Enterprise Resource Planning, Parametrização, Rollout, Levantamento e
Análise de Requisitos, Modelação de Sistemas, Engenharia Inversa, Templates.
1. Introdução
Um sistema ERP é um pacote de software utilizado para coordenar informação, de forma
integrada, entre diferentes áreas funcionais de uma organização [Davenport 1998]. Os dados são
registados uma única vez no sistema, ficando visíveis para o seu todo. A gestão de processos de
negócio é assegurada através de uma base de dados comum e de uma gestão partilhada de
ferramentas de report [Monk et al. 2009].
A metodologia de rollout é uma forma de implementação de um ERP [Welti 1999]. Esta aplica-
se no caso em que existe uma implementação final de um sistema numa organização e vai
proceder-se ao seu alargamento a outras organizações com o mesmo perfil de actividade
[Drelichowski et al. 2009]. Esta ampliação pode ocorrer num único momento (big-bang) ou em
várias fases, cada uma abarcando um conjunto de organizações [D'Souza et al. 2005].
A utilização de uma metodologia de rollout permite a standardização dos processos de negócio
dentro de uma organização ou grupo empresarial, conseguindo-o com uma poupança em termos
de custos monetários e com uma aceleração na implementação da maioria das tarefas de
projecto [Brown et al. 2003, Drelichowski et al. 2009]. Apesar desta unificação, os custos de
adaptação necessários não são totalmente eliminados, pois existem sempre alguns requisitos
específicos da nova organização que terão de ser acomodados no sistema [Drelichowski et al.
2009]. Desse levantamento, denominado fit-gap analysis, podem resultar adaptações
essencialmente em dois níveis: em termos processuais e/ou em termos de dados e sua estrutura
[Hu et al. 2008]. Embora estejam estreitamente relacionadas, este artigo apenas abordará a
última vertente, expondo o desenvolvimento de uma nova abordagem de parametrização de
ERPs, no âmbito de rollouts.
Por parametrização (ou configuração) entende-se a definição e selecção de parâmetros ou
valores do sistema (sem acção no código), de modo a assegurar o ajustamento do mesmo às
especificidades da organização [Glass 1998, Valentim 2010]. Note-se que este conceito
distingue-se do conceito de customização, o qual não será explorado nesta abordagem e que
implica intervenção no código fonte, quer através de modificação directa, quer através de pontos
de extensão, de forma a complementar funções do sistema [Glass 1998, Rothenberger et al.
2009].
A abordagem proposta com este artigo irá concretizar-se num template de parametrização, que
será construído com base em técnicas de levantamento e análise de requisitos, modelação de
sistemas, assim como no conceito de engenharia inversa. Com a sua aplicação, pretende-se obter
um processo de parametrização de dados optimizado e padronizado.
De forma a validar a sua utilidade e consistência, esta abordagem será ainda testada num
contexto real. Esse contexto será a gestão de serviços partilhados da Administração Pública
Portuguesa, em concreto o sistema de gestão de recursos humanos, ERP SAP RH, que após uma
implementação inicial em que integrará cinco organismos piloto, seguirá uma metodologia de
rollout, de modo a alargar-se progressivamente ao restante sector público. Após a sua aplicação,
a abordagem será avaliada, através de entrevistas a informadores chave.
Nesse sentido, este documento, após esta introdução, será composto por mais cinco divisões: a
revisão da literatura sobre os conceitos relacionados com a abordagem a propor (secção 2); a
apresentação dessa mesma abordagem (secção 3); a aplicação desta ao contexto prático
mencionado (secção 4); a sua avaliação (preliminar) por especialistas (secção 5); a exposição de
um conjunto de conclusões, bem como limitações e sugestões de trabalhos futuros (secção 6).
2. Revisão da Literatura
Este tópico tem por objectivo expor o estado actual do conhecimento sobre as temáticas
subjacentes à proposta conceptual. Desse modo, serão abordadas as seguintes matérias:
Levantamento e Análise de Requisitos;
Modelação de Sistemas;
Engenharia Inversa;
Templates para Rollouts de ERPs.
2.1. Levantamento e Análise de Requisitos
Um requisito [Young 2004] pode ser classificado, essencialmente, em duas vertentes:
Requisitos do utilizador / sistema [Sommerville 2006];
Requisitos funcionais / não funcionais / restrições [Robertson et al. 2006, Young 2004].
O levantamento e análise de requisitos é uma etapa nuclear no processo de engenharia de
requisitos [Sommerville 2006], podendo ser utilizadas diversas técnicas para a sua execução
[Belgamo et al. 2000, Bevan et al. 2002, Lloyd 2001, Sommerville 2006]. Entre elas encontram-
se os cenários [Bevan et al. 2002] e os casos de uso [Jacobson 1992], que privilegiam a
interacção dos diferentes actores externos com sistema, focando-se no pensamento efectivo
sobre a utilização do mesmo no contexto de negócio associado.
Embora ainda subsista alguma confusão entre os conceitos de casos de uso e cenários, Jacobson
[1994] defende que um cenário deve ser encarado como uma instância específica de um caso de
uso. Esta ideia é corroborada por Cockburn [2000], na sua abordagem orientada por objectivos,
a qual engloba ambas as técnicas.
O aparecimento da UML - Unified Modeling Language tornou possível a representação gráfica
da visão externa do sistema e das suas interacções com o exterior, através de diagramas de casos
de uso [Booch et al. 2005, Furlan 1998, Somé 2006, Vedoato 2003]. Contudo, aquando da sua
utilização, os casos de uso deixam de ter em conta o conceito de usabilidade, podendo este ser
recuperado através da complementaridade com a técnica de cenários [Constantine et al. 2001,
Vedoato 2003].
2.2. Modelação de Sistemas
A modelação de sistemas consiste na construção de representações abstractas que forneçam um
correcto entendimento de sistemas existentes ou auxiliem a especificação de um novo sistema
[Easterbrook et al. 2000, Sommerville 2006]. Para tal objectivo, podem ser utilizados diferentes
tipos de modelos, entre os quais:
Modelos comportamentais – Reflectem o comportamento do sistema (exemplos:
modelos de fluxos de dados ou modelos de transição de estados) [Sommerville 2006];
Modelos de dados – Representam a forma lógica dos dados processados pelo sistema
(exemplos: modelos ERA - Entity-Relation-Attribute) [Korth et al. 2010, Sommerville
2006};
Modelos orientados a objectos – Representam os dados do sistema, bem como o seu
processamento, resultando numa combinação de modelos de dados semânticos e
modelos comportamentais (exemplos: modelos UML, nomeadamente diagrama de
classes UML – dados e o diagrama de actividades UML – comportamento) [Nunes et al.
2004, Sommerville 2006].
Os modelos orientados a objectos têm, hoje em dia, uma grande taxa de utilização [Sommerville
2006], fornecendo, através da linguagem UML (standard neste tipo de modelação), um
sustentado apoio à etapa de levantamento e análise de requisitos [Berenbach 2004]. Por
exemplo, os diagramas de actividades UML podem tornar-se uma mais-valia quando se
pretende detalhar um caso de uso associado a um processo de negócio ou ainda descrever fluxo
de interacção em cenários específicos, fornecendo assim uma representação gráfica
complementar a uma abordagem de análise de requisitos baseada em casos de uso / cenários
[Pressman 2009].
Os modelos comportamentais e de dados orientados a objectos assumem ainda um papel
importante na definição de casos de teste, existindo já metodologias para a sua geração a partir
de um diagrama de actividades UML [Kundu et al. 2009] ou de um diagrama de classes UML
[Chandran et al. 2009].
2.3. Engenharia Inversa
Segundo Chikofsky e Cross II [1990], a engenharia inversa é o processo de análise de um
sistema de modo a:
Identificar os seus componentes e as relações/dependências que estes estabelecem;
Gerar visões alternativas e sintetizar representações usando um alto nível de abstracção.
As representações do sistema poderão ser úteis na reconstrução do desenho ou na especificação
de requisitos, particularmente quando a documentação está em falta ou desactualizada [Müller
et al. 1995].
A engenharia inversa pode separar-se em dois grupos: engenharia inversa do código ou
programa e engenharia inversa de dados [Englebert et al. 2000, Jahnke et al. 2000a]. Apenas o
último será objecto da proposta conceptual apresentada neste artigo.
A engenharia inversa de dados é o conjunto de métodos e ferramentas que ajudam a organização
a determinar a estrutura, função e significado dos seus dados [Aiken 1996]. Para aplicar esta
abordagem, existem duas tarefas fundamentais [Jahnke et al. 2000a]:
Análise dos dados - Recuperar o modelo de dados lógico estruturalmente completo e
com a semântica anotada Os responsáveis pelo desenvolvimento e os especialistas do
domínio podem, com o seu conhecimento e experiência, apresentar-se como um factor
crítico de sucesso desta tarefa;
Abstracção conceptual – Efectuar o mapeamento entre o modelo de dados lógico
resultante da análise e o equivalente desenho conceptual, usualmente representado
através de diagramas ERA ou diagramas de classes UML.
Embora Jahnke et al. [2000a] enumere alguns factores que impeçam uma resposta efectiva, por
parte de soluções tecnológicas, às etapas acima mencionadas, existem já ferramentas que se
encaminham para ultrapassar estas questões. Por exemplo, a ferramenta Varlet consegue
auxiliar as etapas de análise e abstracção, recorrendo, respectivamente, às técnicas Generic
Fuzzy Reasoning Nets e Triple Graph Grammars [Jahnke et al. 1998, Jahnke et al. 2000b].
Também as ferramentas Rational Rose (IBM) e Together (Borland) providenciam a recuperação
do modelo conceptual a partir da análise do código fonte [Maciel 2003, Sun et al. 2005].
2.4. Templates para Rollouts de ERPs
A expansão dos sistemas ERP, durante a última década, aumentou as necessidades de integração
interna, principalmente porque estes começaram a ser estendidos a parceiros das próprias
organizações. A configuração individual dos sistemas, com processos e dados mestre a serem
criados de forma diferente, têm dificultado essa mesma integração [Alt et al. 2000].
Templates para ERPs podem ser definidos como modelos para standardização de processos,
funções e dados que podem ser desenvolvidos num sistema físico (ERP). Estes funcionam como
ferramentas importantes na configuração/parametrização de dados em sistemas ERP
semelhantes, dentro de uma organização ou grupos de organizações. A determinação de uma
semântica padrão para várias aplicações e a multiplicação do know-how obtido em diversas
implementações são algumas das consequências positivas da aplicação destes templates. A sua
utilização cinge-se à fase de implementação, sobretudo em metodologias de rollout, nas quais os
templates são desenvolvidos centralmente e posteriormente aplicados localmente.
Alt, Huber e Österle [2000] destacam a relevância da utilização destes templates na
standardização da configuração do sistema, na medida em que:
Sustentam fluxos de informação integrada, promovendo uma nova perspectiva para os
processos e reforçando as potencialidades de controlo e report;
Reduzem os custos de implementação e coordenação de sistemas ERP distribuídos,
dentro de um grande grupo empresarial ou de uma grande empresa multinacional.
Para a sua construção, estes autores propõem um método que reúne um conjunto de actividades,
para as quais estão associados possíveis documentos resultantes, a utilizar nos vários projectos
(Tabela A1 – secção Apêndice A).
Esta abordagem reforça a importância da documentação na reutilização dos templates,
especialmente para esclarecer os seus propósitos, descrever funcionalmente os seus
componentes e guiar a sua utilização. A manutenção dos templates é algo igualmente a ter em
conta, para que seja assegurada a consistência na sua aplicação às diferentes unidades de
negócio ou localizações geográficas distintas.
3. Proposta de Abordagem Conceptual
3.1. Proposta Geral
Como já foi explorado na introdução do artigo, a proposta conceptual passa pela criação de uma
abordagem para optimizar a parametrização de dados em ERPs. A sua aplicação apenas a
projectos de rollout reside na necessidade da existência de uma estrutura de informação base,
que é construída na implementação inicial (ou alterada / aproveitada a partir do ERP standard).
Posteriormente, esta é reutilizada e modificada de acordo com os requisitos específicos
decorrentes de cada rollout. A criação e a alteração da estrutura de tabelas de parametrização
não fazem parte do objectivo desta abordagem, ainda que possam ocorrer numa implementação
rollout.
A abordagem tem como ponto central o desenvolvimento de templates de parametrização. Estes
ostentarão uma arquitectura de três camadas [Ramirez 2000]:
Camada de apresentação, que fornece as interfaces de interacção com o utilizador do
template;
Camada de negócio, que, através da implementação das regras de negócio, controla a
funcionalidade do template, sendo ainda responsável pela comunicação com a base de
dados;
Camada de dados, constituída pela base de dados, a qual é responsável pelo
armazenamento da informação. Em alternativa, a camada de dados pode ainda ser
responsável pela interacção com a base de dados, retirando essa função da camada de
negócio.
Para que o ERP seja efectivamente parametrizado, é necessário o desenvolvimento de um
mecanismo de carregamento de dados de parametrização ou a aplicação de um já existente.
Desse modo e embora não faça parte da construção do template em si, este mecanismo é parte
integrante do âmbito da abordagem, pois só assim é possível transferir os dados de
parametrização para sistema ERP e obter o fluxo completo do processo.
A Figura 1 providencia uma esquematização conceptual da arquitectura da solução subjacente à
proposta de abordagem.
Figura 1 – Arquitectura da solução (conceptual) associada à proposta de abordagem
O processo de desenvolvimento do template, designando por Macroprocesso, irá apoiar-se nas
actividades subscritas pelo método Template Handbook [Alt et al. 2000] - Tabela A1 (secção
Apêndice A). Contudo, algumas dessas actividades não têm relevância para a abordagem a ser
apresentada:
Âmbito da
Abordagem Camada de Apresentação
Camada de Negócio
Camada de Dados
E
R
P
Mecanismo de
carregamento
de dados de
parametrização
6 – Definição do conceito de autorização – Esta actividade é desnecessária, uma vez
que todos os dados do template são parametrizáveis, não sendo nele incluídos campos
com valores já atribuídos centralmente e não configuráveis localmente;
8 - Documentar add-ons do template – Não será considerada a utilização de add-ons,
por ser algo acessório;
14 - Preparar guia de implementação – Este guia de implementação, seguida pelo
método referenciado, destina-se ao posterior desenvolvimento ou adaptação do template
localmente, o que não se aplica, pois estes são somente definidos centralmente. Todas
as especificidades locais que colidam com definições globais do sistema terão de ser
tratadas fora do template, pois envolvem análise de possíveis novas soluções.
De forma a se adaptarem às intenções desta nova abordagem, as actividades 5 e 7 do método
Template Handbook (Determinar e completar as definições de configuração) convergirão para o
desenvolvimento dos módulos de regras e de interacção com a base de dados do template, ao
passo que a actividade 9 (Definir as orientações para o armazenamento de dados) tratará do
mecanismo de carregamento de dados.
Num outro sentido, as primeiras três actividades acabarão por se agregar no planeamento e
organização do template. Este constitui o ponto de partida da abordagem, onde serão aplicadas
técnicas de levantamento e análise de requisitos, modelação de sistemas e engenharia inversa,
abordadas na revisão da literatura. Devido à relevância e complexidade associadas, o
planeamento e organização do template será tratado como um subprocesso do Macroprocesso,
sendo nomeado Microprocesso. A Figura 2 espelha a lógica processual da abordagem proposta.
Figura 2 – Lógica processual da abordagem proposta
Com esta abordagem pretende-se a standardização da parametrização de dados em ERPs, em
projectos de rollout. Para os requisitos funcionais previstos, o template passa a ser aplicável a
Macroprocesso
S.1
S.A.1 S.A.2 S.A.n
Microprocesso
A.1 A.2 A.n
Subprocesso Actividade Actividade do
Legenda: do Macroprocesso do Macroprocesso subprocesso (Microprocesso) (Microprocesso)
S A S.A
qualquer “nova” organização, em qualquer fase de rollout, desde que acautelados os
procedimentos de manutenção do template. A aplicação do Microprocesso é fundamental, pois
vai permitir perceber o funcionamento e a estrutura do sistema ERP, de forma a transpô-la para
o template, tendo sempre em conta a concordância com a lógica de negócio associada.
A parametrização dos dados pode assim ser assegurada pelo utilizador funcional da
organização, eliminando a necessidade de recorrer a técnicos com conhecimentos do sistema
ERP para o cumprimento dessa função. O template tem disponível uma camada com todas as
regras de validação exigidas, garantindo, desse modo, que os dados introduzidos estão no
formato e sequência adequados para o carregamento no ERP. A documentação tem um papel
fundamental na correcta utilização do template.
Em resumo, esta abordagem tem como finalidade reduzir os custos e o tempo de implementação
em projectos de rollout, assim como melhorar a qualidade dos dados que farão parte do ERP.
3.2. Macroprocesso
Nesta secção será apresentado o processo de desenvolvimento do template (Macroprocesso).
Efectuado o planeamento inicial para a construção do template (descrito na secção seguinte –
3.2 – Microprocesso), são desenhados os seus ecrãs (e suas interacções) e a sua base de dados,
respeitando os modelos de dados e comportamentais obtidos na fase inicial. A implementação
dos módulos de regras e interacção com a base de dados vai certificar que os dados respeitam as
validações do negócio e do ERP e que os mesmos são correctamente enviados para a base de
dados. Terminada a construção do template, é necessário desenvolver um mecanismo para o
carregamento dos dados parametrizados no sistema ERP ou, em alternativa, aplicar um já
existente. Para comprovar o seu sucesso, são realizados testes ao template, tendo por base os
casos testes definidos inicialmente. Por fim, são definidos os procedimentos de manutenção do
template e é preparada toda a documentação que guiará o utilizador.
A Figura 3 exibe um diagrama de actividades UML onde estão representadas as diferentes
actividades que compõe o Macroprocesso. A sua descrição e produtos/documentos resultantes
encontram-se na Tabela B1 (secção Apêndice B).
1 - Planeamento e organização do template (Microprocesso)
2 - Desenhar os interfaces e a base de dados
3 - Desenvolver os módulos de regras e de interacção com a base de dados
4 - Desenvolver e aplicar o mecanismo para carregamento dos dados de parametrização no sistema ERP
5 - Testar o template
7 - Providenciar os procedimentos de manutenção6 - Preparar a documentação para os utilizadores
[Template sem erros]
[Template com erros]
Figura 3 – Diagrama de actividades UML referente ao Macroprocesso
3.3. Microprocesso
O subprocesso de planeamento e organização dos templates (Microprocesso) corresponde à
etapa inicial da abordagem, funcionando como um suporte sólido para a posterior construção do
template. É nesta fase que se recorre ao processo de engenharia inversa de dados, abordado por
Jahnke et al. [2000a], de forma a compreender e obter a estrutura dos dados do sistema ERP
existente. As técnicas de casos de uso e cenários (levantamento e análise de requisitos) serão
igualmente contempladas, de acordo com a abordagem de Cockburn [2000], no sentido de
traduzirem o comportamento que o template deve assumir aquando da interacção com o
utilizador. Este comportamento deve ter em conta as dependências estabelecidas na estrutura de
dados do sistema. Tanto para representar essa estrutura (diagrama de classes UML ou diagrama
ERA), como para apresentar o comportamento do template (diagramas de actividades UML),
serão utilizados modelos de sistemas, os quais servirão de base à definição dos casos de teste
[Chandran et al. 2009, Kundu et al. 2009].
A Figura 4 exibe um diagrama de actividades UML onde estão representadas as diferentes
actividades que compõe o Microprocesso. A sua descrição e produtos/documentos resultantes
encontram-se na Tabela C1 (secção Apêndice C).
1 - Definir os requisitos
2.1 - Analisar o sistema ERP existente
2.2 - Representar o sistema ERP de forma abstracta
2 – Aplicar engenharia
inversa de dados
3 - Identificar e decompor os casos de uso e descrever os cenários associados
4 - Modelar os cenários
5 - Definir os casos de teste
6 - Definir as tecnologias a adoptar
7 - Analisar possíveis interacções dos dados de saída do template
Figura 4 – Diagrama de actividades UML referente ao Microprocesso
4. Aplicação da Abordagem Proposta
4.1. Descrição do Contexto de Aplicação
Com o intuito de racionalizar e reestruturar a Administração Pública Portuguesa, foi
implementada a lógica de serviços partilhados. A sua aplicação traduziu-se na centralização e
consolidação de processos não críticos (exemplo: gestão de recursos humanos) dos organismos
públicos numa outra entidade, centro de serviços partilhados, promovendo a eficiência, através
da redução de custos e informação redundante, foco dos organismos na sua missão principal e
melhoria da qualidade do serviço prestado ao cliente. A gestão destes serviços é suportada por
ERPs SAP.
Baseado na solução mySAP HCM E.C.C. 6.0 destinada ao sector público, o sistema de gestão
partilhada de recursos humanos da Administração Pública Portuguesa (denominado em diante
de SGRHAP) assenta numa lógica modular, oferecendo um conjunto de serviços que visam
essencialmente a consolidação da informação dos trabalhadores dos organismos públicos num
cadastro único e o cumprimento uniforme da legislação afecta à gestão de pessoal deste sector.
Numa fase inicial, o SGRHAP está a ser desenvolvido para cinco organismos piloto, estando
estabelecida uma estratégia de extensão aos restantes organismos da Administração Pública,
através de uma metodologia de rollout por fases. Em cada uma destas fases, a estratégia passa
pelo levantamento de informação a parametrizar junto dos "novos" organismos, tratamento e
conversão dessa informação, finalizando com a parametrização directa no sistema por parte de
um conjunto de consultores SAP.
Neste sentido, surge a oportunidade de aplicar a abordagem conceptual proposta, dando a
possibilidade ao SGRHAP de se adequar ao perfil dos organismos públicos, que integrem as
várias fases de rollout, de forma optimizada, isto é, suprindo, quer a necessidade de tratamento e
conversão de informação em cada uma das fases, quer a parametrização de dados directa no
sistema por parte de consultores SAP. A parametrização passa assim a ser realizada pelos
utilizadores funcionais dos organismos, através da utilização do template.
4.2. Concretização da Abordagem – Arquitectura da Solução e Processo
De forma a responder à arquitectura da solução apresentada na proposta conceptual, foi
seleccionada a ferramenta Microsoft Office Access 2010, a qual funcionará apenas do lado do
cliente. Esta possui um conjunto de características que permitem a definição de todas as
camadas consideradas na proposta:
Camada de apresentação - Os interfaces para apresentação e recolha de dados de
parametrização foram desenhados recorrendo a formulários (User Forms);
Camada de negócio - O módulo para a implementação do motor de regras de negócio
foi desenvolvido com recurso à linguagem de programação VB 7.0 - Microsoft Visual
Basic 7.0, tendo a comunicação com a base de dados sido assegurada pela linguagem de
programação SQL - Structured Query Language;
Camada de dados – É constituída pela base de dados, sendo que a ferramenta adoptada
permitiu, não só efectuar toda a sua gestão, mas também garantir a comunicação com a
camada de negócio de forma integrada.
Para assegurar o carregamento dos dados parametrizados no SGRHAP, foi utilizada uma
ferramenta SAP, o LSMW - Legacy System Migration Workbench. O seu modo de
funcionamento obrigou à exportação das tabelas da base de dados do template, para ficheiros de
extensão xls (Microsoft Excel) ou txt. Para cada um dos ficheiros foi necessário efectuar um
mapeamento de equivalência entre os campos das tabelas da base de dados do template e do
SGRHAP. A entrada dos dados de parametrização nas tabelas do SGRHAP é assegurada pela
criação de transacções (chamadas e execuções de programas ABAP, linguagem de programação
dos ERPs SAP), que permitem à ferramenta aceder a essas tabelas e actualizá-las. A Figura 5
concretiza a arquitectura de solução adoptada durante a aplicação da abordagem.
Figura 5 – Arquitectura de solução adoptada durante a concretização da abordagem proposta
Para demonstrar a aplicação da abordagem conceptual, será ilustrada a realização de algumas
das actividades afectas à abordagem proposta, tendo por base o requisito funcional –
Parametrizar tabela salarial (regime; carreira; categoria e posição/nível remuneratório dos
trabalhadores). Apenas será tida em conta a aplicação do requisito a carreiras gerais, de forma a
simplificar o entendimento da abordagem. As actividades descritas serão as seguintes (Figura
6):
Microprocesso:
o 2 - Aplicar engenharia inversa de dados:
2.1 - Analisar o sistema ERP existente;
Camada de Apresentação:
Interfaces
(User Forms)
Camada de Negócio:
Módulos de Regras (VB)
e Interacção com a base de dados (SQL)
Microsoft
VB +
Camada de Dados:
Base de Dados
Ficheiros .xls ou
.txt exportados
Transacção
SGRHAP
SAP
LSMW
Âmbito de
Aplicação
2.2 - Representar o sistema ERP de forma abstracta.
Figura 6 – Lógica processual da abordagem desenvolvida, com destaque para as actividades que irão
exemplificar a sua concretização
4.3. Analisar o Sistema Existente
Esta etapa de análise permitirá recolher informações sobre o SGRHAP, de modo a conseguir
estabelecer uma base sólida para a posterior modelação dos dados. Para tal, esta foi realizada
com o acompanhamento de um consultor funcional SAP RH, que detém experiência, quer a
nível de negócio (gestão de recursos humanos no sector público), quer a nível de sistema
(mySAP HCM para o sector público).
Para a análise do SGRHAP foram utilizadas transacções. A transacção SPRO mostra os vários
pontos de parametrização para os diferentes módulos de um ERP SAP. Neste caso, uma vez que
se trata do módulo de recursos humanos, o ponto de partida é o tópico da "Administração de
Pessoal", mais concretamente a informação do cadastro do trabalhador necessária para processar
a sua remuneração base:
"Verificar tipo de acordo colectivo" (Regime);
"Verificar região de acordo colectivo" (Carreira);
"Revisar faixas e níveis salariais" (Categoria e Posição/Nível Remuneratório).
Em cada um dos pontos de parametrização referenciados, é possível obter-se uma vista sobre os
dados já parametrizados, assim como os campos de possível parametrização (Figura 7).
Recorrendo às informações técnicas de cada campo, é possível apurar qual a tabela de
parametrização onde os dados são gravados. Na grande maioria das situações, são utilizadas,
Macroprocesso 1.Planeamento
e organização
do template
2. Desenhar os
interfaces e a
base de dados
Microprocesso
1. Definir
os
Requisitos
2.Analisar
o sistema
existente
...
3.Representar o
sistema ERP de
forma abstracta ...
Aplicação da Abordagem
numa camada superior, views (identificadas com inicial V_), isto é, porções de uma tabela (em
alguns casos de várias tabelas) que sintetizam a informação necessária para parametrizar o
sistema. A necessidade da sua existência resume-se ao facto das tabelas de parametrização
serem constituídas por um grande número de campos, isto devido à standardização dos ERPs e
da sua necessidade de aplicação a diversas organizações, de diferentes países, com necessidades
distintas. Os dados de parametrização presentes nas views são automaticamente armazenados
na(s) tabela(s) que a constituem.
Acedendo a uma view, é possível observa os campos que a constituem, bem como os seus tipos,
tamanhos ou descrições (Figura 7). Apenas relevam os campos que são visíveis no ponto de
parametrização, pois apenas esses poderão ser objecto de parametrização.
Figura 7 – Pontos de parametrização "Verificar tipo de acordo colectivo" e constituição da view
V_T510A, com destaque para os campos possíveis de parametrizar
Ao seleccionar o botão (Gráfico) é possível observar as relações existentes entre esta view
e outras views/tabelas (Figura 8).
Figura 8 – Relações de dependência da view V_T5101
A Figura 8 mostra que para cada "Tipo de acordo colectivo" (Regime) - V_T510A ou "Região
de acordo colectivo" (Carreira) - V_T510G podem existir várias "Faixas Salariais" (Categoria e
Posição/Nível Remuneratório) - V_T510, estabelecendo assim uma relação de um para muitos
(1:CN). Esta ligação implica que as chaves da V_T510A e V_T510G funcionem como chave da
V_T510.
4.4. Representar o Sistema de Forma Abstracta
Nesta actividade será elaborada uma representação conceptual dos dados, tendo por base a
análise elaborada. Para tal será utilizado um diagrama de classes UML, onde cada classe
representará uma tabela/view, aproveitando-se as associações para traduzir as suas relações e
respectiva multiplicidade. Os campos da view/tabela serão transformados em atributos da classe,
com tipos de dados iguais ou equivalentes.
A Figura 9 apresenta o diagrama de classes UML gerado a partir da informação obtida na
análise do sistema, para o requisito funcional definido.
-Codigo_Reg : Char(2)
-Descricao_Reg : Char(20)
Regime (V_T510A)
-Codigo_Car : Char(2)
-Descricao_Car : Char(20)
Carreira (V_T510G)
-Codigo_Categ : Char(8)
-PosNivel_Remun : Char(2)
-Rubrica_ Salarial : Char(4) = /621
-Montante_Rub_Sal : Double(13)
-DataIni : Date(8)
-DataFim : Date(8)
-Agrupador_Empregados : Char(1) = 3
-Agrupador_Países : Char(2) = 19
Categoria-PosNivel_Remuneratorio (V_T510)
1 0..*1
0..*
Figura 9 – Diagrama de classes UML para o requisito funcional - Parametrizar tabela salarial dos
trabalhadores (carreiras gerais) – lógica do SGRHAP
1 Nos diagramas gerados a partir de views, o prefixo “V_”, relativo ao seu nome, é removido.
Analisando a Figura 9, é possível verificar que, ao contrário da lógica de negócio, não existe
qualquer dependência entre o Regime e a Carreira. Estes apenas se associam através da
definição da Categoria-Posição/Nível Remuneratório. No contexto em estudo, uma carreira
pertence a um regime e subdivide-se em categorias, que por usa vez detêm um conjunto de
posições / níveis remuneratórios associados.
Dessa forma, a identificação dos casos de uso e cenários, que irão apoiar a definição do
comportamento do template, deverá ter por base o diagrama da Figura 10, que espelha a visão
do negócio, pois os utilizadores dos organismos conhecem apenas essa realidade. Contudo, é
necessário manter a lógica da Figura 9 na exportação dos dados de parametrização do template,
de forma a providenciar uma estrutura correcta para o carregamento dos mesmos no SGRHAP.
-Codigo_Reg : Char(2)
-Descricao_Reg : Char(20)
Regime
-Codigo_Car : Char(2)
-Descricao_Car : Char(20)
Carreira
-Codigo_Categ : Char(8)
-Descricao_Categ : Char(20)
-DataIni : Date(8)
-DataFim : Date(8)
-Agrupador_Empregados : Char(1) = 3
-Agrupador_Países : Char(2) = 19
Categoria
1
0..*
1
0..*
-Codigo_PosNivel_ Remun : Char(2)
-Descricao_PosNivel_ Remun : Char(20)
-Rubrica_Salarial : Char(4) = /621
-Montante_Rub_Sal : Double(13)
-DataIni : Date(8)
-DataFim : Date(8)
PosNivel_Remuneratorio0..*1
Figura 10 – Diagrama de classes UML para o requisito funcional - Parametrizar tabela salarial dos
trabalhadores (carreiras gerais) – lógica de negócio
5. Avaliação Preliminar da Abordagem Conceptual
Após a sua aplicação a um contexto real, a abordagem foi alvo de uma avaliação preliminar
através de entrevistas a informadores chave (key informants).
Informadores chave são pessoas que, devido às características pessoais ou posição que ocupam,
podem disponibilizar informação importante sobre um determinado acontecimento [Marshall
1996]. A realização de entrevistas a informadores chave pode ser utilizada numa situação de
avaliação, de forma a aproveitar o saber dos intervenientes relativamente à temática em questão
[Kumar 1989].
Na avaliação efectuada, foram utilizados, como informadores chave, três consultores com
conhecimento e experiência, quer em termos de informação de negócio, quer a nível do sistema
SGRHAP e sua parametrização. Estes acompanharam a aplicação da abordagem proposta, tendo
no final participado numa entrevista semi-estruturada, que visava obter a sua opinião sobre a
importância deste novo conceito de parametrização de dados em ERPs, bem como dos seus
benefícios e custos.
A Tabela 1 sintetiza a opinião dos três informadores chave, em termos de vantagens e
desvantagens da abordagem desenvolvida.
Avaliação Preliminar da Abordagem Desenvolvida – Informadores Chave
Vantagens Desvantagens
Diminuição do tempo de desenvolvimento do rollout.
Morosidade na aplicação do Microprocesso
(Organização e Planeamento do Template), o
qual pode ter actividades com pouca
relevância (exemplo: Modelar os casos de
uso/cenários), se os templates forem
construído por elementos com conhecimentos
aprofundados de ERPs SAP e do projecto em
questão.
Diminuição de erros de implementação devido às
validações introduzidas no template.
Diminuição de recursos necessários para efectuar a
parametrização.
Aumento da qualidade e da segurança da
parametrização de dados com as actividades do
Microprocesso (Organização e Planeamento do
Template), que fornecem igualmente documentação
que acompanha o projecto, preservando o know-how
a ele associado, melhorando o seu entendimento e
suportando a manutenção dos templates.
Tabela 1 – Vantagens/desvantagens na aplicação da abordagem, segundo os informadores chave
De acordo com a análise providenciada pelos informadores chave, a aplicação da abordagem
traduz-se em benefícios a vários níveis.
No que toca aos custos monetários, embora a construção dos templates envolva um agregado de
custos fixos iniciais, os custos variáveis, durante as várias fases de um rollout, referem-se
apenas à manutenção dos templates. Por outro lado, o processo de parametrização de dados
seguido habitualmente pelas organizações pressupõe a utilização de um conjunto de consultores
(técnicos), com conhecimentos do sistema, no sentido de assegurar a parametrização directa
ERP, o que representa um custo variável elevado, que será tanto maior, quanto mais fases e
organismos integrarem o projecto de rollout. A Figura 11 espelha, em termos gerais, a diferença
entre os custos totais do processo de parametrização habitual e do processo associado à
abordagem proposta, tendo em conta o tamanho do projecto de rollout.
Figura 11 – Total de custos de parametrização de dados em ERPs, no âmbito de projectos de rollout
A redução do tempo de desenvolvimento, em cada fase do rollout, resulta do facto de a
parametrização ser assegurada pelos utilizadores funcionais do organismo, sendo eliminadas as
seguintes necessidades:
Tratamento e conversão dos dados obtidos junto dos organismos, dado que estas
funcionalidades passam a estar contempladas no motor de regras do template, o qual
promove uma menor taxa de erros na implementação e uma melhoria na qualidade dos
dados de parametrização carregados no sistema ERP;
Parametrização directamente no sistema por consultores com conhecimentos do sistema
em causa.
A aplicação do Microprocesso gera alguma discordância na análise efectuada pelos
informadores chave. Algumas das suas actividades podem ser consideradas desnecessárias para
o desenvolvimento dos templates, quando estes são implementados por elementos com
conhecimentos de ERP SAP e do negócio associado ao projecto. Porém, este contempla a
produção de um conjunto de documentos que promovem entendimento mais adequado e
concreto, quer do comportamento, quer da forma de armazenamento dos dados por parte
sistema, suportando ainda a manutenção futura dos templates. Este subprocesso possibilita
ainda:
A detecção de inconsistências entre a lógica do sistema e a lógica do negócio (exemplo:
diferenças entre as Figuras 9 e 10), o que pode inclusive surgir como oportunidade para
modificar a estrutura do sistema existente;
A construção dos templates por elementos sem domínio de ERPs SAP.
Custo
Total
Tamanho do
projecto de rollout
Legenda: Parametrização
Habitual
Parametrização
utilizando
a abordagem
Total de custos de parametrização de dados em ERPs - Projectos de rollout
6. Conclusões, Limitações e Trabalhos Futuros
Neste trabalho foi apresentada uma nova abordagem para parametrização de ERPs, em projectos
de rollout. Esta teve por base um processo desenvolvimento de templates, construídos com base
em técnicas de levantamento e análise de requisitos, modelação de sistemas e engenharia
inversa.
Após a aplicação da abordagem ao sistema SGRHAP, construído sobre um ERP SAP, foi
elaborada uma avaliação preliminar com recurso a informadores chave, a qual sugere um
aumento de eficiência na parametrização dos dados referentes a estes sistemas. Esta optimização
é sustentada pela utilização de menos recursos (e consequente diminuição dos custos), pela
redução do tempo de implementação e pela melhoria da qualidade dos dados de parametrização
do sistema ERP.
O aproveitamento do Microprocesso, embora possa ser afectado por uma possível demora na
execução de algumas das suas actividades, garante uma maior qualidade na criação dos
templates, fornecendo igualmente uma estrutura de documentação chave para um melhor
entendimento do ERP e para correcta manutenção dos templates.
Importa referir que, desde que sejam cumpridos os procedimentos de manutenção, está atestada
a standardização, tanto do processo de parametrização (para os requisitos definidos), como dos
dados do sistema. Desse modo, é promovida a utilização de uma semântica comum nos vários
sistemas ERP, eliminando possíveis redundâncias e duplicações nos dados.
No que toca às limitações, estas passaram essencialmente pela impossibilidade de acesso a
ferramentas de mercado que poderiam auxiliar e acelerar as actividades de engenharia inversa
de dados respeitantes ao Microprocesso. Ainda neste tópico, é importante referir que a
construção de uma base mais sólida de literatura em termos de parametrização de dados em
ERPs foi restringida pela reduzida quantidade de artigos científicos publicados a esse nível,
principalmente pela confidencialidade, deste tipo de temas e soluções, estabelecida pelas
empresas do ramo.
Em relação a trabalhos futuros, a sugestão passa pelo uso de outras técnicas e ferramentas nas
várias etapas do Macroprocesso e do Microprocesso. Outra proposta a ter conta é igualmente a
aplicação da abordagem conceptual a outros ERPs, de forma a verificar a possível
generalização, na sua utilização. De acordo com a opinião de um dos informadores chave, esta
abordagem deve ser igualmente testada numa fase de implementação inicial de um ERP, para os
casos em que a estrutura standard do sistema não venha a sofrer quaisquer alterações, sendo
aproveitada na sua totalidade.
7. Referências
Aiken, P., Data Reverse Engineering: Slaying the Legacy Dragon, Nova Iorque, McGraw-Hill,
1996.
Alt, R., Huber, T., Österle, H., "Templates Instruments for Standardizing ERP Systems", in
Proceedings of the 33rd
Hawaii International Conference on System Sciences, 7, 2000,
7016-7026.
Belgamo, A., Martins, L. E. G., "Estudo Comparativo sobre as Técnicas de Elicitação de
Requisitos de Software", in XX Congresso Brasileiro da Sociedade Brasileira de
Computação, Curitiba, 2000.
Berenbach, B., “The Evaluation of Large, Complex UML Analysis and Design Models”, in
Proceedings of the 26th International Conference on Software Engineering, 2004, 232-
241.
Bevan, N., Maguire, M., "User Requirements Analysis: A review of supporting method", in
Proceedings of IFIP 17th World Computer Congress - TC13 Stream on Usability:
Gaining a Competitive Edge, 2002, 133-148.
Booch, G., Jacobson, I., Rumbaugh, J., The Unified Modeling Language User Guide, Addison-
Wesley, Massachusetts, 2ª Edição, 2005.
Brown, C. V., Vessey, I., "Managing the Next Wave of Enterprise Systems: Leveraging Lessons
From ERP", MIS Quarterly Executive, 2, 1 (2003), 65-77.
Chandran, K. R., Prasanna, M., “Automatic Test Case Generation for UML Object diagrams
using Genetic Algorithm”, International Journal of Advances in Soft Computing, 1, 1
(2009), 19-32.
Chikofsky, E. J., Cross II, J. H., "Reverse engineering and design recovery: a taxonomy", IEEE
Software (Journal), 7, 1 (1990), 13–17.
Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 1ª Edição, 2000.
Constantine, L. L., Lockwood, L. A. D., "Structure and style in use cases for user interface
design" in M. V. Harmelen, Object Modeling and User Interface Design, Addison-
Wesley, Boston, 1ª Edição, 2001, 245-279.
Davenport, T. H., "Putting the enterprise into the enterprise system", Harvard Business Review,
76, 4 (1998), 121-131.
Drelichowski, L., Parafian, L., "Using the Rollout Methodology during the ERP Systems
Implementations in Foreign Countries" in Series & Proceedings of Polish Association for
Knowledge Management, 20, 2009, 23-31.
D'Souza, D., Madapusi, A., "Aligning ERP Systems with International Strategies", Information
Systems Management, 22, 1 (2005), 7-17.
Easterbrook, S., Nuseibeh, B., "Requirements Engineering: A Roadmap", in Proceedings of the
Conference on The Future of Software Engineering, 2000, 35-46.
Englebert, V., Hainaut, J., Henrard, J., Hick, J., Roland, D., " The Nature of Data Reverse
Engineering", in Proceedings of Data Reverse Engineering Workshop, 2000.
Furlan, J. D., Modelagem de Objectos através da UML, Makron Books, São Paulo, 1ª Edição,
1998.
Glass, R. L., "Enterprise resource planning–breakthrough and/or term problem?", SIGMIS
Database, 29, 2 (1998), 13-16.
Hu, Q., Morton, N. A., “Implications of the fit between organizational structure and ERP: A
structural contingency theory perspective”, International Journal of Information
Management, 28, 5 (2008), 391-402.
Jacobson, I., Object Oriented Software Engineering: A Use Case Driven Approach, Addison
Wesley, Harlow, 1ª Edição, 1992.
Jacobson, I., "Basic Use Case Modeling", Report on Object Analysis & Design, 1, 2 (1994), 15-
19.
Jahnke, J. H., Zündorf, A., "Using Graph Grammars for Building the Varlet Database Reverse
Engineering Environment", in Proceedings of the 6th International Workshop on Theory
and Application of Graph Transformation, 1998.
Jahnke, J. H., Müller, H. A., Smith, D. B., Storey, M., Tilley, S. R., Wong, K., "Reverse
engineering: a roadmap", in Proceedings of the Conference on The Future of Software
Engineering, 2000a, 47-60.
Jahnke, J. H., Wadsack, J., "The Varlet Analyst: Employing Imperfect Knowledge in Database
Reverse Engineering Tools", in Proceedings of the 3rd
ICSE Workshop on Intelligent
Software Engineering, 2000b, 59-69.
Korth, H., Silberschatz, A., Sudarshan, S., Database System Concepts, McGraw-Hill, 6ª Edição,
2010.
Kumar, K., "Conducting key informant interviews in developing countries", A.I.D. Program
Design and Evolution Methodology Report, 13, 1989.
Kundu, D., Samanta, S., "A Novel Approach to Generate Test Cases from UML Activity
Diagrams", Journal of Object Technology, 8, 3 (2009), 65-83.
Lloyd, W. J., Tools and Techniques for Effective Distributed Requirements Engineering: An
Empirical Study, Faculty of the Virginia Polytechnic Institute and State University,
Blacksburg (E.U.A), 2001. Master's thesis in Computer Science.
Maciel, M., Round-Trip Engineering: Avaliação do estado da arte, Universidade Nova –
Faculdade de Ciências e Tecnologia, Lisboa (Portugal), 2003. Projecto de Final de Curso
(Departamento de Informática).
Marshall, N. M., "The key informant technique", Family Practice, 13, 1 (1996), 92-97.
Monk, E. F., Wagner, B. J., Concepts in: Enterprise Resource Planning, Cengage Learning,
Boston, 3ª Edição, 2009.
Müller, H. A., Tilley, S.R., Wong, K., "Understanding software systems using reverse
engineering technology" in V. S. Alagar, S. Missaoui, Object-oriented Technology for
Database and Software Systems, World Scientific Publishing Co Pte Ltd, Inc, 1ª Edição,
1995, 240-252.
Nunes, M., O'Neill, H., Fundamental de UML, FCA, Lisboa 5ª Edição, 2004.
Pressman, R., Software Engineering: A Practioner´s Approach, McGraw-Hill, 7ª Edição, 2009.
Ramirez, A. O., "Three-Tier Architecture", Linux Journal, 2000, 75 (2000).
Robertson, J., Robertson, S., Mastering the Requirements Process, Addison Wesley
Professional, 2ª Edição, 2006.
Rothenberger, M., Srite, M., "An Investigation of Customization in ERP System
Implementations", IEEE Transactions on Engineering Management (Journal), 56, 4
(2009), 663-676.
Somé, S. S., "Supporting use case based requirements engineering", Information and Software
Technology (Journal), 48, 1 (2006), 43-58.
Sommerville, I., Software Engineering, Addison Wesley, 8ª Edição, 2006.
Sun, D., Wong, K., “On Evaluating the Layout of UML Class Diagrams for Program
Comprehension”, in Proceedings of the 13th International Workshop on Program
Comprehension, 2005, 317-326.
Valentim, O. A., Dificuldades para a Actualização de Versão do Sistema ERP R/3 da SAP:
Estudo de Caso em Empresa do Segmento de Bebidas", Universidade Federal de São
Carlos, São Carlos (Brasil), 2010. Tese de Mestrado em Engenharia de Produção.
Vedoato, R., Abordagem Baseada em Objectivos para Construção de Casos de Uso e Cenários,
Universidade Federal do Rio Grande, Porto Alegre (Brasil), 2003. Tese de Mestrado em
Ciência da Computação.
Welti, N., Successful SAP R/3 Implementation: Pratical Management of ERP Projects, Addison
Wesley, 1ª Edição, 1999.
Young, R. R., The Requirements Engineering Handbook, Artech House, 2004.
Apêndice A – Tabela resumo do método Template Handbook - Revisão da
Literatura
Template Handbook
Actividades Possíveis documentos resultantes
1 Organizar o desenvolvimento do template Resumo do planeamento do template
2 Documentar as condições para o
desenvolvimento do template
Lista de condições para o desenvolvimento do
template
3 Documentar o processo associado template Diagrama de actividades do processo do template
4 Analisar possíveis trocas de dados de saída,
decorrentes do processo do template Diagrama do contexto do processo do template
5 Determinar as definições de configuração Pré-condições para a configuração (resumo)
6 Definir o conceito de autorização Conceito de autorização
7 Completar as definições de configuração Pré-condições para a configuração (detalhadas)
8 Documentar add-ons do template Resumo dos add-ons do template
9 Definir as orientações para o armazenamento de
dados
Documentação das orientações para o
armazenamento dos dados
10 Testar o template Relatório de testes
11 Preparar descrição funcional Documentação da funcionalidade do template
Template Handbook
Actividades Possíveis documentos resultantes
12 Providenciar procedimentos de manutenção Documentação de procedimentos de manutenção
13 Escrever a documentação para os utilizadores Documentação para os utilizadores finais
14 Preparar guia de implementação
Lista de condições para o desenvolvimento do
template, lista de add-ons do template, lista de
definições a serem localizadas e lista de
modificações para objectos originais
Tabela A1 – Desenvolvimento de templates de configuração segundo à abordagem Template Handbook
[baseado em Alt et al. 2000]
Apêndice B – Tabela descritiva do Macroprocesso - Proposta de
Abordagem Conceptual
Macroprocesso
Actividades (A) / Subprocessos (S)
Nº Nome Descrição Produtos/Documentos
resultantes
1
(S) Planeamento e
organização do
template
(Microprocesso)
Ver Microprocesso. Ver Microprocesso
2
(A) Desenhar os
interfaces e a base
de dados
Desenho dos vários ecrãs associados ao template e suas
interacções. Desenho da base de dados do template, de
acordo com a representação do sistema ERP obtida no
Microprocesso e sua concordância com a lógica de
negócio.
Template de
parametrização do ERP
3
(A) Desenvolver
os módulos de
regras e de
interacção com a
base de dados
Implementação, não só do motor para validar as regras
de negócio, mas também do módulo de comunicação
com a base de dados, na qual são armazenados os dados
preenchidos nos ecrãs. As regras são extraídas da
análise do sistema efectuada no Microprocesso.
Template de
parametrização do ERP
Macroprocesso
Actividades (A) / Subprocessos (S)
Nº Nome Descrição Produtos/Documentos
resultantes
4
(A) Desenvolver e
aplicar o
mecanismo para
carregamento dos
dados de
parametrização no
sistema ERP
Implementação do mecanismo de carregamento de
dados de parametrização, armazenados na base de
dados do template, no sistema ERP. Caso já exista um
mecanismo e não seja necessário qualquer tipo de
desenvolvimento/configuração, a actividade resume-se
à aplicação do mesmo.
Mecanismo de
carregamento de dados de
parametrização no ERP
5
(A) Testar o
template
Realização de testes de release (caixa preta) com base
nos casos de teste gerados no Microprocesso e de testes
de integração entre os diferentes componentes do
template.
Relatório de testes
6
(A) Preparar a
documentação para
os utilizadores
Documentação das várias funcionalidades do template,
de forma a explicar o seu propósito e componentes e
guiar o utilizador no seu funcionamento. Compilação e
integração de documentação produzida e classificada
como relevante para os fins assinalados.
Documentação para os
utilizadores finais
7
(A) Providenciar
os procedimentos
de manutenção
Definição das acções de manutenção, para que o
template se mantenha consistente na aplicação às
diferentes unidades organizacionais e também durante
as várias fases de rollout, se este ocorrer por etapas.
Documentação de
procedimentos de
manutenção do template
Tabela B1 – Actividades/subprocessos e produtos/documentos resultantes do Macroprocesso
Apêndice C – Tabela descritiva do Microprocesso - Proposta de Abordagem
Conceptual
Microprocesso - Planeamento e Organização do Template
Actividades
Nº Nome Descrição Produtos/Documentos
resultantes
1 Definir os
requisitos
Definição dos requisitos funcionais que corresponderão às
acções/objectivos de parametrização do sistema ERP. São
igualmente identificados requisitos não funcionais
referentes a propriedades que o template deve contemplar
e restrições em termos do desenho do template. Estes
poderão influenciar a escolha da tecnologia a adoptar.
Resumo geral dos
requisitos identificados
2
Aplicar
engenharia
inversa de dados -
2.1 - Analisar o
sistema ERP
existente
Análise do sistema de modo a recuperar o modelo de
dados lógico. Para esta etapa é essencial o apoio de
especialistas do sistema, com algum conhecimento do
negócio, de forma a auxiliar a selecção da informação
referente aos requisitos funcionais estabelecidos.
Não aplicável
Aplicar
engenharia
inversa de dados -
2.2 - Representar
o sistema ERP de
forma abstracta
Representação conceptual do modelo de dados lógico
obtido na etapa anterior, através de diagramas de classes
UML ou diagramas ERA.
Modelo de Dados
(Diagrama de classes
UML ou diagrama ERA)
3
Identificar e
decompor os
casos de uso e
descrever os
cenários
associados
Partindo dos requisitos funcionais a parametrizar,
representados por casos de uso (podem ser decompostos
em novos casos de uso), são identificados todos os
cenários de interacção com o utilizador, encapsulados em
cada caso de uso. A possível ligação entre casos de uso ou
a definição dos cenários está directamente relacionada
com as dependências estabelecidas no modelo de dados,
podendo entrar-se em conta com outros aspectos
relevantes extraídos da análise do sistema ERP existente.
Documento de descrição
dos casos de uso e
cenários associados
Microprocesso - Planeamento e Organização do Template
Actividades
Nº Nome Descrição Produtos/Documentos
resultantes
4 Modelar os
cenários
Tradução dos cenários levantados para cada caso de uso
em modelos comportamentais, nomeadamente em
diagramas de actividade UML.
Modelo
Comportamental
(Diagrama de
actividades UML)
5 Definir os casos
de teste
Concepção e geração dos casos de teste, com base nos
modelos de dados e comportamentais alcançados.
Documento de casos de
teste
6
Definir as
tecnologias a
adoptar
Determinação das tecnologias a utilizar no desenho e
desenvolvimento do template, bem como no carregamento
de dados de parametrização no sistema ERP.
Resumo das tecnologias
adoptadas
7
Analisar possíveis
interacções dos
dados de saída do
template
Discussão sobre possíveis interacções dos dados de saída
do template com outros sistemas ou ferramentas, antes do
seu armazenamento no ERP, por exemplo, para um
eventual tratamento ou conversão de dados.
Diagrama de Contexto
Tabela C1 – Actividades e produtos/documentos resultantes do Microprocesso