william scatola - univates scatola .pdf · figura 43 - processo de inclusÃo manual de...
TRANSCRIPT
CENTRO UNIVERSITÁRIO UNIVATES
CURSO DE ENGENHARIA DA COMPUTAÇÃO
UM SISTEMA PARA AUTOMATIZAR A CUSTOMIZAÇÃO DE PROCESSOS DE NEGÓCIO EM SISTEMAS DE INFORMAÇÕES
GERENCIAIS
William Scatola
Lajeado, novembro de 2013.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
William Scatola
UM SISTEMA PARA AUTOMATIZAR A CUSTOMIZAÇÃO DE PROCESSOS DE NEGÓCIO EM SISTEMAS DE INFORMAÇÕES
GERENCIAIS
Monografia apresentada ao Centro de Ciências Exatas e Tecnológicas do Centro Universitário UNIVATES, como parte dos requisitos para a obtenção do título de Bacharel em Engenharia da Computação.
Orientador: Prof. Ms. Pablo Dall'Oglio
Lajeado, novembro de 2013.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
William Scatola
UM SISTEMA PARA AUTOMATIZAR A CUSTOMIZAÇÃO DE
PROCESSOS DE NEGÓCIO EM SISTEMAS DE
INFORMAÇÕES GERENCIAIS
A Banca examinadora abaixo aprova a Monografia apresentada na disciplina Trabalho de Conclusão
de Curso II, do Centro Universitário Univates, como parte da exigência para a obtenção do grau de
Bacharel em Engenharia da Computação:
Prof. Ms. Pablo Dall'Oglio - orientador
Centro Universitário Univates
Prof. Ms. Mouriac Halen Diemer
Centro Universitário Univates
Prof. Ms. Marcelo de Gomensoro Malheiros
Centro Universitário Univates
Lajeado, novembro de 2013.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
RESUMO
Os atuais sistemas de informações gerenciais são desenvolvidos visando principalmente a automatização e integração dos processos de negócios da empresa. Porém, mesmo nas situações em que o sistema de informação atende aos processos de negócios de uma organização, algum nível de customização se faz necessário. O procedimento de customização de sistema envolve custos elevados e engessa o sistema, pois após customizada uma rotina, esta não é mais atualizada em novas versões do mesmo e, de alguma forma, precisarão passar por algum tipo de manutenção no futuro. Dentro deste contexto, o objetivo do presente trabalho é apresentar o desenvolvimento de um sistema que possibilite automatizar a customização de sistemas de informações gerenciais por meio da definição de regras e da criação de gatilhos de ações, de maneira a adicionar um novo comportamento à aplicação existente, sem, no entanto, modificar o comportamento original desta. Com isso, poderá ser minimizada a necessidade de customização de software, além de aumentar sua aderência aos processos organizacionais.
Palavras-chave: customização. sistemas de informações gerenciais. processos de negócio.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
ABSTRACT
The current management information systems are developed targeting mainly the automation and integration of business processes of the company. But even in situations where the information system meets the business processes of an organization, some level of customization is needed. The system customization process involves high costs and limits the system, because after customizing the routine, it is no longer updated in new versions of the system and, somehow, need to go through some type of maintenance in the future. Within this context, the aim of this work is to present the development of a system that allows to automate the customization of management information systems by defining rules and creating trigger actions in order to add a new behavior to the existing application without, however, modifying the behavior of the original. With this, the needs for software customization can be minimized, increasing their adherence to organizational processes.
Keywords: Customization. Management information systems. Business processes.
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE FIGURAS
FIGURA 1 - O ALINHAMENTO DE TI SEGUNDO MODELO DE CHAN........................13FIGURA 2 - FLUXO BÁSICO DE UM PROCESSO DE NEGÓCIO....................................14FIGURA 3 - TRATAMENTO INTEGRADO DE INFORMAÇÕES.......................................21FIGURA 4 - INTERAÇÃO DA INFORMAÇÃO NO PROCESSO DECISÓRIO..................22FIGURA 5 - A INFORMAÇÃO COMO MATÉRIA-PRIMA PARA A FORMULAÇÃO DA ESTRATÉGIA..........................................................................................................................24FIGURA 6 - EVOLUÇÃO DAS APLICAÇÕES EMPRESARIAIS.......................................28FIGURA 7 - ÁREAS DE APLICAÇÃO DE UM SISTEMA ERP...........................................30FIGURA 8 - FUNCIONALIDADES DE UM SISTEMA ERP................................................31FIGURA 9 - EXEMPLO DE ESTRUTURA ORGANIZACIONAL (VERTICAL E HORIZONTAL)........................................................................................................................33FIGURA 10 - VISÃO DEPARTAMENTAL E VISÃO DE PROCESSOS..............................33FIGURA 11 - EVENTOS, OBJETOS DE FLUXO DA BPMN...............................................35FIGURA 12 - ATIVIDADES, OBJETOS DE FLUXO DA BPMN..........................................35FIGURA 13 - GATEWAYS, OBJETOS DE FLUXO DA BPMN............................................35FIGURA 14 - FLUXO DE SEQUÊNCIA, OBJETO DE FLUXO DA BPMN........................36FIGURA 15 - NÍVEIS DE CUSTOMIZAÇÃO DE PRODUTO.............................................37FIGURA 16 - PARADIGMA PROCURA-CONSOLIDA-EXECUTA...................................41FIGURA 17 - EXEMPLO DE UM DIAGRAMA DE CASO DE USO...................................44FIGURA 18 - EXEMPLO DE ESTRUTURA DE CLASSE EM UML...................................45FIGURA 19 - EXEMPLO DE DIAGRAMA DE COMPONENTES.......................................45FIGURA 20 - EXEMPLO DE DIAGRAMA DE ATIVIDADES.............................................46FIGURA 21 - ARQUITETURA DO CUSTOMEASY.............................................................49FIGURA 22 - DIAGRAMA DE CASOS DE USO..................................................................50FIGURA 23 - MENU PRINCIPAL DO SISTEMA..................................................................51FIGURA 24 - TELA DE CADASTRO DE SERVIDORES DE BANCO DE DADOS...........52FIGURA 25 - TELA DE CADASTRO DE SERVIDORES DE WEB SERVICES.................53FIGURA 26 - TELA DE CADASTRO DE REGRAS..............................................................54FIGURA 27 - TELA DE CADASTRO DE REGRA DE BANCO DE DADOS......................55FIGURA 28 - TELA DE CADASTRO DE REGRA DE WEB SERVICE...............................56FIGURA 29 - TELA DE CADASTRO DE UMA AÇÃO........................................................56FIGURA 30 - TELA DE CADASTRO DE UMA AÇÃO DE BANCO DE DADOS..............57
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
FIGURA 31 - TELA DE CADASTRO DE UMA AÇÃO DE WEB SERVICE.......................58FIGURA 32 - TELA DE CADASTRO DE UMA AÇÃO DE E-MAIL...................................59FIGURA 33 - TELA DE CADASTRO DE FREQUÊNCIAS..................................................60FIGURA 34 - EXEMPLO DE NOTIFICAÇÃO ENVIADA PELO CUSTOMEASY............61FIGURA 35 - DIAGRAMA DE ATIVIDADES DO SISTEMA CUSTOMEASY..................62FIGURA 36 - DIAGRAMA DE CLASSES.............................................................................63FIGURA 37 - DIAGRAMA E.R. DO SISTEMA CUSTOMEASY.........................................69FIGURA 38 - CONFIGURAÇÃO DO PROGRAMA DISPARADOR DE AÇÕES...............73FIGURA 39 - CONFIGURAÇÃO DE AGENDAMENTO......................................................74FIGURA 40 - ALGORITMO DO PROGRAMA PRINCIPAL DO CUSTOMEASY..............74FIGURA 41 - ORGANIZAÇÃO DO PROJETO DENTRO DO IDE NETBEANS................77FIGURA 42 - PROCESSO DE INCLUSÃO MANUAL DE SOLICITAÇÕES DE COMPRA, SEM O CUSTOMEASY...........................................................................................................79FIGURA 43 - PROCESSO DE INCLUSÃO MANUAL DE SOLICITAÇÕES DE COMPRA, COM O CUSTOMEASY..........................................................................................................79FIGURA 44 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR DE COMPRAS...................................................................................................................................................80FIGURA 45 - PROCESSO DE CÁLCULO DE DEPRECIAÇÃO, SEM O CUSTOMEASY81FIGURA 46 - PROCESSO DE CÁLCULO DE DEPRECIAÇÃO, COM O CUSTOMEASY...................................................................................................................................................82FIGURA 47 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR DE PATRIMÔNIO..........................................................................................................................82FIGURA 48 - PROCESSO DE CÁLCULO DA FOLHA DE PAGAMENTO, SEM O CUSTOMEASY........................................................................................................................83FIGURA 49 - PROCESSO DE CÁLCULO DA FOLHA DE PAGAMENTO, COM O CUSTOMEASY........................................................................................................................84FIGURA 50 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR DE RECURSOS HUMANOS.........................................................................................................85FIGURA 51 - PROCESSO DE SELEÇÃO DE TÍTULOS PARA PAGAMENTO, SEM O CUSTOMEASY........................................................................................................................86FIGURA 52 - PROCESSO DE SELEÇÃO DE TÍTULOS PARA PAGAMENTO, COM O CUSTOMEASY........................................................................................................................86FIGURA 53 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR FINANCEIRO...................................................................................................................................................87
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE TABELAS
TABELA 1 - DESCRIÇÃO DA CLASSE REGRA.................................................................64TABELA 2 - DESCRIÇÃO DA CLASSE REGRABD............................................................64TABELA 3 - DESCRIÇÃO DA CLASSE REGRAWS............................................................65TABELA 4 - DESCRIÇÃO DA CLASSE ACAO....................................................................65TABELA 5 - DESCRIÇÃO DA CLASSE ACAOWS..............................................................65TABELA 6 - DESCRIÇÃO DA CLASSE ACAOBD..............................................................66TABELA 7 - DESCRIÇÃO DA CLASSE ACAOEMAIL.......................................................66TABELA 8 - DESCRIÇÃO DA CLASSE SERVERBD..........................................................66TABELA 9 - DESCRIÇÃO DA CLASSE SERVERWS..........................................................67TABELA 10 - DESCRIÇÃO DA CLASSE LOG.....................................................................67TABELA 11 - DESCRIÇÃO DA CLASSE FREQUENCIA....................................................67TABELA 12 - DESCRIÇÃO DA CLASSE RETORNO..........................................................68TABELA 13 - DESCRIÇÃO DA TABELA REGRAS.............................................................70TABELA 14 - DESCRIÇÃO DA TABELA REGRASBD.......................................................70TABELA 15 - DESCRIÇÃO DA TABELA REGRASWS.......................................................70TABELA 16 - DESCRIÇÃO DA TABELA ACOES................................................................71TABELA 17 - DESCRIÇÃO DA TABELA ACOESBD..........................................................71TABELA 18 - DESCRIÇÃO DA TABELA ACOESWS..........................................................71TABELA 19 - DESCRIÇÃO DA TABELA ACOESEMAIL...................................................71TABELA 20 - DESCRIÇÃO DA TABELA SERVERSBD......................................................72TABELA 21 - DESCRIÇÃO DA TABELA SERVERSWS.....................................................72TABELA 22 - DESCRIÇÃO DA TABELA LOGS..................................................................72TABELA 23 - DESCRIÇÃO DA TABELA FREQUENCIAS.................................................73
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
LISTA DE ABREVIATURAS
ERP: Enterprise Resource Planning
MRP: Materials Requirements Planing
PCP: Planejamento e Controle da Produção
RF: Requisitos Funcionais
RNF: Requisitos Não Funcionais
SIG: Sistemas de Informações Gerenciais
SOA: Service Oriented Architeture
SOAP: Simple Object Access Protocol
TI: Tecnologia da Informação
UML: Unified Modeling Language
W3C: WorldWideweb Consortium
WS: Web Service
XML: Extensible Markup Language
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
SUMÁRIO
1 INTRODUÇÃO...................................................................................................................121.1 Motivação..........................................................................................................................151.2 Objetivos...........................................................................................................................161.3 Metodologia......................................................................................................................171.4 Roteiro do restante do trabalho.........................................................................................192 REFERENCIAL TEÓRICO................................................................................................202.1 Sistemas de Informações Gerenciais.................................................................................202.1.1 Importância dos sistemas de informações gerenciais para as empresas........................212.2 Gestão Estratégica da Informação.....................................................................................232.2.1 Estratégia e Informação.................................................................................................232.2.2 Estratégia e Competitividade: algumas abordagens de estratégia..................................252.2.3 O alinhamento com a TI.................................................................................................252.3 Enterprise Resource Planning...........................................................................................272.3.1 Evolução dos Sistemas Integrados de Gestão Empresarial (ERP).................................272.3.2 Definição de Sistema ERP.............................................................................................292.3.3 Arquitetura e Principais Funcionalidades de um ERP...................................................302.4 Gestão por processos.........................................................................................................312.5 Mapeamento de processos................................................................................................342.6 BPMN - Business Process Modeling Notation.................................................................342.6.1 Evento............................................................................................................................352.6.2 Atividade........................................................................................................................352.6.3 Gateways........................................................................................................................352.6.4 Fluxo de Sequência........................................................................................................362.7 Gaps..................................................................................................................................362.8 Customização....................................................................................................................362.8.1 Desafios..........................................................................................................................382.8.2 Testes..............................................................................................................................382.9 Arquiteturas Orientadas a Serviço e Web Services...........................................................392.9.1 Web Services..................................................................................................................392.9.2 Arquiteturas Orientadas a Serviço..................................................................................402.9.3 O protocolo SOAP.........................................................................................................412.10 XML – Extensible Markup Language.............................................................................422.11 UML - Unified Modeling Language...............................................................................432.11.1 Diagrama de casos de uso............................................................................................432.11.2 Diagrama de classes.....................................................................................................44
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.11.3 Diagrama de Componentes..........................................................................................452.11.4 Diagrama de Atividades...............................................................................................463 TRABALHO PROPOSTO...................................................................................................473.1 Levantamento de requisitos do sistema............................................................................473.2 Arquitetura do CustomEasy..............................................................................................483.3 Casos de Uso.....................................................................................................................503.3.1 Cadastrar Servidores......................................................................................................523.3.2 Cadastrar Regras............................................................................................................533.3.3 Cadastrar Ações..............................................................................................................563.3.4 Fornecer Informações....................................................................................................603.3.5 Receber Notificações.....................................................................................................613.4 Diagrama de Atividades....................................................................................................623.5 Modelo de Classes............................................................................................................633.6 Modelo Relacional............................................................................................................683.7 Verificação de Regras e execução de Ações.....................................................................733.8 Tecnologias utilizadas.......................................................................................................753.9 Organização dos arquivos Java dentro do projeto Netbeans.............................................764 VALIDAÇÃO DA FERRAMENTA....................................................................................784.1 Processo de inclusão manual de solicitações de compra..................................................784.2 Processo de cálculo mensal de depreciação de bens.........................................................804.3 Processo de cálculo da folha de pagamento......................................................................834.4 Processo de seleção de títulos a pagar..............................................................................854.5 Avaliação dos resultados...................................................................................................875 CONSIDERAÇÕES FINAIS...............................................................................................89
REFERÊNCIAS........................................................................................................................90
APÊNDICE...............................................................................................................................92
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
1 INTRODUÇÃO
A informação possui atualmente um valor altamente significativo nas empresas, visto
que integra, quando devidamente estruturada, suas diversas unidades organizacionais. Esta
integração permite que a informação esteja presente em todos as atividades, seja envolvendo
pessoas, sistemas, recursos financeiros, processos ou tecnologias (REZENDE, ABREU,
2003).
Para Freitas, Becker e Kladis (1997) a importância da informação nas organizações
aumenta de mesmo modo que a complexidade da sociedade. Além disso, a informação é um
recurso fundamental em todos os níveis organizacionais (operacional, tático e estratégico), e a
maneira com a qual é trabalhada precisa ser observada para que seja transmitida sem ruídos ao
usuário em determinado processo decisório ou operacional.
Neste contexto organizacional, o processo de gestão da informação contempla
processos que não se baseiam somente na administração da infraestrutura de Tecnologia da
Informação (TI) e de sistemas de informação, mas que também incluam a administração do
comportamento informacional da organização, da cultura organizacional e da equipe
organizacional (BEAL, 2004).
Atualmente os altos gastos em tecnologia da informação (mais de um trilhão de
dólares anuais) não condizem com o desempenho financeiro das empresas. A alegação dos
gestores é de que a informação que dispõem hoje é pouco melhor da que possuíam
anteriormente. Segundo economistas, a provável causa deste problema é a negligência dos
programas de TI quanto ao aspecto humano no processo de equacionamento da informação.
Estes altos gastos em TI indicam sinais de obsessão pela tecnologia, tanto que nos Estados
Unidos, por exemplo, metade dos investimentos empresariais são em TI. Os departamentos de
sistemas de informação nas corporações dedicam-se quase que exclusivamente à aquisição e
manutenção dos computadores, softwares e redes de comunicação. A filosofia que predomina
é a de “se desenvolvermos a TI, o resto virá” (DAVENPORT; DICKSON; BELLINI, 2004).
Neste sentido, para que haja um correto gerenciamento da informação na organização,
sobretudo para a execução da estratégica desta, é importante um alinhamento com a TI.
Segundo Beuren (2000), o alinhamento da TI com a estratégia global da empresa não
acontece por acaso. É um processo que requer um envolvimento completo de grande parte dos
níveis da empresa. É, ainda, um esforço contínuo que exige capacidades e conhecimentos,
além de poder permitir a ocorrência de riscos (mas com uma gestão adequada dos mesmos).
12
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
A Figura 1 ilustra o alinhamento de TI através do Modelo de Chan, relacionada à
orientação estratégica dos negócios, onde pode ser percebido que há uma ligação direta da TI
no desempenho dos negócios da organização.
Figura 1 - O alinhamento de TI segundo Modelo de Chan
Fonte: Chan et al (1997).
Para apoiar os gestores no processo de transformação da informação, ou seja,
transformar os dados em algo útil para a organização e, assim, prover o alinhamento da TI
com os processos de negócio e operações, tomadas de decisão e estratégias competitivas, há a
necessidade da implantação um sistema que gere ou manipule dados. Estes sistemas são
genericamente chamados de sistemas de informação, e podem contribuir de forma
significativa para a solução de diversos problemas empresariais. Segundo Rezende e Abreu
(2003), os esforços das empresas tendem a concentrar-se nos níveis superiores dos sistemas
de informação empresariais: os Sistemas de Informação Gerenciais (SIG).
Visando a integração dos dados entre as diversas áreas da organização, o SIG é
composto por variados subsistemas, também chamados de módulos (financeiro, contabilidade,
gestão de pessoal, estoque e custos). Um dos desafios dos administradores é aumentar a
eficiência global do SIG através do aperfeiçoamento da integração entre estes subsistemas,
sem perder a visão do todo, que é a empresa (REZENDE; ABREU, 2003).
Em síntese, o objetivo principal de um sistema de informação gerencial é melhorar o
desempenho das pessoas nas organizações através do uso da tecnologia da informação. Este
objetivo é alcançado por uma variante dos tradicionais sistemas de informação gerenciais
empresariais, conhecidos como Enterprise Resource Planning (ERP). Estes são sistemas
desenvolvidos com o objetivo de abranger determinadas áreas administrativas da empresa,
como recursos humanos, contabilidade, financeiro e faturamento. A palavra de ordem em um
13
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
ERP é integração. A integração presume o uso comum de dados, ou seja, um determinado
cadastro (cadastro de clientes, por exemplo) pode estar em diferentes módulos, como
financeiro, faturamento, contabilidade e ser visualizado/alterado/excluído por qualquer uma
destas áreas. Este é o exemplo mais básico das funcionalidades de um ERP, sendo que este é
implementado visando principalmente a automatização e integração dos processos de
negócios da empresa (COLÂNGELO, 2001).
Para De Sordi (2009), o processo de negócio pode ser definido como uma série de
etapas criadas para produzir um produto ou serviço, incluindo várias funções e preenchendo
as lacunas existentes entre as diversas áreas organizacionais, objetivando com isso estruturar
uma cadeia de agregação de valor ao cliente, conforme ilustrado na Figura 2.
Figura 2 - Fluxo básico de um processo de negócio
Fonte: Elaborado pelo autor.
Todavia, mesmo nos casos em que o sistema de informação gerencial atende aos
processos de negócios da empresa, pode ser necessária a utilização de uma ferramenta de
apoio para automatizar a customização destes processos. Esta constatação é verificada
principalmente quando há uma análise dos processos de negócio da empresa, através da
ferramenta de mapeamento de processos (PAIM; CARDOSO; CAULLIRAUX, 2009).
A demanda de customização de processos surge, principalmente, pelo fato dos
sistemas de informações gerenciais (sobretudo os ERPs) serem softwares genéricos, ou seja,
no momento de sua aquisição e posterior implantação, estes vêm com as mesmas
funcionalidades para qualquer empresa que o adquirir (também chamadas de rotinas padrões
do sistema). Na etapa de implantação do ERP, a empresa define, então, a partir do seus
processos de negócio, quais módulos utilizará para que o sistema seja parametrizado de
acordo com as necessidades verificadas. Mesmo assim, nem sempre as mais variadas
14
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
configurações das rotinas padrões do sistema acabam contemplando todos os processos de
negócio da empresa. Posteriormente, a utilização constante das rotinas do sistema de
informação gerencial irá agregar conhecimento aos participantes do processo e,
invariavelmente, será verificado que algum ponto do processo precisa de melhoria. Dessa
forma, pode ser detectado que em algum ponto do processo de negócio há alguma deficiência
no produto (software), sendo então necessária a customização de software (RABISER et al.,
2009).
Rabiser et al. (2009) afirma, ainda, que a customização é o ato de transformar,
personalizar, determinado sistema aos parâmetros estabelecidos pela empresa. Seja alterando
cálculos, fórmulas ou metodologia. É o ato de modificar o processo de negócio. Este tipo de
software é desenvolvido sob medida para as necessidades da empresa, levando em
consideração o ramo de negócios, metodologias de trabalho, rotina de cada departamento e
preferências do usuário final. Através de uma customização, pode ser gerado um nível maior
de identificação e adesão entre os futuros usuários, já que este software levará em
consideração particularidades da rotina de trabalho desses profissionais. Pode, ainda, integrar-
se à rotina ao oferecer soluções alinhadas às necessidades da empresa, elevando o nível de
produtividade e atuando como um poderoso aliado da equipe no cumprimento da rotina.
De uma maneira geral, a customização pode ser considerado como um procedimento
que proporciona aos processos de negócio uma maior aderência à organização, reduzindo
custos de operação e, através de um alinhamento com a TI, prover suporte a estratégia,
automatizando os processos de negócios e garantindo que os investimentos de TI são
priorizados de forma adequada, de acordo com as necessidades do negócio.
1.1 Motivação
Os usuários finais dos atuais sistemas de informações gerenciais, em sua maioria
ERPs, geralmente necessitam de um grande esforço para entender suas funcionalidades
oferecidas por padrão. Tipicamente, os usuários precisam somente de uma pequena fração das
rotinas disponibilizadas, mas são sobrecarregados de funcionalidades desnecessárias em seus
processos diários.
Segundo Rabiser et al. (2009), os ERPs e softwares do gênero (popularmente
chamados de softwares genéricos) precisam possuir características comuns a todas as áreas de
negócio, além das especificidades de cada área. O resultado final desta necessidade comum é
uma miscelânea de funcionalidades presentes no software que ora não são usadas, ora são
15
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
deficientes para uma necessidade peculiar da organização. Toda e qualquer organização
possui o seu conjunto de processos de negócio que a torna única, e que por diversas vezes
transformam-se em diferenciais competitivos. A finalidade, portanto, de um Sistema de
Informações Gerenciais, é atender à estes processos de negócio da organização. Todavia,
raramente um sistema ERP atende a totalidade destes processos, uma vez que são produtos
genéricos, e precisam ser adaptados à realidade de cada organização através de um rigoroso
processo de implantação.
Mesmo nas situações em que o sistema de informação atende aos processos de
negócios de uma organização, algum grau de customização se faz necessário. Geralmente o
procedimento de customização de sistema envolvem custos elevados e “engessam” o sistema,
pois após customizada uma rotina, esta não é mais mantida nas atualizações das
funcionalidades padrão do sistema e, de alguma forma, precisarão passar por algum tipo de
manutenção no futuro.
Percebe-se que apesar de existirem grandes empresas desenvolvedoras de ERPs,
mesmo que há décadas em atuação no mercado, pode ser verificado a necessidade de alguma
customização do sistema para contemplar alguma demanda particular do negócio da empresa,
sem descaracterizar o software original.
Uma das principais fontes de renda para as empresas fornecedoras de software são
justamente as customizações de software, que por vezes são realizadas sem um correto
processo de implantação. Dessa forma, muitas customizações levam mais tempo que o
necessário para sua implementação e em alguns casos são totalmente desnecessárias.
Neste sentido, existe uma demanda por soluções que permitam que as customizações
de software sejam realizadas sem a descaracterização do produto original. Além disso, existe a
necessidade de que as customizações possam ser adicionadas e removidas da aplicação
original de forma transparente, sem influenciar o funcionamento básico do software.
Dessa maneira, o presente trabalho visa responder a questão: Como permitir a
customização de um software, acrescentando-o novas características, sem a alteração do
produto original, de maneira a aumentar a aderência do mesmo aos processos de negócio,
contribuindo com as estratégias organizacionais?
1.2 Objetivos
A partir das eventuais necessidades de cada organização quanto à aderência de novas
funcionalidades ao seu atual processo de negócio, a proposta do presente trabalho é o
16
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
desenvolvimento de um sistema que vise automatizar a customização de processos de negócio
em sistemas de informação gerenciais.
O principal objetivo do sistema proposto é permitir a definição de regras e a criação de
gatilhos de ações, de maneira a adicionar um novo comportamento a um sistema de
informações gerenciais existente, sem no entanto modificar o comportamento original do
software. Com isso, poderão ser definidos novos fluxos de processos e regras de negócio,
minimizando a necessidade de customização de software e aumentando a aderência aos
processos organizacionais.
O sistema proposto será modelado para que seja genérico, ou seja, possa ser aplicado
em qualquer sistema de informação gerencial. Como o sistema da presente proposta tem o
objetivo de trabalhar diretamente no banco de dados (de qualquer tipo) do sistema de
informação gerencial sendo customizado, a camada da aplicação não sofre modificação e,
assim, o sistema proposto pode ser aplicado em qualquer organização que utilize um software
de gestão.
Os objetivos específicos da proposta são:
a) Levantamento de requisitos do sistema;
b) Modelagem da arquitetura do software;
c) Implementação da solução;
d) Avaliação em um ambiente real;
e) Coleta e análise dos resultados.
A seguir, será apresentada a metodologia seguida para desenvolvimento do presente
trabalho.
1.3 Metodologia
Para a realização do presente trabalho, foram realizadas leituras em livros, artigos e
periódicos, com o intuito de fundamentar a teoria acerca dos assuntos abordados no presente
documento. As teorias utilizadas na pesquisa precisavam estar alinhadas à linha de
pensamento e de investigação desta. A fundamentação teórica precisou, ainda, servir de base
para a análise e interpretação dos dados coletados, com o objetivo final de auxiliar a etapa de
elaboração dos relatórios finais.
O presente trabalho caracteriza-se como sendo um estudo de caso. A posição tomada
na Conferência de Cambridge (ADELMAN et al., 1976) a respeito de uma definição de
estudo de caso, foi de que este é um termo amplo, incluindo “uma família de métodos de
17
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
pesquisa cuja decisão comum é o enfoque em uma instância”. Esta instância pode ser um
evento, uma pessoa, um grupo, uma escola, uma instituição ou um programa.
Após o aprofundamento teórico, foram realizadas observações diretas em processos do
setor administrativo do Centro Universitário Univates (UNIVATES), organização onde o
presente estudo de caso foi realizado. A UNIVATES é uma instituição de ensino superior
localizada em Lajeado, no Estado do Rio Grande do Sul e que também possui uma área
administrativa, como qualquer organização. Dessa forma, a UNIVATES também precisa gerir
suas informações através de um sistema de informação. Além disso, há a necessidade de um
alinhamento dos gestores com a TI para que os processos dos diversos setores administrativos
sigam seu fluxo de acordo com a estratégia da organização.
O ERP utilizado pela instituição é o Microsiga Protheus (versão 11) da empresa
TOTVS. Este será o ERP abordado durante o desenvolvimento da presente proposta, e cuja
base de dados será explorada.
No estudo de caso foi verificada a necessidade de aplicação do sistema proposto nos
seguintes setores administrativos da instituição: Compras, Patrimônio, Financeiro e Recursos
Humanos. Estes setores participam do processo de negócio da instituição, e utilizam o ERP
Microsiga Protheus 11 diariamente na elaboração de suas atividades.
Para executar os procedimentos visando o levantamento dos processos junto aos
setores administrativos da UNIVATES, foi necessário apoio do setor de gestão de processos
da instituição. O objetivo principal do acompanhamento presencial de um integrante do setor
de gestão de processos foi auxiliar o mapeamento dos processos do setor visitado. O
responsável pelo setor visitado precisou acompanhar as observações e coleta de informações,
interagindo com os entrevistadores.
A partir destas observações e mapeamentos realizados, houve uma quantidade
significativa de informações as quais possibilitaram gerar um estudo aprofundado de maneira
a permitir o conhecimento mais amplo e detalhado do processo. Após, foi avaliado juntamente
com o setor de gestão de processos se a forma de trabalho dos setores estão adequadas com a
estratégia da instituição. Se não estiver, os gaps1 identificados devem ser solucionados.
Nesta etapa entra em cena o sistema proposto. Seu objetivo principal é a resolução dos
gaps via customização do ERP, com a criação de regras e gatilhos (na modelagem do sistema
serão chamados “ações”).
1 Gaps: Na área de Sistemas de Informação, gap pode ser utilizado para identificar uma determinada funcionalidade de um sistema, o qual não atende total ou parcialmente a necessidade do cliente, que por sua vez, pode estar avaliando, implantando ou utilizando o sistema.
18
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
A metodologia utilizada precisou explicar de forma teórica os procedimentos
realizados desde a etapa de coleta de dados, até a análise e posterior discussão dos resultados.
A abordagem foi qualitativa, ou seja, os resultados obtidos foram analisados e
avaliados de uma forma descritiva; não medidos estatisticamente (SANTOS, 2002). Em suma,
a partir deste estudo de caso, foram mapeados alguns processos que necessitam customização,
e a ferramenta foi aplicada posteriormente para automatizar a customização.
Outro ponto importante a ser salientado, e que também foi considerado quanto à
aderência da presente proposta, foram os atuais gastos com despesas do setor de TI com
customizações no ERP Microsiga Protheus. Foi verificado junto ao responsável pela TI da
instituição que o apoio de um sistema de notificações poderia auxiliar na identificação de
reais necessidades de customização e, ainda, diminuir os custos com customizações
desnecessárias
Após o término do procedimento de coleta de dados junto aos setores, foi obtida uma
quantidade de dados satisfatória para que seja inciada a modelagem do software
desenvolvido. A modelagem baseou-se nas necessidades levantadas na etapa de levantamento
de requisitos de software.
Ao final, uma pesquisa qualitativa foi realizada com os usuários para avaliar, a partir
dos dados coletados, o quão satisfatória foi a ferramenta. O objetivo desta pesquisa é
sintetizar os resultados obtidos, a fim de indicar limitações, reconsiderações, apontar relação
entre fatos verificados e teoria, além de contribuir ao meio acadêmico através da pesquisa
científica.
1.4 Roteiro do restante do trabalho
Para a melhor compreensão da presente proposta, seus capítulos foram divididos em
uma ordem de apresentação.
No Capítulo 2, é descrito o referencial teórico utilizado como embasamento para o
desenvolvimento da proposta, que conta com conteúdos descritivos como: Sistemas de
Informações, Gestão Estratégica da Informação, Enterprise Resource Planning (ERP), Gestão
de Processos e Customização de Software.
O Capítulo 3 irá apresentar uma visão geral do trabalho proposto. Sua arquitetura,
modelos, e especificações de casos de uso serão alguns dos tópicos abordados.
E, por fim, no Capítulo 4 é feita a conclusão do presente trabalho.
19
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2 REFERENCIAL TEÓRICO
Esta seção tem por objetivo analisar as referências bibliográficas utilizadas no
desenvolvimento do trabalho. Cada item da seção é importante, pois apresenta uma breve
discussão teórica do problema, na perspectiva de fundamentá-lo. Será buscada a identificação
do significado de cada conceito chave para a pesquisa, e de como estão relacionados entre si.
2.1 Sistemas de Informações Gerenciais
Os sistemas de informações gerenciais, também chamados de sistemas de apoio à
gestão empresarial, surgiram a partir de uma necessidade comum entre as organizações:
transformar os dados de operações desta organização para agrupá-los e, desta forma, facilitar
a tomada de decisões pelo corpo gestor ou gerencial das unidades departamentais, em
conjunto com as demais unidades. A característica principal dos sistemas de informações
gerenciais é a apresentação dos dados agrupados, seja em totais, percentuais ou acumuladores.
Segundo (REZENDE; ABREU, 2003), enquadram-se nessa classificação, como
exemplo, os grupos de informações de sistemas de:
a) Planejamento e controle de produção (PCP): total da quantidade produzida;
b) Faturamento: valor do faturamento de um dia, ou valor acumulado do mês;
c) Contas a pagar ou receber: títulos a pagar do dia, número de inadimplentes;
d) Estoque: percentuais de estoque distribuído por grupos de materiais;
e) Contabilidade fiscal: acumulados de impostos a recolher por mês e ano;
f) Folha de pagamento: valores acumulados de salários e de encargos sociais.
Esta característica de agrupamento é fundamental para que os administradores
adquiram um melhor conhecimento das operações da organização, podendo, assim, obter
reflexos positivos no processo de planejamento e controle do negócio (BEAL, 2004).
Para (OLIVEIRA, 2004), quando os administradores consideram o SIG, precisam ter
em mente que o mesmo aborda apenas uma parcela das informações globais da empresa.
Precisam, ainda, lembrar-se que o SIG é um sistema para proporcionar ao referido
administrador informações seguras para a tomada de decisões sólidas que resultem na
concretização dos objetivos previamente estabelecidos. O SIG, portanto, precisa ser
visualizado como uma ferramenta administrativa de significativo auxílio para os executivos
das empresas.
Um dos papéis dos administradores é aumentar a eficiência global do SIG através do
aperfeiçoamento da integração dos diversos subsistemas (também conhecido por módulos)
20
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
sem perder a visão do todo, que é a empresa. Pode ser verificado, na Figura 3, uma ilustração
contemplando alguns dos diversos subsistemas que podem estar presentes em um SIG, bem
como suas relações no processo chamado Tratamento Integrado de Informações (OLIVEIRA,
2004).
Figura 3 - Tratamento integrado de informações
Fonte: Oliveira (2004).
Esta figura serve apenas como uma base para ilustrar alguns subsistemas presente em
um SIG e suas relações no negócio da empresa, pois foi verificado nas diversas bibliografias
consultadas que cada sistema possui a sua peculiaridade; seus módulos e relações podem
variar, dependendo de variáveis como: abrangência, foco e ramo da empresa. Mesmo assim,
percebeu-se que alguns subsistemas estão presentes em praticamente todos os SIGs, como por
exemplo: contas a receber, controle de estoque e contabilidade. Esta constatação reforça a
importância destes módulos no processo de integração entre as diversas áreas da empresa.
2.1.1 Importância dos sistemas de informações gerenciais para as empresas
Um aspecto importante a ser destacado é a interação da informação com o processo
decisório. Uma forma esquemática resumida desta interação pode ser visualizada na Figura 4.
21
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 4 - Interação da informação no processo decisório
Fonte: Oliveira (2004).
Atualmente, tem-se uma certa dificuldade em mensurar, de uma forma quantitativa,
qual o efetivo benefício de um sistema de informações gerenciais, ou seja, a melhoria no
processo decisório. Pode-se trabalhar com uma lista de hipóteses sobre o impacto do SIG nas
empresas, o que propicia ao executivo um entendimento, ainda que genérico, de sua
importância.
Nesse sentido, para (OLIVEIRA, 2004) afirma-se que o SIG, sob determinadas
condições e variáveis particulares envolvidas em cada situação, pode proporcionar os
seguintes benefícios para as empresas:
a) Redução dos custos das operações;
b) Melhoria no acesso às informações, ou seja, geração de relatórios mais
precisos, com menor esforço;
c) Melhoria na produtividade, tanto setorial quanto global;
d) Melhoria na tomada de decisões, através de informações mais rápidas e
precisas;
e) Melhor interação com os fornecedores;
f) Redução do grau de centralização de decisões na empresa;
g) Automatização dos processos da empresa de uma maneira geral, reduzindo o
fluxo de processos manuais;
h) Amento do nível de motivação das pessoas envolvidas.
22
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Entretanto, para que as empresas possam usufruir destes benefícios é necessário que
alguns aspectos sejam observados. Há a necessidade de um envolvimento da alta e média
administração com o SIG. Se o envolvimento não for o adequado, pode provocar situação de
descrédito para com o sistema. O executivo precisa lembrar que o SIG é um instrumento
básico para o processo decisório e este deve estar sempre com as informações atualizadas,
além de estar direcionado para os resultados. É importante salientar que a participação dos
vários usuários do sistema envolvidos no processo de operacionalização do SIG precisa ser
efetivada com responsabilidade.
Outro aspecto a ser observado é a necessidade de apoio de uma adequada estrutura
organizacional, bem como normas e procedimentos inerentes aos sistemas. Nesse caso, a
estrutura organizacional aparece como um instrumento administrativo do SIG, o qual precisa
ser racionalizado por meio de normas e procedimentos. Será abordado na Seção 2.4, Gestão
por Processos, os conceitos relativos à estrutura organizacional, alinhada aos processos de
negócio da empresa.
2.2 Gestão Estratégica da Informação
Nesta Seção serão abordados conceitos relativos à Gestão Estratégica da Informação e
sua importância no contexto organizacional.
2.2.1 Estratégia e Informação
O primeiro conceito de estratégia conhecido fora aplicado em meio militar, no
processo de preparação para as guerras. O objetivo principal da utilização da estratégia neste
contexto militar estava relacionado ao planejamento e mobilização da larga escala de
operações militares ou manobras e, assim, obter posições vantajosas em relação ao inimigo
(GURALINK, 1982) apud (BEAL, 2004) .
Com o passar do tempo, apareceram visões sobre o significado da estratégia no meio
corporativo. Na década de 90, Michael Porter, considerado uma das principais autoridades
mundiais em estratégia competitiva, difundiu que a ideia da estratégia consiste em realizar um
conjunto de atividades distintas dos competidores, que signifique maior valor para os clientes
e/ou crie um valor comparável a um custo mais baixo (PORTER, 1996) apud (STAREC,
GOMES, 2006). Não há um conceito universalmente aceito para o termo, entretanto destaca-
se que uma característica típica da estratégia é sua vinculação a um prazo de execução,
durante o qual deve ser objetivo de reavaliações. Com as constantes mudanças que ocorrem,
23
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
sejam de clientes, do mercado, dos canais de comunicação, da venda e da distribuição, as
empresas precisam manter-se flexíveis e reavaliar de tempos em tempos se as estratégias
adotadas permanecem apropriadas, ou se é necessário adaptá-las ou até substituí-las.
Para (BEAL, 2004) a informação é essencial para a implementação e avaliação de
qualquer estratégia. Se os gestores responsáveis pela elaboração da estratégia não tiverem em
mãos as informações adequadas a respeito das variáveis do processo onde a organização se
insere, pode acontecer de não conseguirem identificar todos os fatores que devem ser
considerados na tomada de decisões estratégicas. Segue a Figura 5, ilustrando a informação
como matéria-prima para a formulação da estratégia.
Figura 5 - A informação como matéria-prima para a formulação da estratégia
Fonte: Beal (2004).
Além de servir como matéria-prima para a formulação da estratégia, a informação
também deve ser objeto de um planejamento estratégico, a fim de que possam ser escolhidas
possibilidades e ênfases em relação à informação e aos fluxos informacionais da organização.
Em detrimento da característica de cada estratégia corporativa, os esforços podem tanto serem
concentrados na obtenção, tratamento e disseminação da informação mais útil para apoiar a
execução da estratégia, bem como na adaptação dos fluxos informacionais às novas
exigências dos ambientes interno e externo.
24
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.2.2 Estratégia e Competitividade: algumas abordagens de estratégia
Porter (1986) apud Starec e Gomes (2006) destaca a importância da formulação de
estratégias competitivas, ou, em outras palavras, ações a serem adotadas pelas empresas
visando criar uma posição que enfrente com sucesso as forças competitivas.
Para (ANSOFF, 1993) apud (STAREC; GOMES, 2006), é importante que se destaque
inicialmente o planejamento e, posteriormente, a administração estratégica, sendo que o
planejamento parte de uma análise das perspectivas da empresa, de modo a identificar
aspectos que possam alterar as tendências históricas, além de identificar novas áreas de
negócio compatíveis com as capacidades da empresa. Por sua vez, a administração estratégica
preocupa-se em ir além, acrescentando novos ingredientes ao planejamento estratégico,
incorporando as potencialidades, sendo determinadas por cinco componentes:
a) Qualificações e mentalidade dos principais administradores;
b) Clima social (cultura) da empresa;
c) Estrutura interna do poder;
d) Sistemas e estrutura gerencial;
e) Capacidade de administração geral para o trabalho de gestão.
A partir destes componentes e dos modelos de análise de forças competitivas
pesquisados nas referências bibliográficas do presente trabalho, foi verificado que a
construção da estratégia baseia-se na tentativa de tornar a empresa diferente em relação aos
concorrentes. Sendo assim, a operacionalização, o acompanhamento e o controle do plano
estratégico visam possibilitar que a empresa alcance seus objetivos. Para isto, e para também
buscar uma maior produtividade, muitas organizações incorporam ferramentas e técnicas
gerenciais que aumentam de forma considerável a eficácia operacional (STAREC; GOMES,
2006).
2.2.3 O alinhamento com a TI
Segundo (STAREC; GOMES, 2006) é preciso que a TI suporte a estratégia, provendo
a automação dos processos de negócio. Orientar a estratégia de TI para equilibrar
adequadamente os investimentos entre os sistemas que suportam a empresa a transformam, ou
contribuem para o seu crescimento. Ainda sim, é necessário tomar decisões informadas sobre
o enfoque e prioridades relativas à utilização de recursos de TI, garantindo que estejam
disponíveis e, desta forma, cumprir às expectativas da organização.
25
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Um dos problemas relacionados com a TI atualmente é a desconexão entre a estratégia
de TI e a estratégia de negócio. Esta falta de alinhamento conduz a vários problemas de
negócio, incluindo os que se seguem:
a) Incapacidade do negócio em atingir o seu potencial completo;
b) Insucesso em identificar e capitalizar as oportunidades de negócio que podem
ser facilitadas pela TI;
c) Custos de operação potencialmente mais elevados e, consequentemente,
desvantagem competitiva, devido ao fracasso em substituir processos caros por
outros automatizados (a longo prazo) e de menor custo;
d) Um enfoque incorreto e ineficaz dos recursos relacionados com a TI;
e) Incapacidade para recrutar e manter pessoas de negócio e de TI de alta
qualidade;
f) Custos globais mais elevados.
Todos estes itens reforçam a constatação de que é preciso que a TI suporte a estratégia,
provendo a automação dos processos de negócio.
2.2.4 Os sistemas de informação como fonte de vantagem competitiva
A informação, ao ser considerada como importante fonte de vantagem competitiva,
passa a ser relevante para a formulação de estratégia para as empresas. Desta forma, a
tecnologia da informação é mobilizada para realizar o apoio ao processo de incorporação de
informações que de alguma forma agreguem valor à formação da estratégia.
Ansoff (1993) apud Starec e Gomes (2006) aponta a necessidade de um sistema de
informação sobre os concorrentes como forma de identificar antecipadamente possíveis
manobras e introduzir novos produtos ou atuar em novos mercados. Quanto mais rápido e
eficiente for o sistema de informações, mais as oportunidades poderão ser aproveitadas,
proporcionando maiores margens de lucro.
Todavia, a eficácia dos sistemas de informações e inteligência são frequentemente
questionados. Esta constatação foi verificada em diversas referências, como por exemplo
(MINTZBERG, 2000) apud (STAREC; GOMES, 2006), que critica os sistemas estruturados
de informação, destacando que as informações são muito agregadas para serem utilizadas
eficazmente na formulação de estratégias; as informações são limitadas no seu escopo, e
chegam tarde demais para serem usadas na formulação de estratégias.
26
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Nesse sentido, a partir da adoção de sistemas de informações, pode-se dispor de
informações formais e informais que, por exemplo, auxiliem a reflexão sobre o ambiente
externo, a construção e atualização de cenários, a formulação de estratégias e o
monitoramento de fatores críticos de sucesso (são características, condições ou variáveis que
devidamente gerenciadas, mantidas ou sustentadas podem apresentar um significativo
impacto para o sucesso dos negócios de uma empresa ou indústria em particular) (BEAL,
2004).
Outro aspecto importante é a necessidade de criação de uma cultura gerencial que
utilize a informação no processo decisório. Isso porque a cultura organizacional interfere na
definição do modo como a informação circula na empresa. Portanto, requer-se das unidades
organizacionais, responsáveis pela gestão da tecnologia da informação, a responsabilidade
pela criação de sistemas gerenciais que apoiem a circulação da informação e facilitem a sua
utilização, de modo a agregar valor às ações das equipes de trabalho e à tomada de decisões.
2.3 Enterprise Resource Planning
Nesta seção será abordada a evolução dos ERPs. Iniciar-se-á com um breve histórico
deste ramo de Sistema de Informação Gerencial. Após, será apresentada uma definição formal
de ERP. Por fim, será representada a sua arquitetura (de forma genérica).
2.3.1 Evolução dos Sistemas Integrados de Gestão Empresarial (ERP)
A utilização de computadores no suporte a informações gerencias (mais voltados a
processos de negócio) datam da década de 1960. Nesta época, os computadores eram caros e
lentos, além de ter uma limitação quanto à sua capacidade de processamento. O uso da
informática nesta época, então, baseou-se quase que exclusivamente ao controle de estoque, a
fim de automatizar processos informacionais que antes eram realizados manualmente.
Na década de 1970, os computadores tornaram-se mais baratos e mais rápidos, e em
virtude disto apareceram os primeiros sistemas de gestão, chamados de Materials
Requirements Planing (MRP), voltados para empresas manufatureiras. Estes sistemas MRP
realizavam o controle de estoque destas empresas, além de apoiar o processo de compra de
materiais e planejamento de produção. De uma maneira geral, os sistemas MRP não
proporcionavam suporte a PCP, e não integravam-se com outras aplicações (módulos)
utilizadas pela organização. Mesmo assim, a adoção de algoritmos MRP nessa época já
27
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
caracterizava o uso da tecnologia para mudar a forma de trabalho, uma vez que sua aplicação
manual era impraticável.
Os sistemas MRP II surgiram na década de 1980, na época em que os
microcomputadores estavam difundindo-se. Surgiu como uma ampliação dos MRPs, pois
além de executar funções de planejamento de produção e estoques, tratavam da capacidade de
produção e de aspectos financeiros, como orçamentação e custeio da produção. No início da
década de 1990, movimentos políticos (como a Guerra Fria e Queda do Muro de Berlim)
abriram oportunidades para a chamada “globalização”, o que tornou o ambiente de negócios
extremamente competitivo. Assim, a ampliação da área de cobertura dos sistemas MRP II
para o domínio das Finanças e dos Recursos Humanos prometia agilidade e redução de custos,
tornando-se mais atraentes. A expressão Enterprise Resource Planning, ou Planejamento de
Recursos da Organização, passou a ser utilizada para denominar este novo conceito de
sistema de informação, principalmente devido à sua grande amplitude funcional, como pode
ser verificado na Figura 6 (COLÂNGELO, 2001).
Figura 6 - Evolução das aplicações empresariais
Fonte: Colângelo (2001).
28
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.3.2 Definição de Sistema ERP
Não existe atualmente uma definição precisa e inquestionável sobre o que é um
sistema ERP. Segundo (COLÂNGELO, 2001), o ERP pode ser considerado um software que:
a) Automatiza e integra uma parcela dos negócios de uma empresa, podendo
abranger finanças, recursos humanos, contabilidade, estoques, entre outros;
b) Compartilha dados, visando a uniformidade do processo de negócio;
c) Produz e utiliza informações em tempo real.
Os primeiros sistemas ERP foram desenvolvidos com o objetivo de abranger
determinadas áreas da empresa (recursos humanos, contabilidade, contas a receber,
faturamento ou ao controle de estoques). Sua utilização era muito limitada, pois a
comunicação entre os sistemas era deficiente, quase mínima. O problema, portanto, com os
sistemas não integrados, é que torna-se difícil realizar a coordenação de diferentes áreas da
organização, e muitas tarefas acabam sendo redundantes. Como exemplo, pode ser
considerado o processo de criação de pedido de venda. Os dados do pedido de um cliente,
registrado no módulo de vendas, precisariam ser digitados novamente no módulo faturamento
quando os produtos são faturados. Os dados correspondentes ainda precisariam ser lançados
manualmente no módulo contas a pagar, além de ser feita a baixa dos estoques no módulo
controle de estoque.
A reação frente à esses problemas, foi integrar os sistemas entre si. A integração
presume o uso comum de dados, possibilitando consistência nos processos de negócio. Os
cadastros são únicos e compartilhados por todos os módulos e, desta forma, por todas as áreas
da empresa. Com a integração dos sistemas, um evento real é registrado uma só vez, e produz
efeito em todos os processos que estão envolvidos (SOUZA; SACCOL, 2003).
A integração, porém, também significa maior complexidade. Em um sistema
integrado, um processo pode sofrer um número maior de etapas a serem executadas, e sua
reversão, ou cancelamento, torna-se mais intrincada. Como exemplo, pode ser utilizado o
processo de estorno de uma nota fiscal. Para isto, em um sistema integrado, há a necessidade
de realizar simultaneamente (e sincronizadamente) a exclusão do título no setor financeiro,
promover o reingresso do material no estoque, e posteriormente executar ações fiscais.
Segue a Figura 7, demonstrando as áreas de aplicação de um sistema ERP.
29
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 7 - Áreas de aplicação de um sistema ERP
Fonte: Colângelo (2001).
Pode-se dizer também, que o ERP é um tipo de sistema que possibilita um fluxo de
informações único, contínuo e consistente por toda a empresa, sob uma única base de dados.
É um instrumento para melhoria de processos de negócios. Em síntese, o ERP é um sistema
que permite a visualização por completo das transações efetuadas pela empresa, desenhando
um amplo cenário de seus negócios (CHOPRA; MEINDL, 2003) apud (PADILHA;
MARINS, 2005).
2.3.3 Arquitetura e Principais Funcionalidades de um ERP
A partir de consulta realizada à ampla bibliografia sobre sistemas ERP, puderam ser
identificadas algumas características importantes acerca de sua arquitetura e funcionalidades:
a) Sua arquitetura de software possibilita agilidade no fluxo de informações entre
todas as atividades da empresa. É um amplo sistema de soluções e
informações;
b) A utilização de um banco de dados centralizado, além de uma plataforma
comum que interage com um conjunto integrado de aplicações, propicia a
fusão de todas as operações de negócio em um simples ambiente
computacional;
c) As funcionalidades do ERP representam uma solução genérica, o que acaba
refletindo em uma série de considerações sobre a forma como as empresas
operam em geral.
Segundo (PADILHA; MARINS, 2005) a utilização de sistemas ERP otimiza o fluxo
de informações e facilita o acesso aos dados operacionais, favorecendo a adoção de estruturas
organizacionais mais enxutas e flexíveis. Além disso, as informações tornam-se mais
30
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
consistentes, possibilitando a tomada de decisão com base em dados que refletem a realidade
da empresa.
A figura 8 apresenta as funcionalidades dos sistemas ERPs separando-as em funções
internas (back-office) e funções externas (front-office) .
Figura 8 - Funcionalidades de um Sistema ERP
Fonte: Colângelo (2001).
Os sistemas de informações gerenciais empresariais são uma plataforma de software
desenvolvida para integrar os diversos departamentos de uma empresa, possibilitando a
automação e armazenamento de todas as informações de negócios. Os ERPs têm um custo de
implantação altíssimo, sendo quase que exclusivo para grandes empresas. Empresas médias
interessadas nesse tipo de sistema devem analisar bem se vale a pena o alto investimento desta
integração. Além disso, os ERPs não são de fácil operação. As empresas, por vezes, precisam
de funcionários treinados para usar o programa, pois o fato de ser um sistema genérico acaba
tornando-o um sistema sem uma boa interface de leitura.
2.4 Gestão por processos
A partir da evolução dos mercados de consumo e o implemento das tecnologias de
produção, principalmente no período pós Segunda Guerra Mundial, verificou-se um
crescimento acirrado das organizações, constituindo os gigantescos conglomerados
industriais.
31
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Estes conglomerados eram estruturados verticalmente, ou seja, consistiam de uma
estrutura organizacional dividida em setores (também chamada de visão funcional). Esta
verticalização provocou a proliferação das estruturas organizacionais, sendo que a
especialização ocasionou a divisão do trabalho em funções (DE SORDI, 2009). A divisão em
funções criou dutos verticais de gestão, culminando com o distanciamento das empresas dos
seus objetivos de negócio.
Outra característica da visão vertical é o rompimento das vias de comunicação entre os
setores, isolando, assim, áreas que atuam em processos semelhantes, criando as chamadas
barreiras funcionais. Esta visão vertical também estimula a criação de barreiras hierárquicas,
sobretudo pela proliferação dos níveis hierárquicos, em que supervisores só falam com
supervisores e gerentes com gerentes e diretores. Estas constatações materializam o processo
de obstrução da comunicação que se instaura em uma estrutura organizacional deste tipo. Por
estas razões, a abordagem administrativa funcional é considerada um típico exemplo de
abordagem científica reducionista.
Houve, então, a necessidade de um movimento de reengenharia de processos. A
abordagem sistêmica para gestão das organizações passou a ser denominada no início da
década de 1990, sendo também conhecida como abordagem administrativa de gestão por
processos (ou, ainda, visão horizontal).
Com a adoção da visão horizontal, a estrutura da organização continua similar, com
cada setor executando as suas funções. A diferença está na autonomia que os responsáveis por
cada atividade possuem. Uma atividade passará de um nível setorial para processual, sendo
que todos os envolvidos saberão que estão fazendo parte de um processo e não apenas de uma
atividade, e entenderão mais amplamente os motivos da atividade estar sendo efetuada, assim
como os caminhos pelos quais esse processo percorre (DE SORDI, 2009). Segue Figura 9,
demostrando a modificação na estrutura organizacional, principalmente no que se refere à
comunicação, com o advento da estrutura orientada por processo.
32
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 9 - Exemplo de estrutura organizacional (Vertical e Horizontal)
Fonte: De Sordi (2009).
Para uma melhor compreensão das duas visões (Departamental e por Processos), segue
a Figura 10, a qual ilustra um comparativo entre elas, no fluxo de um evento qualquer.
Figura 10 - Visão Departamental e Visão de Processos
Fonte: De Sordi (2009).
Algumas vantagens que podem ser apresentadas a colaboradores para aderirem a esta
nova visão, de acordo com (DE SORDI, 2009):
a) Facilidade para treinamento de colaboradores novos;
b) Facilidade de entendimento do processo;
c) Facilidade para encontrar responsáveis por atividades;
d) Facilidade para encontrar informações sobre as atividades e processos;
e) Facilidade para localizar o ponto em que um processo encontra-se parado.
33
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.5 Mapeamento de processos
O mapeamento de processos é uma ferramenta utilizada para retratar os processos
organizacionais, sendo largamente aplicada em organizações que desejam migrar da visão
funcional para a visão por processos.
É na etapa de mapeamento de processos que os analistas vão adquirir visibilidade e
conhecimento sobre determinadas tarefas, definindo, assim, missão e objetivos,
responsabilidades, entradas e saídas, fornecedores e clientes (PAIM; CARDOSO;
CAULLIRAUX, 2009).
A realização de uma análise crítica poderá responder a diversas perguntas, tais como:
a) Este processo é realmente necessário? Agrega valor?
b) Qual é o impacto do processo para a organização?
c) Como está seu desempenho? Como medir a performance?
d) Pode ser melhorado? Atende aos objetivos definidos?
Com o mapeamento de processos tem-se, como resultado, uma visão atual, consegue-
se efetuar melhorias, sempre com o intuito de simplificar as tarefas.
Foi verificado, a partir das leituras realizadas nas diversas bibliografias, que esta
ferramenta é se suma importância para a presente proposta, visto que a partir do mapeamento
dos processos de negócio de uma empresa é possível detectar gaps no processo, como
problemas de comunicação, falhas de segurança, trabalhos repetitivos sem necessidade, erros
de operação (pela ausência de um controle de erros ou de transação), entre outros (PAIM;
CARDOSO; CAULLIRAUX, 2009).
2.6 BPMN - Business Process Modeling Notation
O BPMN, Business Process Modeling Notation (em português Notação de
Modelagem de Processos de Negócio) é uma representação gráfica contendo elementos como
atividades, responsabilidades e fluxos. Ela tem, como principal objetivo, utilizar-se desses
elementos para modelar processos de negócio (SANTOS, 2010).
Na notação BPMN existem elementos gráficos com finalidades específicas para
representar um fluxo, evento, ou atividade dentro do processo mapeado. A seguir serão
descritos os objetos de fluxo abordados no presente trabalho.
34
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.6.1 Evento
Evento é algo que acontece durante um processo. Estes eventos afetam o fluxo do
processo, causando-lhe algum impacto. Existem três tipos de eventos: início, intermediário e
fim (SANTOS, 2010), conforme Figura 11.
Figura 11 - Eventos, objetos de fluxo da BPMN
Fonte: Elaborado pelo autor.
2.6.2 Atividade
Atividade é o termo empregado para um trabalho executado. Algumas ferramentas de
modelagem de processo permitem a identificação das atividades com esteriótipos. Os
principais são: automáticas/serviço (sistema) e humanas (SANTOS, 2010). Um exemplo é
dado na Figura 12.
Figura 12 - Atividades, objetos de fluxo da BPMN
Fonte: Elaborado pelo autor.
2.6.3 Gateways
São utilizadoa para controlar decisões ou convergências de sequência de um fluxo.
Desta forma, é possível determinar decisões tradicionais, como unir ou dividir trajetos
(SANTOS, 2010). A figura 13 apresenta alguns tipos de gateways:
Figura 13 - Gateways, objetos de fluxo da BPMN
Fonte: Elaborado pelo autor.
35
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.6.4 Fluxo de Sequência
É usado para mostrar a sequência com que as atividades serão executadas em um
processo. A notação utilizada é uma seta, conforme Figura 14:
Figura 14 - Fluxo de Sequência, objeto de fluxo da BPMN
Fonte: Elaborado pelo autor.
2.7 Gaps
As diversas definições para gaps não se apresentam tão claras e confundem-se na
literatura, não permitindo uma definição singular. Dessa forma, a seguir, será apresentada a
definição de gap segundo o dicionário Michaelis.
Michaelis (2013) define gap como:
1 Abertura, fenda, brecha, fissura, intervalo. 2 parte ou espaço vazio, vácuo, branco, lacuna. 3 diferença grande de opinião ou de caráter, disparidade.
De acordo com a definição acima, pode ser constatado que gap significa uma falha,
algo que está faltando. Uma brecha no processo.
Um dos principais motivos para o acontecimento de gaps em processos, segundo Paim
(2002), é a falha na modelagem dos processos. Uma boa modelagem de processos deve
refletir as características dos processos com o nível ideal de detalhamento desejado. Este nível
ideal desejado está estritamente relacionado com as motivações da organização interessada na
modelagem de processos e precisa estar apoiada pela estratégia global desta. Dependendo da
motivação, como a de redução de falhas na integração de sistemas de informática, por
exemplo, os processos devem estar bem detalhados de forma que ofereça informações
suficientes para os envolvidos. Em contrapartida, motivações relacionadas à otimização da
tomada de decisão operacional não necessitam de um profundo detalhamento, tendo em vista
que uma visão macro dos processos é suficiente.
2.8 Customização
A implementação de sistemas ERP implica em grandes desafios para as organizações.
Segundo (ROTHENBERGER; SRITE, 2009), as empresas que implantam softwares deste
36
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
tipo geralmente falham nos estágios iniciais deste processo, ou excedem substancialmente o
custo do projeto de implantação. Através de estudos realizados nesta área, vários fatores são
apresentados como causadores deste insucesso, como o suporte técnico aos gestores,
performance do time do projeto, o processo de implantação em si, educação e treinamento e
uma customização mínima realizada.
Rothenberger e Srite (2009) ainda constatam que em todas as instalações de sistemas
ERP, algum grau de customização se faz necessário. Mesmo que os pacotes da aplicação
sejam desenhados para trabalhar em diferentes organizações (esse é o propósito do ERP, como
visto na Seção 2.3), uma grande parte deles não proporcionam todas as funcionalidades
necessárias para uma área específica de negócio. Não obstante, customizações que envolvem
adições de funcionalidades ao ERP, ou modificações no código fonte deste, podem
comprometer o sucesso do projeto de implantação, visto que muitas customizações elevam os
custos de projeto e estendem os limites de manutenção do software.
A Figura 15 demonstra os três níveis de customização de produto e os stakeholders2
envolvidos. Verifica-se que em cada nível, uma quantidade maior de questões são resolvidas.
Figura 15 - Níveis de Customização de Produto
Fonte: Rabiser et al. (2009).
2 Stakeholder (em português, parte interessada ou interveniente) é um termo usado em diversas áreas como administração e arquitetura de software referente às partes interessadas que devem estar de acordo com as práticas de governança corporativa executadas pela empresa.
37
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Para (RABISER et al. ,2009), os três níveis de customização de produto são:
a) Nível 1: Derivação do Produto por Fornecedores: Os fornecedores procuram
resolver as variabilidades verificadas do ERP, a fim de adaptar o produto
baseado nas características (requerimentos) do cliente;
b) Nível 2: Configuração do Produto pelos Usuários: É comum em várias
organizações que os clientes não são usuários finais, mas estão encarregados da
introdução do novo produto. Os clientes ainda precisam adaptar o produto para
as especificidades organizacionais (processo de negócio). Eles precisam, por
exemplo, ajustar as características do produto para acomodar as tarefas e regras
dos diferentes departamentos;
c) Nível 3: Personalização para os usuários finais: Os usuários finais do produto
adaptam ainda mais o produto para suas demandas específicas. Eles
personalizam a aplicação para as suas tarefas e responsabilidades específicas.
2.8.1 Desafios
Para (DITTRICH; VAUCOULEUR; GIFF, 2009), o principal desafio no processo de
customização é o entendimento do ERP.
Os autores constatam que até desenvolvedores mais experientes podem necessitar
auxílio de consultores especialistas em módulos específicos, caso a customização torne-se
muito complexa. Uma técnica possível seria a entrevista para tentar entender a parte
desconhecida do sistema, seja explorando o código fonte ou rodando testes em paralelo
através da interface para verificar quais tabelas são afetadas (e como são afetadas).
Geralmente a documentação do código fonte é pobre, e por isso muitas vezes qualquer
mudança no escopo pode impactar em outras partes do sistema. Em alguns casos, a ordem do
procedimento realizado influencia no resultado. É importante, acima de tudo, experiência em
um ERP específico. Esta é a técnica principal em customização de ERPs.
2.8.2 Testes
Testes rigorosos dependem de quanto o cliente se propõe a pagar pelo esforço extra.
Todavia, os clientes geralmente não priorizam os testes. Fornecedores também (os
desenvolvedores, no caso) baseiam-se no sistema padrão como correto, com exceção de bugs
conhecidos. Uma dificuldade encontrada é que geralmente é difícil testar modificações
isoladas no sistema padrão. Porém, desenvolvedores mais experientes sabem que mudanças
38
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
específicas podem afetar partes do sistema padrão e merecem testes adicionais para estas
respectivas partes do software.
Testes são normalmente feitos em um sistema de níveis. Isto quer dizer que um
desenvolvedor ou o consultor de implantação do projeto testam a característica através de
formas respectivas e eventualmente checam as tabelas da database em uma interface dedicada
para tal a fim de verificar se os dados estão corretos. Os testes são muitas vezes parte da
documentação.
Os fornecedores checam as características (features) que estão sujeitas ao contrato em
um teste de aceitação. Normalmente, consultorias corrigem os erros contemplados no contrato
nas primeiras semanas sem custos adicionais (DITTRICH; VAUCOULEUR; GIFF, 2009).
2.9 Arquiteturas Orientadas a Serviço e Web Services
Nesta seção serão providos os conceitos e terminologias básicas sobre web services e
Service Oriented Architetures (SOA), ou Arquiteturas Orientadas a Serviço, em português.
Será explicada a definição de web service, além do framework SOA, que visa auxiliar a
estruturação de uma aplicação baseada na tecnologia de web services.
2.9.1 Web Services
Os web services (WS) têm ganho respaldo desde que o termo foi introduzido, no ano
2000. Fornecedores de software (grandes e pequenos) vêm utilizando os WS em seus
produtos, e muitos destes estão envolvidos na “afinação” dos padrões desta tecnologia. No
início de sua utilização, houve uma lenta convergência sobre o entendimento comum do que o
termo significava (não havia uma simples, definição universalmente adotada, do que o termo
web service queria dizer) (GRAHAM; DAVIS; SIMEONOV, 2004). Por isso, o grupo de
trabalho de arquitetura de serviços web do WorldWideweb Consortium (W3C), que gerencia a
evolução das especificações SOAP e WSDL, desenvolveu a seguinte definição para um web
service:
“Um web service é um software com a finalidade de suportar a interação máquina a
máquina, através de uma rede utilizando protocolos padronizados. Outros sistemas interagem
com um WS da forma descrita utilizando mensagens SOAP, normalmente transmitidas
utilizando HTTP com uma serialização em XML, em conjunto com outros padrões utilizados
na web”.
39
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Um importante ponto a ser destacado, é que um web service não precisa
necessariamente estar na web. Pode estar em qualquer lugar na rede (Internet ou Intranet).
Outro ponto é que detalhes da implementação dos web services não são relevantes para o
programa que está chamando o serviço.
Graham, Davis e Simeonov (2004) propõem que em uma perspectiva técnica, um WS
nada mais é do que uma coleção de uma ou mais operações relacionadas que estão acessíveis
em uma rede e que são descritas por um serviço.
Em uma perspectiva de negócios, os WS vêm se tornando um importante conceito
para os processos de negócio das organizações. Para um gestor de negócio, os serviços web
convergem para a integração, ou seja, integram funcionalidades da aplicação dentro da
organização, ou integram aplicações entre os parceiros de negócio. A integração das
aplicações através dos web services permitem uma maior eficiência nas questões que
envolvem tempo e custo no que diz, por exemplo, no processo de recebimento de pedidos de
venda e solicitações de carregamento. Então, em uma perspectiva de negócio, um web service
é um processo de negócio disponibilizado em uma rede de dados para que parceiros de
negócio, tanto interna, como externamente, possam atingir objetivos comuns.
Em um panorama técnico, o WS nada mais é do que uma coleção de uma ou mais
operações relacionadas que estão acessíveis em uma rede de dados. Com os web services, a
indústria de TI está solucionando um dos principais desafios da computação distribuída:
localizar e acessar componentes remotos. A solução deste problema está próximo, através de
utilização de tecnologias abertas (XML e protocolos internet) e padrões abertos patrocinados
por amplas consultorias.
2.9.2 Arquiteturas Orientadas a Serviço
Arquitetura Orientada a Serviços, ou Service Oriented Architecture (SOA) em Inglês,
é uma metodologia de programação criada para interligar diferentes softwares de uma forma
simplificada e unificada.
Seu foco é a interoperabilidade, e pode ser adaptável em quase todas as situações. Ela
já está em constante utilização no desenvolvimento de aplicações (O'BRIEN; MERSON;
BASS, 2007).
Em uma SOA, todos os componentes de software são modeladas como serviços. A
premissa, então, é de que todas as tarefas ou processos de negócio que são construídas em
software sejam designadas como serviços para serem acessados na rede.
40
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
O SOA trabalha diretamente com web services, e nada mais é do que a transformação
da metodologia SOA em código fonte.
Para garantir a interoperabilidade dos serviços web através das plataformas, os
serviços web utilizam basicamente dois padrões: web service Description Language (WSDL)
e Simple Object Access Protocol (SOAP), que são padrões abertos e de ampla utilização.
A Arquitetura Orientada a Serviços pode ser bem representada a partir do processo
chamado de "find-bind-execute paradigm", ou “paradigma procura-consolida-executa".
Na Figura 16, é exemplificada uma estrutura SOA.
Figura 16 - Paradigma procura-consolida-executa
Fonte: O'Brien, Merson e Bass (2007).
De uma forma resumida, seguem as três responsabilidades contidas em um SOA:
a) Service Provider (Porvedor de Serviço): É responsável por criar uma descrição
de serviço;
b) Service Requestor (Requisitor de Serviço): É responsável por encontrar uma
descrição de serviço;
c) Service Registry (Registro de Serviço): É responsável por referenciar um local
em que os provedores de serviço podem transmitir informações.
2.9.3 O protocolo SOAP
Para descrição dos tipos e estruturas de dados em SOA, os desenvolvedores fazem
amplo uso da linguagem XML. Também baseada em XML, a web services Description
Language (WSDL) normalmente descreve os serviços, enquanto o protocolo SOAP descreve
os protocolos de comunicação.
Embora a definição de web service seja bastante ampla (conforme Seção 2.9.1), é
claramente verificado que o SOAP está no núcleo de qualquer tecnologia de web services. É
simples e flexível. Pode ser utilizado de muitas maneiras para preencher as necessidades de
diversos cenários em aplicações de web service (O'BRIEN, MERSON, BASS, 2007).
41
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
O SOAP é um protocolo para troca de informações estruturadas em uma plataforma
distribuída. Baseia-se na utilização de XML para seu formato de mensagem, e normalmente
em outros protocolos da camada de aplicação, mais notavelmente em Chamadas de
Procedimento Remoto (RPC) e Protocolo de Transferência de Hipertexto (HTTP) para a
negociação e transmissão de mensagens.
O SOAP pode formar a camada base de uma pilha de protocolos de web services,
fornecendo um espécie de framework de mensagens básico sob o qual os serviços web podem
ser construídos. Este protocolo baseado em XML consiste de três partes: um envelope, que
define o que está na mensagem e como processá-la, um conjunto de regras codificadas para
expressar instâncias do tipo de dados definidos na aplicação e uma convenção para
representar chamadas de procedimentos e respostas.
Sua especificação ainda define um framework que proporciona diversas maneiras para
se construir mensagens que podem trafegar através de protocolos, e foi especificado de forma
a ser independente de qualquer modelo de programação ou outra implementação específica.
Geralmente servidores SOAP são implementados utilizando-se servidores HTTP,
embora isto não seja uma restrição para funcionamento do protocolo. As mensagens SOAP
são documentos XML que aderem a uma especificação fornecida pelo órgão W3C.
2.10 XML – Extensible Markup Language
XML, Extensible Markup Language, é uma linguagem de marcação de propósito
geral, recomendada pelo W3C.
Desde sua introdução, em 1998, a Extensible Markup Language (XML) vem
revolucionando a maneira de pensar sobre estruturação, descrição e troca de informações. As
maneiras em que o XML esta sendo usado na indústria de software são muitas, e aumentando.
Certamente, para web services, a importância do XML é suprema; todas as tecnologias de
web service chaves são baseadas nele (GRAHAM; DAVIS; SIMEONOV, 2004).
Por ser um padrão muito difundido e utilizado em diversos softwares de modelagem
de processos de negócio, e por estar presente na descrição dos tipos e estruturas de dados em
SOA, foi escolhido para estar presente na arquitetura deste trabalho.
42
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.11 UML - Unified Modeling Language
A Unified Modeling Language (UML) ou Linguagem de Modelagem Unificada, é uma
linguagem visual criada para auxiliar o processo de modelagem de softwares baseados no
paradigma de orientação a objetos. Atualmente (e nos últimos anos), esta linguagem está
sendo adotada como padrão pela indústria de engenharia de software, em âmbito internacional
(GUEDES, 2009).
É importante ressaltar que a UML é uma linguagem de modelagem, e não uma
linguagem de programação. Seu objetivo é auxiliar os engenheiros de software a definirem as
características do sistema (requisitos, comportamento, estrutura lógica e processos). Através
da UML, estas características podem ser definidas antes mesmo do software começar a ser, de
fato, desenvolvido. A UML, portanto, não é um processo de desenvolvimento de software; é
totalmente independente, podendo ser utilizada por diversos processos de desenvolvimento
diferentes ou da forma que o engenheiro considerar mais adequada (BEZERRA, 2007).
A UML é composta por diversos diagramas, cujo objetivo é prover múltiplas visões do
sistema a ser modelado. Nesse sentido, cada diagrama analisa o sistema sob uma determinada
ótica, mas no final do processo é atingido a completude da modelagem, já que os diagramas
se complementam e assim teremos uma modelagem de todas as funcionalidades do sistema a
ser desenvolvido.
Dentre os diversos diagramas que a UML define, será descrito rapidamente sobre cada
um dos diagramas oferecidos pela UML e que serão utilizados na presente proposta. São eles:
Diagrama de Casos de Uso, Diagrama de Classes e Diagrama de Componentes.
2.11.1 Diagrama de casos de uso
Este é o diagrama mais geral e informal da UML. É utilizado principalmente nas fases
de levantamento e análise de requisitos do sistema. Procura ilustrar os atores (usuários, outros
sistemas, ou até mesmo algum hardware especial) que irão interagir de alguma forma com o
software. A notação utilizada para ilustrar os atores tem a forma de um boneco, com seu nome
definido abaixo deste. O caso de uso é representado por uma elipse, e o relacionamento de
comunicação é representado por um segmento de reta ligando ator e caso de uso (BEZERRA,
2007). A Figura 17 apresenta um diagrama de caso de uso em que é exemplificado um
Fornecedor podendo acessar os dados de um pedido de compra, enquanto o Comprador
possui, além do acesso para visualização, acesso para alterar dados deste pedido.
43
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 17 - Exemplo de um Diagrama de Caso de Uso
Fonte: Bezerra (2007).
2.11.2 Diagrama de classes
O diagrama de classes é utilizado na construção do modelo de classes. Dentre todos os
diagramas UML, o diagrama de classes é considerado o mais completo em termos de notação.
Nesta subseção, serão abordados os elementos do diagrama de classes utilizados para a
criação do modelo de classes.
Em UML, uma classe é representada por uma caixa com, no máximo, três
compartimentos. De cima para baixo, no primeiro compartimento é exibido o nome da classe.
Esse nome sempre é apresentado (por convenção) no singular e com as palavras componentes
começando com letras maiúsculas. No segundo compartimento, são apresentados os atributos
da classe, ou seja, as informações que este armazena. No terceiro compartimento, são
declaradas as operações, que nada mais são do que as ações que a classe irá realizar. Não é
necessário o preenchimento de todos os retângulos, pode-se criar um diagrama mais simples
contendo apenas o nome das classes (BEZERRA, 2007).
Para uma melhor compreensão do que foi descrito, segue Figura 18, demonstrando a
estrutura de uma classe.
44
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 18 - Exemplo de estrutura de classe em UML
Fonte: Elaborado pelo autor.
2.11.3 Diagrama de Componentes
Segundo (GUEDES, 2009), o diagrama de componentes está ligado diretamente à
linguagem de programação escolhida para ser utilizada no desenvolvimento do sistema
modelado. Este diagrama representa os componentes do sistema quando este for
implementado, como por exemplo: código-fonte, bibliotecas utilizadas, formulários, módulos
auxiliares e sistema gerenciador da base de dados.
A Figura 19 apresenta o exemplo de um diagrama de componentes para um Sistema de
Controle Bancário.
Figura 19 - Exemplo de diagrama de componentes
Fonte: Guedes (2009).
45
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2.11.4 Diagrama de Atividades
Neste tipo de diagrama são representadas as atividades de um processo. O diagrama de
atividade é orientado a fluxos de controle, podendo ser considerado como uma extensão dos
tradicionais fluxogramas.
Os elementos de um diagrama de atividade são divididos em dois grupos: os que são
utilizados para representar fluxos de controle sequenciais, e os que são utilizados para
representar fluxos de controle paralelos. Estes elementos são ilustrados na Figura 20 e
descritos nas seções a seguir (BEZERRA, 2007).
Figura 20 - Exemplo de diagrama de atividades
Fonte: Bezerra (2007).
46
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3 TRABALHO PROPOSTO
O propósito básico do sistema proposto é fornecer uma ferramenta auxiliar para
automatizar a customização de processos de negócio. O fato de ser uma ferramenta auxiliar,
implica que a organização onde a presente proposta poderá ser implantada obrigatoriamente
deverá ter em produção algum sistema de informação gerencial.
O nome da ferramenta será CustomEasy. Custom, de customizar; Easy, que significa
“fácil”, em Inglês. O próprio soar da palavra lembra a palavra “customize”, em Português. Por
estes motivos, este foi o nome escolhido para o sistema, mesmo que a concordância entre as
palavras, na língua Inglesa, não esteja correta.
Paralelamente à etapa de definição do escopo da ferramenta, foi pesquisado na
documentação de softwares de gestão conhecidos em escala mundial, como o ERP Microsiga
Protheus 11, da empresa brasileira TOTVS, e o ERP SAP AG, da Empresa Alemã SAP AG, e
foi verificado que as funcionalidades do sistema proposto não estão presentes em qualquer um
dos softwares pesquisados.
Foram também realizadas pesquisas na Internet para identificar sistemas com
funcionalidades semelhantes às do projeto proposto. Foi identificado que existem diversos
sistemas que emitem notificações por padrão, porém estes não tomam ações. Sua função
nestes softwares, portanto, é somente notificar o usuário, diferentemente do sistema
CustomEasy, que além de notificar, tomará ações de diferentes tipos e terá diversos cadastros
e regras para administrar estas ações e as notificações em si.
3.1 Levantamento de requisitos do sistema
A modelagem dos diversos diagramas do sistema proposto baseou-se nas necessidades
levantadas na etapa de levantamento de requisitos de software.
Foram as descrições dos serviços e as restrições estabelecidas pelos usuários que
definiram as propriedades do sistema. Estes requisitos refletiram a necessidade dos usuários
frente ao sistema proposto, seguindo as restrições da organização onde o estudo de caso será
aplicado.
Como o sistema terá uma característica de um software do tipo “configurador”, ou
seja, o sistema se tornará operacional a partir de diversas configurações a serem realizadas
pelo usuário administrador do sistema, a etapa de levantamento de requisitos baseou-se
basicamente em observações dos processos dos setores administrativos da instituição, a fim de
verificar seus processos de negócio diários.
47
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Os requisitos foram divididos em requisitos funcionais e não funcionais. Os requisitos
funcionais (RF), que descrevem as funcionalidades que se espera que o software forneça
quando estiver pronto, como entradas, saídas, exceções, entre outros, são os seguintes:
a) RF001: Possibilitar a definição de regras com condições lógicas para execução
de ações personalizadas;
a) RF002: Possibilitar a notificação dos usuários quando tal regra é atendida;
b) RF003: Permitir executar ações automaticamente através de rotina agendada;
c) RF004: Possibilitar a conexão com outros sistemas quando uma condição for
atendida;
d) RF005: Permitir o cadastro de múltiplos servidores, de qualquer tipo;
e) RF006: Possibilitar a emissão de relatórios através de logs registros.
Os requisitos não funcionais (RNF) são as restrições ao software de uma maneira
geral. Não são, portanto, relativos diretamente às funções desempenhadas pelo produto. São
estes:
a) RNF001: Software será desenvolvido na linguagem de programação Java;
b) RNF002: O Banco de dados utilizado será PostgreSQL;
c) RNF003: A metodologia de desenvolvimento será orientada à objetos;
d) RNF004: Será armazenado histórico (log) de todas as ações executadas;
e) RNF005: Backup diário automático da base da dados;
f) RNF006: O Sistema deverá ser desenvolvido conforme o modelo MVC
(model, view, controller).
Os requisitos funcionais serão detalhados na seção 3.3.
3.2 Arquitetura do CustomEasy
O diagrama de componentes apresentado na Figura 21 demonstra a arquitetura do
sistema CustomEasy.
48
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 21 - Arquitetura do CustomEasy
Fonte: Elaborado pelo autor.
O diagrama de componentes da Figura 21 apresenta as formas de comunicação do
CustomEasy com os demais softwares utilizados pela organização.
Pode ser verificado no diagrama que haverá um servidor dedicado (custom server)
para o sistema proposto, porém este detalhe não é obrigatório. Poderá ser feito
compartilhamento de recursos com outro servidor, desde que os requisitos para o
funcionamento sejam atendidos. O CustomEasy conecta-se ao servidor do ERP através de
uma conexão via web service, possibilitando, desta forma, executar algum método para obter
informações do sistema de gestão.
O CustomEasy também poderá conectar-se à base de dados do ERP utilizado pela
organização através de uma conexão de banco de dados. Com isso, o sistema proposto pode
executar uma consulta qualquer no banco de dados do ERP, ou mapear alguma informação
específica a fim de verificar se houve mudança de valor e assim tomar alguma ação de banco
de dados.
De forma análoga, pode ser estabelecida uma conexão com o servidor de e-mails, mais
especificamente com o software gerenciador de e-mail da instituição, com o objetivo de
enviar as notificações aos usuários a partir das regras e ações de e-mail definidas.
49
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3.3 Casos de Uso
Após a etapa de levantamento de requisitos, foram definidos os papéis e
responsabilidades dos atores envolvidos nos casos de uso. Para auxiliar este processo, será
utilizado um diagrama de casos de uso, conforme Figura 22.
Pode ser verificado nesta figura que existem três atores envolvidos, sendo: o
Colaborador, o Administrador do Sistema e o ERP (Sistema de Informações Gerenciais)
utilizado pela organização.
Figura 22 - Diagrama de Casos de Uso
Fonte: Elaborado pelo autor.
50
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
As rotinas de cadastro serão disponibilizadas somente para o administrador do sistema,
e este, somente este, poderá cadastrar as regras, servidores, e ações intrínsecas à necessidade
levantada.
Para auxiliar o entendimento de cada caso de uso, se fará uso de capturas de tela (print
screen) do sistema. Desta forma, será explicado descritivamente todos os casos de uso com
auxílio das imagens capturadas.
Observação importante: como o sistema baseia-se em despachar tarefas a partir das
regras e ações cadastradas, todos os cadastros do sistema serão explicados detalhadamente.
Caso alguma informação não estiver cadastrada corretamente, o sistema poderá não funcionar
da maneira esperada.
Antes do detalhamento dos casos de uso, é apresentada na Figura 23 uma captura da
tela inicial do sistema proposto.
Figura 23 - Menu Principal do Sistema
Fonte: Elaborado pelo autor.
Ao clicar em qualquer uma das opções do menu à esquerda da tela, será carregado um
formulário na área delineada em vermelho. Isto significa que para cada uma das opções
selecionadas no menu da esquerda, este espaço marcado carregará diversas telas diferentes
(conforme será explicado posteriormente em cada caso de uso), possibilitando ao usuário
realizar um cadastro específico com poucos cliques.
51
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
As opções de cadastros genéricos (Regra, Ações e Frequências) têm a finalidade de
realizar o seu respectivo cadastro de forma separada. Posteriormente, estes cadastros podem
ser vinculados através dos cadastros específicos (Ação de Banco de Dados, Ação de web
service, Ação de e-mail, Regra de Banco de Dados, Regra de web service, Servidor de Banco
de Dados e Servidor de web service).
A seguir, será explicado cada caso de uso.
3.3.1 Cadastrar Servidores
Este caso de uso tem o objetivo de definir um servidor de banco de dados ou um
servidor de web services. Na Figura 24 é apresentada a tela de cadastro de servidores de banco
de dados.
Figura 24 - Tela de Cadastro de Servidores de Banco de Dados
Fonte: Elaborado pelo autor.
O campo Host define o endereço do servidor na rede. O campo Nome tem a finalidade
de registrar o nome da base de dados deste servidor, para ser facilmente identificado quando
houver necessidade de conexão. Já o campo Senha é necessário quando houver conexão à
base de dados com autenticação. No campo Tipo, é informado qual o tipo de Banco de Dados
(Postgres, Oracle, Mysql, entre outros). Por fim, no campo Usuário, deve ser informado um
usuário válido para criar a conexão com a base de dados.
52
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
A seguir, na Figura 25, é demonstrada a tela correspondente ao cadastro de servidores
de web services.
Figura 25 - Tela de Cadastro de Servidores de web services
Fonte: Elaborado pelo autor.
O campo Endereço define o endereço do web service disponibilizado pelo Sistema de
Informações Gerenciais. Através deste endereço, é possível buscar informações do SIG, desde
que este possua um serviço de web service disponível. O campo Nome tem a finalidade de dar
um nome para este servidor, possibilitando que seja identificado com mais facilidade no
cadastro.
3.3.2 Cadastrar Regras
Caso de uso que tem por finalidade cadastrar Regras de Banco de Dados e Regras de
web service. A Figura 26 representa o primeiro passo para cadastrar uma regra, independente
do tipo. É necessário criar uma regra genérica antes de vinculá-la à uma regra específica
(Banco de Dados ou web service), pois o sistema foi projetado para que a regra específica
possa ser vinculada posteriormente, conforme a necessidade.
53
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 26 - Tela de Cadastro de Regras
Fonte: Elaborado pelo autor.
Toda Regra necessita de algumas informações básicas para tornar-se utilizável pelo
sistema. O campo Nome define um nome para a Regra sendo cadastrada. No campo
Condição, deverá ser informado uma condição que, juntamente com o campo Valor, irá
verificar se esta Regra é válida ou não. O campo Frequência permite definir uma frequência
de verificação desta regra, desde que o próximo campo, Habilitada, esteja informado com o
valor “Sim”. E, por fim, o campo Tipo define o tipo de regra a qual está sendo vinculada. Esta
informação pode ser omitida, visto que o tipo de regra pode ser informado posteriormente,
mudar de tipo conforme a necessidade, ou ainda ser utilizada por uma ação de e-mail. Ações
de e-mail não necessitam uma regra específica.
Depois de definida a Regra, o próximo passo é cadastrar algum tipo de Regra
específica. A Figura 27 apresenta a tela de cadastro de Regra do tipo Banco de Dados.
54
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 27 - Tela de Cadastro de Regra de Banco de Dados
Fonte: Elaborado pelo autor.
Segundo Figura 27, podem ser verificados três campos. O campo Regra permite
selecionar uma Regra genérica previamente cadastrada. O campo Servidor BD permite
selecionar um Servidor de Banco de Dados cadastrado no sistema, enquanto o campo de texto
Query define a consulta que será executada na base de dados do SIG.
Na Figura 28 é apresentado o cadastro de uma Regra de web service. Existem dois
campos a serem preenchidos. O campo Regra define uma Regra genérica previamente
cadastrada, enquanto o campo Servidor WS tem o propósito de definir um servidor para esta
regra de web service.
55
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 28 - Tela de Cadastro de Regra de web service
Fonte: Elaborado pelo autor.
3.3.3 Cadastrar Ações
Neste caso de uso, o Administrador do Sistema pode cadastrar diferentes tipos de
Ações e vinculá-las à Regras previamente cadastradas. Segue a Figura 29, que demonstra a
tela de cadastro de uma Ação genérica.
Figura 29 - Tela de Cadastro de uma Ação
Fonte: Elaborado pelo autor.
56
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
De acordo com a Figura 29, o primeiro campo chama-se Regra. Este campo é utilizado
para selecionar uma Regra já cadastrada no sistema, vinculando-a a esta Ação. O segundo
campo, chamado Descrição, é utilizado para inserir uma pequena descrição sobre o propósito
ou utilidade desta Ação. Por fim, o campo Habilitada permite habilitar ou desabilitar a ação
conforme a necessidade.
As Ações específicas podem ser de três tipos: Ação de Banco de Dados, Ação de web
service e Ação de e-mail. A seguir, na Figura 30, é apresentada a tela de cadastro de uma ação
de Banco de Dados.
Figura 30 - Tela de Cadastro de uma Ação de Banco de Dados
Fonte: Elaborado pelo autor.
Conforme Figura 30, no campo Ação é possível selecionar a ação genérica
previamente cadastrada. Em Servidor BD, é possível selecionar o Servidor de Banco de
Dados no qual será executado esta ação. Esta ação pode ser de realizada de diversas maneiras,
como um comando insert na base de dados deste servidor, um select para selecionar uma
quantidade de registros, ou um update para alterar algum registro já existente. Para isto, é
necessário inserir uma instrução SQL no campo Query.
O próximo cadastro a ser explicado é o de Ação de web service. Este cadastro está
ilustrado na Figura 31.
57
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 31 - Tela de Cadastro de uma ação de web service
Fonte: Elaborado pelo autor.
No campo Ação é possível selecionar a ação genérica previamente cadastrada. Em
Servidor WS, pode ser selecionado um Servidor de web service no qual será executada
alguma ação. O campo Query String tem a finalidade de cadastrar uma string. Este campo
trabalha em conjunto com o campo Servidor WS, onde ambas as informações serão
concatenadas visando realizar o acesso a um determinado endereço de web service e, assim,
executá-lo de forma direta.
O terceiro caso de uso envolvendo ações específicas é o Cadastro de Ações de e-mails.
O objetivo deste caso de uso é informar os dados necessários ao sistema para que seja
possível o envio de e-mail automático quando uma ação de e-mail for executada. Para isto,
quatro campos precisam ser informados.
A Figura 32 apresenta a tela deste cadastro. No campo ação deve-se selecionar uma
ação genérica para esta ação de e-mail. O campo destinatário é utilizado para informar os
usuários que receberão este e-mail. O campo Assunto define o assunto deste e-mail, enquanto
no campo Mensagem é informado o texto do e-mail. Pode-se observar que no espaço
destinado para redação da mensagem é possível a inserção de variáveis definidas como sendo
o nome do campo, o qual será substituído pela valor da base de dados. Este padrão foi adotado
para que as mensagens não sejam fixas. Com o uso de variáveis, a mensagem do e-mail
poderá conter informações dinâmicas, ou seja, serão obtidas da base de dados em tempo real.
58
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 32 - Tela de Cadastro de uma ação de e-mail
Fonte: Elaborado pelo autor.
O último caso de uso envolvendo telas do sistema web é o Cadastro de Frequências. A
Figura 33 apresenta as informações necessárias para que este cadastro seja efetuado.
Conforme a Figura 33, de cima para baixo, o primeiro campo a ser preenchido é o
Tipo de Agendamento. Este campo traz quatro Tipos de Agendamento disponíveis para
seleção:
a) Tipo 1: Toda hora em um minuto determinado;
b) Tipo 2: Todo dia em uma hora determinada;
c) Tipo 3: Toda semana em uma dia determinado;
d) Tipo 4: Todo mês em uma dia determinado.
O campo Tipo de Agendamento trabalha em conjunto com os quatro campos auxiliares
deste cadastro (Dia da Semana, Dia do Mês, Hora e Minuto) para formação do tempo exato
determinante desta frequência. O algoritmo de verificação de regras (abordado na Seção 3.7
deste documento) analisa qual é o Tipo de Agendamento, e a partir do Tipo cadastrado, estes
quatro campos são verificados para que o agendador execute automaticamente o programa
principal no momento correto. Por fim, o campo Descrição é utilizado para que o registro seja
identificado na base de dados com maior facilidade.
59
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 33 - Tela de Cadastro de Frequências
Fonte: Elaborado pelo autor.
3.3.4 Fornecer Informações
Este caso de uso tem o objetivo de explicitar o ERP utilizado pela organização. O ERP
servirá como fornecedor de informações para o sistema proposto, através da disponibilização
da sua base de dados para consulta, interação, e posterior análise pelo administrador do
sistema e pelo usuário final.
Com o objetivo de validar os testes a partir de processos de negócio reais efetuados
pela Instituição onde foi aplicado o estudo de caso, foi necessário solicitar cópia de algumas
tabelas da base de dados do Microsiga Protheus 11. Para tal, foi solicitada autorização ao
coordenador de TI da referida instituição. Entretanto, por se tratarem de informações
administrativas sigilosas, foi autorizado uso somente do schema da base (tabelas e campos da
base de dados, sem dados inseridos nestes). Sendo assim, foi criada uma base de dados vazia e
foram inseridos dados fictícios, porém com tabelas e campos exatamente iguais aos do ERP
Microsiga. Mesmo que os dados inseridos não sejam reais, a consistência das informações em
60
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
cada tabela foi verificada e validada com os usuários participantes do processo de negócio.
Assim, a validação da ferramenta não foi prejudicada.
Não foi possível validar ações de web service dentro da Instituição estudo de caso, em
virtude do serviço de web service do Microsiga Protheus não possibilitar acesso direto. O ERP
utiliza um arquivo binário onde o web service é rodado, e este necessita configuração direto
na aplicação, sendo que qualquer mudança poderia afetar seu funcionamento no ambiente de
produção. Por isso, foi decidido não modificar as configurações do web service, visto que não
há um web service de testes rodando no servidor (pois consome licenças).
Por fim, é importante salientar que o sistema proposto deverá ser compatível com
qualquer tipo de base de dados, e com qualquer linguagem de programação utilizada na
implementação do software de gestão da organização.
3.3.5 Receber Notificações
Neste caso de uso, o usuário receberá as notificações a partir das regras definidas e
ações e servidores cadastrados. A apresentação desta informação para o usuário precisará ser
trabalhada de forma que não necessite esforço do mesmo para entendê-la.
As notificações serão visualizadas tanto para o usuário, como para o administrador do
sistema (para verificar inconsistências ou somente para fins de documentação). O envio destas
notificações será por e-mail, e haverá um log de registros de ações executadas caso algum
usuário solicitar algum relatório, para fins de conferência ou histórico de ações executadas. A
Figura 34 apresenta um e-mail enviado para o usuário contendo informações fictícias obtidas
da base de dados do ERP utilizado como estudo de caso para o presente trabalho.
Figura 34 - Exemplo de notificação enviada pelo CustomEasy
Fonte: Elaborado pelo autor.
61
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3.4 Diagrama de Atividades
Na Figura 35 é apresentado o diagrama de atividades do CustomEasy. O objetivo deste
diagrama é demonstrar a sequência de eventos internos do sistema. Isto quer dizer que os
eventos ilustrados no diagrama não são perceptíveis ao Administrador do Sistema, ou seja, o
sistema poderá estar executando alguma ação interna sem que o Administrador perceba.
Conforme demonstrado na Figura 35, a ferramenta inicialmente fará uma verificação
em todas as regras cadastradas na base de dados a fim de verificar se alguma delas foi
atendida. A frequência em que esta verificação será executada deve ser programada pelo
Administrador através de um campo específico no cadastro da Regra.
No momento em que o valor encontrado no cadastro da regra for encontrado, a(s)
ação(ões) vinculada(s) a esta regra será(ão) executada(s). Se executada com sucesso, esta ação
ficará gravada em um log para possíveis auditorias, e o sistema continuará a verificação.
Figura 35 - Diagrama de atividades do sistema CustomEasy
Fonte: Elaborado pelo autor.
62
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3.5 Modelo de Classes
O modelo de classes, ilustrado na Figura 36, representa os conceitos envolvidos. Cada
classe é uma “caixa” que possui, de cima pra baixo: o nome desta classe, seus atributos, e, por
fim, os métodos implementados. Os atributos de cada classe foram definidos de acordo com o
Modelo ER, o qual pode ser visto na Seção 3.6 deste documento.
Figura 36 - Diagrama de Classes
Fonte: Elaborado pelo autor.
63
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
As Tabelas enumeradas de 1 até 12 dispõem de uma breve descrição das classes,
atributos e métodos existentes no software proposto.
Tabela 1 - Descrição da Classe Regra
Classe RegraRepresenta uma regra definida pelo usuário envolvido no processo ou pelo administrador do sistema. Sua finalidade é de servir como base para a execução de ações. É esta classe que definirá o “gatilho”, ou seja, a regra responsável por disparar a ação. Atributosnome Nome da Regra.condição A condição que será utilizada para verificada o resultado da
consulta, em conjunto com o campo valor (>, <=, <, >= , =, <>).valor Um valor definido. Este valor, assim que atingido, pode disparar
uma ação específica.frequencia Frequência de execução da regra (horária, semanal, diária ou
mensal).habilitada Indica se a regra em questão está habilitada ou não.MétodosregrasAptas() Este método permite analisar a frequência de verificação de cada
regra cadastrada no sistema. Se a frequência cadastrada for igual ao horário do sistema, a regra é considerada como apta para despachar os tipos de ações vinculadas.
Fonte: Elaborado pelo autor.
Tabela 2 - Descrição da Classe RegraBD
Classe RegraBDRepresenta uma regra de Banco de Dados. Precisa estar vinculada a uma classe do tipo ServerDB e a uma classe Regra.Atributosservidor O servidor de banco de dados desta Regra de Banco de Dados.query A query (consulta) que será executada no banco de dados do
Sistema de Informações Gerenciais utilizado pela organização.MétodosretornaRegraBD(String id) Este método tem o objetivo de retornar um objeto do tipo
RegraBD, a partir do (id) da Regra genérica vinculada.executaQuery(String db, String query, String cond, String valor)
Método que tem por objetivo executar uma consulta (query) na base de dados (db) passados como parâmetro, sendo que o parâmetro (cond) e (valor) são utilizados para verificar se a regra é válida ou não. O retorno deste método é uma Lista de Listas de objetos do tipo Retorno.
Fonte: Elaborado pelo autor.
64
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Tabela 3 - Descrição da Classe RegraWS
Classe RegraWSRepresenta uma regra de web service, definida pelo usuário ou pelo administrador do sistema. Precisa estar vinculada a uma classe do tipo ServerWS e a uma classe Regra.Atributosnome_variavel Neste atributo ficará armazenado dentro da Regra de web
services o nome da variável retornada na consulta.MétodosretornaRegraWS(String id) Este método tem o objetivo de retornar um objeto do tipo
RegraWS, a partir do id da regra genérica na qual esta RegraWS está vinculada.
executaWS(String end) Método que tem por objetivo rodar um web service no endereço (end) passado como parâmetro. O retorno deste método é uma Lista de Listas de objetos do tipo Retorno.
Fonte: Elaborado pelo autor.
Tabela 4 - Descrição da Classe Acao
Classe AcaoEsta classe serve de ligação entre uma classe do tipo Regra e à três tipos de Ação possíveis. Ou seja, uma classe do tipo Regra pode estar vinculada à “n” ações, de qualquer um dos três tipos possíveis (web service, Banco de Dados e e-mail).Atributosdescricao Descrição da ação.habilitada Indica se a ação em questão está habilitada ou não.Métodos
Fonte: Elaborado pelo autor.
Tabela 5 - Descrição da Classe AcaoWS
Classe AcaoWSClasse que representa uma ação de web service.Atributosquery_string Este atributo é uma string contendo variáveis que serão
substituídas por valores no momento de rodar o web service.MétodosacoesWSDaRegra(String id_regra)
Este método retorna uma Lista de objetos do tipo AcaoWS vinculados à Regra cujo id é passado como parâmetro (id_regra).
executaWS(String endereco)
Método que tem por finalidade executar um web service no endereço (end) passado como parâmetro.
Fonte: Elaborado pelo autor.
65
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Tabela 6 - Descrição da Classe AcaoBD
Classe AcaoBDClasse que representa uma ação de Banco de DadosAtributosquery Uma instrução SQL a ser executada no Banco de Dados.MétodosacoesBDDaRegra(String id_regra)
Este método retorna uma Lista de objetos do tipo AcaoBD vinculados à Regra cujo id é passado como parâmetro (id_regra).
executaQuery(String query)
Método que tem por finalidade executar uma instrução SQL de acordo com a consulta (query) passada como parâmetro.
Fonte: Elaborado pelo autor.
Tabela 7 - Descrição da Classe AcaoEmail
Classe AcaoEmailClasse que representa uma ação de e-mailAtributosdestinatario Destinatário(s) que receberá(ão) o e-mail.assunto Assunto do e-mail.mensagem A mensagem a ser enviada por e-mail.MétodosacoesEmailDaRegra(String id_regra)
Este método retorna uma Lista de objetos do tipo AcaoEmail vinculados à Regra cujo id é passado como parâmetro (id_regra).
enviaEmail(String dest, String assunto, String msg)
Método cujo objetivo é enviar um e-mail para um destinatário (dest), contendo com um assunto (assunto) e uma mensagem (mesg). Estas informações são passadas como parâmetro para a função.
Fonte: Elaborado pelo autor.
Tabela 8 - Descrição da Classe ServerBD
Classe ServerBDEsta classe representa um Servidor de Banco de DadosAtributoshost Endereço do servidor na rede.nome Nome do servidor.usuario O usuário para conectar ao servidor de Banco de Dados.senha A senha para conectar ao servidor de Banco de Dados.tipo Tipo do Banco de dados
66
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Métodos
Fonte: Elaborado pelo autor.
Tabela 9 - Descrição da Classe ServerWS
Classe ServerWSEsta classe representa um Servidor de web serviceAtributosaddress Endereço do web service.nome Nome do servidor.Métodos
Fonte: Elaborado pelo autor.
Tabela 10 - Descrição da Classe Log
Classe LogEsta classe representa um registro de Log de ações executadasAtributosData Data que a ação foi executada.Hora Hora que a ação foi executada.Métodos
Fonte: Elaborado pelo autor.
Tabela 11 - Descrição da Classe Frequencia
Classe FrequenciaEsta classe define uma Frequência para verificação de Regras aptas a serem executadasAtributosdescricao Atributo para auxiliar a identificação da Frequencia na Base de
Dados do Customeasytipo_agendamento Tipo de agendamento. Poderão ser de quatro tipo tipos: 1 - Toda
hora em um minuto determinado, 2 - Todo dia em uma hora determinada, 3 - Toda semana em uma dia determinado e 4 - Todo mês em uma dia determinado.
dia_mes Atributo que permite definir um dia do mês {1...31}dia_semana Atributo que permite definir um dia da semana {1...7}, onde 1 é
domingo e 7 é sábado.hora Atributo que permite definir a hora desta frequência {1...24}minuto Atributo que permite definir o minuto desta frequência. Os
valores devem ser múltiplos de 5 minutos {1,5,10..,50,55}.Métodos
Fonte: Elaborado pelo autor.
67
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Tabela 12 - Descrição da Classe Retorno
Classe RetornoClasse auxiliar para armazenar variáveis e valores retornados por uma consulta.Atributosvariavel Atributo com a finalidade de armazenar o nome do campo de
um registro retornado por uma consulta.valor Atributo responsável por armazenar o valor de um registro
retornado por uma consulta.Métodos
Fonte: Elaborado pelo autor.
3.6 Modelo Relacional
A modelagem do diagrama E.R. (Entidade Relacionamento) foi baseada no modelo de
classes e representa como será modelada a base de dados da ferramenta CustomEasy. O
diagrama demonstra todas as tabelas da base de dados e suas respectivas dependências. A
Figura 37 ilustra o Modelo Relacional do sistema.
68
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 37 - Diagrama E.R. do sistema CustomEasy
Fonte: Elaborado pelo autor.
69
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
As Tabelas enumeradas de 13 até 23 dispõem uma breve descrição das tabelas e dos
campos do Diagrama E.R. do CustomEasy.
Tabela 13 - Descrição da tabela Regras
Tabela RegrasTabela destinada a armazenar as Regras cadastradas no Sistema.Camposid Código único da Regra.nome Nome da Regra.condicao Condição da Regra, um operador.valor Uma valor armazenado que, atingido, pode disparar uma ação.frequencia Frequência de execução da Regra.habilitada Define se a Regra está habilitada ou não.
Fonte: Elaborado pelo autor.
Tabela 14 - Descrição da tabela RegrasBD
Tabela RegrasBDTabela destinada a armazenar as Regras de Banco de Dados cadastradas no Sistema.Camposid Código único da Regra de Banco de Dados.servidor O servidor de Banco de Dados.query Consulta cadastrada que será executada na ação designada.id_Regra Código único da tabela Regras.id_ServersBD Código único da tabela ServersBD.
Fonte: Elaborado pelo autor.
Tabela 15 - Descrição da tabela RegrasWS
Tabela RegrasWSTabela destinada a armazenar as Regras de web service cadastradas no Sistema.Camposid Código único da Regra de web service.nome_variavel Armazenará o nome de um campo baseado no resultado de uma
consulta a um web service.id_Regra Código único da tabela Regras.id_ServersWS Código único da tabela ServersWS.
Fonte: Elaborado pelo autor.
70
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Tabela 16 - Descrição da tabela Acoes
Tabela AcoesTabela destinada a armazenar as Ações do Sistema.Camposid Código único da Ação cadastrado no Banco de Dados.descricao Descricão da Ação.habilitada Indica se a Ação está ou não habilitada.id_Regras Código único da tabela Regras.
Fonte: Elaborado pelo autor.
Tabela 17 - Descrição da tabela AcoesBD
Tabela AcoesBDTabela destinada a armazenar as Açoes de Banco de Dados do SistemaCamposid Código único da Ação de Banco de Dados.query Descricão da Ação.id_Acoes Código único da tabela Ações.id_serverBD Código único da tabela ServersBD.
Fonte: Elaborado pelo autor.
Tabela 18 - Descrição da tabela AcoesWS
Tabela AcoesWSTabela destinada a armazenar as Açoes de web service do SistemaCamposid Código único da Ação de Banco de Dados.query_string Armazenará uma string contendo variáveis que serão
substituídas por valores no momento de rodar o web service.id_Acoes Código único da tabela Ações.id_ServersWS Código único da tabela ServersWS.
Fonte: Elaborado pelo autor.
Tabela 19 - Descrição da tabela AcoesEmail
Tabela AcoesEmailTabela destinada a armazenar as Açoes de e-mail do SistemaCamposid Código único da Ação de e-mail.destinatario Destinatário(s) que receberá(ão) o e-mail.
71
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
assunto Assunto do e-mail.mensagem A mensagem a ser enviada por e-mail.id_Acoes Código único da tabela Ações.
Fonte: Elaborado pelo autor.
Tabela 20 - Descrição da Tabela ServersBD
Tabela ServersBDEsta classe representa um Servidor de Banco de DadosCamposid Código único do Servidor de Banco de Dados.host Endereço do servidor na rede.nome Nome do servidor.usuario O usuário para conectar ao servidor de Banco de Dados.senha A senha para conectar ao servidor de Banco de Dados.tipo Tipo do Banco de dados
Fonte: Elaborado pelo autor.
Tabela 21 - Descrição da Tabela ServersWS
Tabela ServersWSEsta classe representa um Servidor de web serviceCamposid Código único do Servidor de web services.address Endereço do web service.nome Nome do servidor.Métodos
Fonte: Elaborado pelo autor.
Tabela 22 - Descrição da Tabela Logs
Tabela LogsUm registro da tabela de Logs representa uma ação executada com sucesso. Servirá para questões de auditoria e/ou emissão de relatórios.Camposid Código único do registro de Log.data Data que a ação foi executada.hora Hora que a ação foi executada.id_Acoes Código único da tabela Ações.
Fonte: Elaborado pelo autor.
72
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Tabela 23 - Descrição da Tabela Frequencias
Tabela FrequenciasUm registro da tabela Frequencias representa uma frequência para agendar verificações de cada regra habilitada.Camposid Código único da frequência.descricao Descrição da frequência.tipo_agendamento Tipo de agendamento desta frequência. São possíveis quatro
tipos diferentes.dia_mes Dia do mês.dia_semana Dia da semana.hora Hora do dia, no formato 24h.minuto Campo que define o minuto em que a regra será verificada.
Podem ser cadastrado minutos múltiplos de 5. Desta forma, uma regra pode ser verificada a cada 5 minutos.
Fonte: Elaborado pelo autor.
3.7 Verificação de Regras e execução de Ações
Nesta seção será explicado como foi elaborado o procedimento de agendamento
automático e o algoritmo de verificação de Regras e execução das Ações. O programa
principal (classe main) estará “empacotado” em um arquivo .JAR, e este estará configurado
nos parâmetros do Agendador de tarefas do Windows, conforme Figura 38.
Figura 38 - Configuração do programa disparador de Ações
Fonte: Elaborado pelo autor.
73
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Configurado o programa disparador de ações, este deve ser agendando para ocorrer em
um horário pré-definido. Foi decidido que o programa será executado a cada 5 minutos,
diariamente. Segue a Figura 39 apresentando a configuração mencionada.
Figura 39 - Configuração de agendamento
Fonte: Elaborado pelo autor.
A seguir, será explicado resumidamente o algoritmo de verificação de Regras e
execução de ações. A Figura 40 ilustra este algoritmo:
Figura 40 - Algoritmo do programa principal do CustomEasy
Fonte: Elaborado pelo autor.
74
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
3.8 Tecnologias utilizadas
Para apoiar o desenvolvimento do presente trabalho fez-se uso de várias ferramentas,
cujos propósitos são: armazenamento, interface, modelagem e algoritmos. As tecnologias
adotadas (e que serão mais bem detalhadas no decorrer deste capítulo) são: PostgreSQL3
como banco de dados de armazenamento; linguagem de programação Java4; NetBeans, para
escrever o código na estrutura MVC; JavaMail API como framework para envio automático
de e-mails e, como técnica de desenvolvimento, a Programação Orientada a Objetos. Para
construção dos diagramas da proposta, foram utilizadas as seguintes ferramentas: Astah
Community (diagramas UML), Mysql Workbench (diagrama E.R.) e a ferramenta de
modelagem de processos Bizagi (processos BPMN).
Segundo a própria documentação do PostgreSQL, a ferramenta é considerada um
sistema gerenciador de banco de dados, o que nada mais é do que um sistema
computadorizado para manter registros de arquivos, fazendo com que o usuário da informação
manipule-as com facilidade O Sistema de Gerenciamento de Banco de Dados (SGBD)
PostgreSQL faz uso da metodologia objeto-relacional. Um banco de dados objeto-relacional,
em sua estrutura básica, é uma coleção de Tabelas, todas com nomes únicos, que compõem a
base de dados, podendo estar relacionada a uma ou mais tabelas. Conceitos como integridade
referencial de dados garantem que um dado referenciado em uma Tabela esteja presente na
Tabela que está sendo referenciada. Chaves primárias estão presentes e garantem que um
conjunto de informações possa ser representado de maneira consistente, independente da
forma de acesso (BOSCARIOLI, 2006).
Através da linguagem de programação Java será aplicado o paradigma de
programação orientada a objetos, o qual faz uso de classes e objetos criados a partir dos
modelos para representar e processar dados, usando programas de computadores. A
modelagem dos dados e operações sobre os dados em um programa de computador permite o
processamento de forma coesa, rápida, e menos suscetível a erros de referência. Segundo
Wazlawick (2004), utilizando a metodologia orientada a objetos, o desenvolvedor poderá,
desde o início do projeto, produzir um software bem organizado, baseado em uma arquitetura
multicamadas e com possibilidade de incluir novos requisitos e modificar os requisitos
existentes de um modo ordenado, mesmo que o sistema já esteja implementado. Seu objetivo
é resolver problemas, identificando os objetos do mundo real do problema e o seu
3Software e documentação disponíveis em http://www.postgresql.org/4Tecnologias e Bibliotecas disponíveis em http://www.oracle.com/technetwork/java/index.html
75
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
processamento necessário, criando, então, simulação dos mesmos, seus processos e as
comunicações necessárias entre eles.
O ambiente de desenvolvimento escolhido para a implementação do sistema foi o
NetBeans5, pois já é de conhecimento do autor do trabalho.
Com o objetivo de auxiliar a elaboração dos diversos diagramas UML da presente
proposta, foram utilizadas as ferramentas Astah Community6 para criação dos diagramas
UML e MySQL Workbench7 para o modelo ER da base de dados. Foi verificado durante a
etapa de elaboração dos diagramas que o Astah é uma ferramenta de fácil utilização e
entendimento, além de se mostrar muito flexível, tendo em vista que foram elaborados
variados tipos de diagramas nesta ferramenta. O MySQL Workbench também se mostrou
eficaz para seu propósito. O diagrama ER foi modelado nesta ferramenta sem maiores
esforços.
Para desenvolvimento dos diagramas na notação BPMN foi utilizado o software
Bizagi8. Foi constatado que as informações contidas no site oficial da ferramenta condizem
com a constatação do autor desta proposta, pois a ferramenta se mostrou rápida e eficaz na
construção dos variados diagramas BPMN.
3.9 Organização dos arquivos Java dentro do projeto Netbeans
No IDE para desenvolvimento NetBeans foram criados dois projetos separados. Um
projeto Java web foi criado para organizar e separar a parte web da ferramenta (responsável
pelos cadastros) com a utilização do servidor Tomcat. Um outro projeto foi criado (projeto
App java), este sem necessidade de servidor web instalado. Este projeto foi criado
separadamente para tratar toda a parte envolvida no scheduler (escalonador, ou agendador de
tarefas) da ferramenta, juntamente com o programa principal verificador de regras e
disparador de ações.
Na Figura 41, pode ser verificado como o projeto web foi dividido. São quatro
pacotes principais de códigos-fonte:
a) Páginas Web: Neste pacote encontram-se os arquivos .JSP. Estes arquivos são
responsáveis pela exibição das páginas web do CustomEasy;
b) Controle: Localizado dentro do pacote de Códigos-fonte do projeto, este pacote
contém as funções de cadastros (redirecionamento de páginas). Todas as
5Disponível em http://netbeans.org/downloads6Disponível em http://astah.net/editions/community7Disponível em http://www.mysql.com/downloads/workbench8Disponível em http://www.bizagi.com/index.php/en/products/bizagi-bpm-suite/download
76
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
funções deste pacote recebem como parâmetro um ServletRequest e retornam
uma string contendo a página redirecionada após confirmação da request;
c) O pacote Modelo contém as classes Java e manipulação de seus atributos
(funções getters e setters);
d) O pacote Persistência contém as classes responsáveis por funções de
manipulação de instruções SQL (classes DAO).
Figura 41 - Organização do Projeto dentro do IDE Netbeans
Fonte: Elaborado pelo autor.
Já no projeto App Java não houve necessidade de separação de arquivos-fontes, pois o
programa principal main somente instancia as classes necessárias já implementadas no projeto
web.
77
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
4 VALIDAÇÃO DA FERRAMENTA
Durante a etapa de validação da ferramenta foram mapeados processos de quatro
setores administrativos do Centro Universitário UNIVATES. Os setores selecionados para
aplicação da ferramenta foram os seguintes: Financeiro (Contas a Pagar), Patrimônio,
Recursos Humanos (Folha de Pagamento) e Compras. O Sistema de Informações Gerenciais
utilizado peça Instituição é o Microsiga Protheus 11, da empresa TOTVS.
Finalizado o mapeamento, estes processos foram verificados e executados na
ferramenta CustomEasy. Posteriormente foi realizado uma análise dos resultados obtidos com
a participação de cada usuário envolvido diretamente no processo de negócio.
Assim que os resultados foram analisados, um questionário foi distribuído aos usuários
envolvidos a fim de verificar se a solução pode aderir ao processo utilizado pela Instituição.
A seguir, serão explicados todos os processos mapeados nestes quatro setores. Para
melhor entendimento da inserção da ferramenta CustomEasy dentro do processo atual da
Instituição, serão apresentados dois diagramas para cada processo utilizando-se a BPMN. O
primeiro diagrama de cada processo de negócio demonstrará o processo atual sem a utilização
da ferramenta auxiliar, enquanto o segundo diagrama irá representar o processo modificado
após aplicação do CustomEasy.
4.1 Processo de inclusão manual de solicitações de compra
Este processo foi mapeado juntamente com o usuário do setor de Compras responsável
pelas solicitações de compra do SIG Microsiga Protheus 11. Atualmente existem na
Instituição duas formas de incluir solicitações de Compra: automática, via sistema interno e
posterior integração via arquivo .TXT, e manual, feita diretamente pelo usuário no ERP. A
seguir podem ser conferidas as principais características do processo mapeado:
a) Ponto específico do processo: Solicitação de compras incluída manualmente
(sem número de solicitação automática preenchida) que extrapola algum
valor máximo pré-definido. Atualmente não se sabe quando ou quem realiza
esta inclusão indevida;
b) Deficiência: Conferência Manual;
c) Solução: Notificar o usuário responsável pelas inclusões quando acontecer este
tipo de inconsistência.
A seguir, na Figura 42, é exibido o processo atual na notação BPMN.
78
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 42 - Processo de inclusão manual de solicitações de compra, sem o CustomEasy
Fonte: Elaborado pelo autor.
É verificado no diagrama que há um processo manual desnecessário sendo realizado.
A conferência de solicitações de compras manuais não precisaria ser realizada se houvesse
alguma forma do usuário ser notificado automaticamente quando houvesse inconsistência.
Para resolver este tipo de operação manual, o CustomEasy pode realizar esta conferência
automaticamente e enviar um e-mail para o usuário informando as solicitações de compras
lançadas incorretamente. O diagrama da Figura 43 demonstra como o CustomEasy se
encaixaria dentro do processo.
Figura 43 - Processo de inclusão manual de solicitações de compra, com o CustomEasy
Fonte: Elaborado pelo autor.
Na Figura 44 é apresentada a notificação enviada para o usuário. A partir desta
notificação enviada por e-mail, o usuário pode realizar o ajuste diretamente no sistema sem a
79
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
necessidade de emissão de relatório no Microsiga. Para garantir a privacidade do usuário, foi
inserido uma tarja preta no endereço de e-mail do usuário.
Figura 44 - Notificação enviada para o usuário do setor de Compras
Fonte: Elaborado pelo autor.
4.2 Processo de cálculo mensal de depreciação de bens
Durante a etapa de mapeamento deste processo também houve a participação do
usuário envolvido diretamente no processo de negócio. Este usuário é responsável por
conferir os lançamentos realizados pelo setor de Patrimônio durante o mês. Caso estiver tudo
lançado corretamente, irá parametrizar o SIG Microsiga Protheus 11 para rodar o cálculo de
depreciação mensal de bens no último dia útil do mês corrente. O cálculo de depreciação
efetua a atualização do valor de depreciação deste bem, baseado em uma taxa definida no
cadastro. O bem sofre um acréscimo em seu valor depreciado após seguidas depreciações
mensais, e assim que o valor máximo definido em seu cadastro é atingido, este bem não pode
sofrer futuras depreciações. Seguem abaixo as principais características do processo mapeado:
a) Ponto específico do processo: Bem que não pode ser mais depreciado após o
valor de depreciação acumulada atingir o valor máximo de depreciação;
b) Deficiência: Conferência posterior trabalhosa e manual;
c) Solução: Notificar o usuário responsável pelo cálculo de depreciação quando
algum bem atingir o valor máximo de depreciação.
A seguir, na Figura 45, é exibido o processo atual na notação BPMN.
80
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 45 - Processo de cálculo de depreciação, sem o CustomEasy
Fonte: Elaborado pelo autor.
O diagrama da Figura 45 demonstra um processo manual desnecessário sendo
realizado. Conforme Figura, o usuário processa um relatório contábil de conferência de
inconsistências no Microsiga após o cálculo mensal, com o objetivo de conferir os bens que
ultrapassaram o valor máximo de depreciação. Com a utilização do CustomEasy, esta
conferência manual não é mais necessária, visto que uma notificação automática por e-mail
pode ser enviada para o usuário a partir de uma frequência definida pela mesma. O diagrama
da Figura 46 demonstra como o CustomEasy se encaixaria dentro do processo.
81
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 46 - Processo de cálculo de depreciação, com o CustomEasy
Fonte: Elaborado pelo autor.
A Figura 47 apresenta a notificação enviada para o usuário responsável pelo cálculo
mensal de depreciação.
Figura 47 - Notificação enviada para o usuário do setor de Patrimônio
Fonte: Elaborado pelo autor.
82
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
4.3 Processo de cálculo da folha de pagamento
O próximo processo mapeado foi o cálculo da folha de pagamento, realizado
mensalmente pelo setor de Recursos Humanos. Este processo é realizado no último dia útil do
mês corrente. O cálculo da folha de pagamento é realizado diretamente no Microsiga, sem
necessidade de conferência prévia. O ERP calcula os valores das verbas de proventos e
descontos automaticamente, sendo que a conferência dos valores é feita posteriormente.
Um problema detectado juntamente com o usuário responsável pelo cálculo da folha
está relacionado com o lançamento de valores negativos em algumas verbas de impostos.
Segundo o usuário, este problema é causado por uma rotina customizada no ERP, já que estas
verbas não poderiam gerar valores negativos. Sempre que há incidência destas verbas na folha
de um funcionário, o usuário realiza o ajuste dos valores manualmente. Abaixo podem ser
verificadas as principais características do processo mapeado:
a) Ponto específico do processo: Geração de valores negativos para algumas
verbas de impostos no cálculo da folha de pagamento. Existem verbas cujos
valores podem ser negativos, porém isto não pode acontecer para as verbas de
impostos;
b) Deficiência: Conferência posterior desnecessária;
c) Solução: Notificar o usuário responsável pelo cálculo da folha de pagamento
quando forem identificados valores negativos para as verbas de impostos
cadastradas na Regra de Banco de Dados.
A seguir, na Figura 48, é exibido o processo atual sem o CustomEasy.
Figura 48 - Processo de cálculo da folha de pagamento, sem o CustomEasy
Fonte: Elaborado pelo autor.
83
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
O CustomEasy, mesmo que modelado para realizar tal função (neste caso seria uma
Ação de Banco de Dados, realizando update na base), não ajustará os valores lançados, visto
que estes variam de funcionário para funcionário e também dependem de outras verbas,
porém a ferramenta pode auxiliar o usuário avisando-o quando ocorrer a inconsistência para
que esta não precise procurar no Microsiga os funcionários cujas verbas de impostos estão
calculadas incorretamente. O diagrama da Figura 49 demonstra a aplicação do CustomEasy
no processo atual.
Figura 49 - Processo de cálculo da folha de pagamento, com o CustomEasy
A Figura 50 apresentada a notificação enviada para o usuário. A partir desta
notificação enviada por e-mail, o usuário poderá efetuar o ajuste dos valores das verbas
negativas diretamente no Microsiga. Desta forma, a etapa de pesquisa pelos registros com
divergência através de relatórios não precisa ser realizada.
84
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Figura 50 - Notificação enviada para o usuário do setor de Recursos Humanos
Fonte: Elaborado pelo autor.
4.4 Processo de seleção de títulos a pagar
O quarto e último processo mapeado foi o processo de seleção de títulos a pagar. Este
processo de negócio é responsável por filtrar os títulos a serem pagos na sexta-feira da semana
corrente. Durante a etapa de mapeamento do processo foi constatado que em todas as quintas-
feiras a usuária responsável por selecionar os títulos para pagamento realiza uma varredura no
Microsiga com o objetivo de selecionar todos os títulos cujo vencimento são para a sexta-feira
daquela semana. Para tal, toda quinta-feira de manhã, a usuária tem a tarefa de verificar no
ERP se os títulos cuja informação de tipo de pagamento são igual a “B” (boleto) possuem o
campo “código de barras” em branco. Isto está errado, pois todos os boletos devem possuir a
informação do código de barra. Este problema é originado porque o leitor de código de barras
pode não ler o código de barras do boleto, e/ou este não foi digitado manualmente no
Microsiga (a usuária esqueceu ou não percebeu).
A referida verificação dos boletos com código de barras em branco é realizada
manualmente através de filtros dentro do módulo Financeiro do Microsiga.
Para eliminar esta tarefa manual, o CustomEasy pode enviar um e-mail à usuária, nas
quintas-feiras pela manhã, (em um horário estipulado) com uma relação de todos os títulos de
tipo de pagamento igual a “B” com código de barras igual a “branco”. Segue abaixo uma
síntese do processo mapeado:
a) Ponto específico do processo: Seleção de títulos para pagamento na sexta-feira
da semana corrente;
85
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
b) Deficiência: Processo manual desnecessário;
c) Solução: Notificar ao usuário responsável pela seleção de títulos para
pagamento uma relação de todos os títulos com inconsistência.
A Figura 51 demonstra o processo atual realizado sem a atuação do CustomEasy, na
BPMN.
Figura 51 - Processo de seleção de títulos para pagamento, sem o CustomEasy
Fonte: Elaborado pelo autor.
A partir da aplicação do CustomEasy neste processo, percebe-se na Figura 52 que três
eventos deixam de existir pelo fato de serem executados automaticamente.
Figura 52 - Processo de seleção de títulos para pagamento, com o CustomEasy
Fonte: Elaborado pelo autor.
86
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
A notificação enviada para o usuário é apresentada na Figura 53. Após recebimento
deste e-mail na quinta-feira de manhã, o usuário não precisará mais pesquisar no Microsiga
quais boletos estão com códigos de barra em branco, bastando somente ajustar os títulos
relacionados no e-mail.
Figura 53 - Notificação enviada para o usuário do setor Financeiro
Fonte: Elaborado pelo autor.
4.5 Avaliação dos resultados
De acordo com a metodologia proposta, este trabalho foi avaliado através do modelo
qualitativo por quatro avaliadores. O questionário apresentado no Apêndice A do presente
trabalho foi utilizado para conduzir a avaliação.
O referido questionário foi divido em duas partes, sendo a primeira parte composta por
perguntas direcionadas às melhorias propostas pela ferramenta auxiliar. A segunda parte é
focada na ferramenta, a fim de verificar questões específicas do software proposto. Os quatro
avaliadores foram selecionados de acordo com sua experiência na área de atuação, sendo,
entre eles: um profissional (Analista de Recursos Humanos) do Departamento Pessoal da
UNIVATES, responsável pela elaboração da folha de pagamento, cálculo de férias, rescisão,
pagamento de impostos e 13° salário, com mais de 6 anos de experiência nesta área, graduado
no curso de Administração de Empresas; um profissional (Auxiliar Administrativo) do setor
de Compras, atuando desde 2007 como Comprador de Suprimentos, acadêmico do Curso de
Administração de Empresas; um funcionário do setor de Patrimônio (Analista de Patrimônio),
colaborador há 9 anos na UNIVATES e com experiência em todas as tarefas realizadas neste
setor, e um profissional do setor Financeiro (Analista de Contas a Pagar), com 6 anos de
experiência nesta função dentro da área de Contas a Pagar e 12 anos de trabalhos prestados à
UNIVATES.
87
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Após recebimento do questionário preenchido e análise das repostas, verificou-se que
todos os avaliadores consideraram a proposta de melhoria estabelecida pelo CustomEasy
aderentes ao processo atual realizado pelo setor visitado. Constataram que o sistema auxiliar
pode possibilitar a identificação de lançamentos manuais realizados incorretamente em
processos de negócio de sua responsabilidade, de forma automática, e que desta forma o erro
poderia ser identificado antes de dar o devido andamento ao restante do processo.
Os avaliadores consideraram o processo de melhoria estabelecido pelo CustomEasy
claro e intuitivo (dois avaliadores consideraram a notificação enviada simples e objetiva), e os
outros dois enfatizaram o recebimento da notificação como uma forma fácil de identificar o
erro. Todos os avaliadores apoiaram consideravelmente no que se refere ao sistema auxiliar
servir de apoio ao sistema de gestão utilizado pela Instituição.
Quanto ao software experimental proposto, todos concordaram que este poderia ser
utilizado em um ambiente real, pois segundo explicação de dois avaliadores, este contempla
uma função indisponível no sistema de gestão existente. Um avaliador ratificou esta
informação explicando que a ferramenta auxiliar poderá facilitar o trabalho de conferências
diárias ou mensais. Outro avaliador justificou a resposta afirmando que o controle realizado
manualmente pode gerar erros, e que com a utilização do software ele poderia receber a
informação com exatidão e em menos tempo.
Quanto à melhorias na ferramenta, sugeriram variadas funcionalidades que poderiam
ser desenvolvidas no sistemas proposto. Consideraram a possibilidade de melhoria através do
envio de uma planilha anexada ao e-mail (ou um arquivo CSV) para facilitar a conferência e
utilizar fórmulas para fazer comparações. Além disso, a usuária do Contas a Pagar achou
interessante o envio do e-mail não somente para os usuários internos do sistema, mas também
para usuários externos, como por exemplo enviar um e-mail para um determinado fornecedor
informando que um determinado pagamento foi efetuado. Um dos usuários reportou que na
customização apresentada não teria nada a acrescentar, pois o CustomEasy está notificando-a
com a informação que precisa. Outro usuário não se manifestou sobre melhorias.
Por fim, concordaram que a ferramenta auxiliar, embora experimental, atende
totalmente quanto à necessidade de gerência de erros e processos manuais, destacando que o
CustomEasy poderia evitar desperdício de tempo em conferências manuais, além de
identificar o erro em tempo hábil.
88
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
5 CONSIDERAÇÕES FINAIS
Todos os objetivos estabelecidos na metodologia do presente trabalho foram
cumpridos. Para tal, o estudo realizado a partir do referencial teórico do presente trabalho
permitiu maior compreensão sobre processos de negócio, facilitando a construção da presente
proposta.
A pesquisa bibliográfica também evidenciou as necessidades de melhoria em
processos de negócio na Instituição onde foi realizado o estudo de caso, apesar desta já
utilizar um sistema de informações gerenciais. Percebeu-se, ainda, que o sistema de
informações gerenciais mencionado poderia passar por algum grau de customização sem
descaracterização de suas funcionalidades originais, agregando novas funcionalidades
inexistentes ou melhorando as existentes.
Após a pesquisa bibliográfica concluída, foi realizado um levantamento de requisitos
com os usuários, a fim de detectar suas reais necessidades quanto à melhoria de processos. O
levantamento de requisitos permitiu confirmar as demandas já identificadas pela literatura e
sugeriu outras específicas. Então, verificou-se a necessidade de uma ferramenta auxiliar capaz
de customizar processos de negócio e notificar usuários a partir de regras definidas por estes.
A partir do levantamento de requisitos, foi realizada a modelagem, projeto de arquitetura e o
desenvolvimento da ferramenta, sempre observando boas práticas de engenharia de software.
Após conclusão do desenvolvimento da ferramenta auxiliar CustomEasy, foi possível
submetê-la para verificação junto aos usuários participantes das rotinas administrativas diárias
mapeadas, através de avaliação qualitativa, conforme metodologia estabelecida. Os resultados
desta avaliação foram analisados a fim de verificar se a solução proposta pode cumprir os
objetivos descritos no presente documento.
Foi possível verificar por meio da avaliação que as notificações expostas neste
trabalho apresentaram confirmações de que uma futura implantação desta em ambiente de
produção poderia apresentar melhorias significativas quanto a automatização de processos de
negócio na Instituição.
Como continuidade deste trabalho, serão desenvolvidas melhorias contínuas no
software proposto, através da adição de novas funcionalidades, possibilidade de criação de
regras mais complexas e ações de diferentes tipos. Além disso, buscar-se-á a publicação em
meios científicos, no intuito de aprimorar o diálogo entre os interessados e como também a
exposição para comunidade acadêmica dos resultados obtidos.
89
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
REFERÊNCIAS
ADELMAN, C. et al. Re-thinking case study: notes from second Cambridge Conference. Cambridge Journal of Education, 6, 3, 1976.
BEAL, A. Gestão estratégica da informação: como transformar a informação e a tecnologia da informação em fatores de crescimento e de alto desempenho nas organizações. São Paulo: Atlas, 2004-2008.
BEUREN, I. M. Gerenciamento da informação: um recurso estratégico no processo de gestão empresarial. São Paulo: Atlas, 2000.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Elsevier, 2007.
BOSCARIOLI, C. Uma reflexão sobre Banco de Dados Orientados a Objetos. 2006. 12p. Disponível em: <http://conged.deinfo.uepg.br/artigo4.pdf>. Acesso em: 24 out. 2012.
CHAN, Y. E. et al. Business strategic orientation, information systems strategic orientation, and strategic alignment. Information Systems Research, v.8, n.2, p-125-150, June 1997.
COLÂNGELO, L. Implantação de sistemas ERP (Enterprise Resources Planning). São Paulo: Atlas, 2001;
DAVENPORT, T. H.; DICKSON, T.; BELLINI, C. G. P. Dominando a gestão da informação. Porto Alegre: Bookman, 2004.
DE SORDI, J. O. Gestão por processos: uma abordagem da moderna administração. São Paulo: Saraiva, 2009.
DITTRICH, Y.; VAUCOULEUR, S.; GIFF, S; ERP Customization as Software Engineering: Knowledge Sharing And Cooperation, pag. 41-47, 2009, IEEE SOFTWARE
FREITAS, H.; BECKER, J. L.; KLADIS, C. M. Informação e decisão: sistemas de apoio e seu impacto. Porto Alegre: Ortiz, 1997.
GRAHAM, S.; DAVIS, D.; SIMEONOV, S. Building web services with java: making sense of XML, SOAP, WSDL, and UDDI. Indianapolis: Developer s, 2004.
GUEDES, G. T. A. UML 2: uma abordagem prática. São Paulo: Novatec, 2009.
90
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
MICHAELIS. http://michaelis.uol.com.br . Acessado em 04 de novembro de 2013.
OLIVEIRA, D. P. R. de. Sistemas de informações gerenciais: estratégicas, táticas, operacionais. São Paulo: Atlas, 2004.
O'BRIEN, L.; MERSON, P.; BASS, L. Quality Attributes for Service-Oriented Architectures. In: International Workshop on Systems Development in SOA Environments, IEEE Computer Society Washington, DC, USA, 7 p., 2007. Disponível em: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4273291. Acesso em: 13 out. 2012.
PADILHA, T. C. C.; MARINS, F. A. S. ERP systems: characteristics, implementation cost, tendencies. Produção, São Paulo, v. 15, n. 1, p. 102-113 p., 2005.
PAIM, R. Engenharia de Processos: análise do referencial teórico-conceitual, instrumentos, aplicações e casos. Rio de Janeiro: Universidade Federal do Rio de Janeiro, 2002.
PAIM, R.; CARDOSO, V.; CAULLIRAUX, H. Gestão de processos: pensar, agir e aprender. São Paulo: Bookman, 2009.
RABISER, R. et al. Three-level Customization of Software Products Using a Product Line Approach. In: 42nd Hawaii International Conference On System Sciences, Hawaii, 2009, 10p.
REZENDE, D. A.; ABREU, A. F. de. Tecnologia da informação aplicada a sistemas de informação empresariais: o papel estratégico da informação e dos sistemas de informação nas empresas. São Paulo: Atlas, 2003.
ROTHENBERGER, M. A.; SRITE, M. An Investigation of Customization in ERP System Implementations. IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 56, NO. 4, 2009, p 663-767
SANTOS, A. R. Metodologia científica: a construção do conhecimento 5. ed. Rio de Janeiro: DP&A, 2002.
SANTOS, R. Notação BPMN v.1.2, http://www.slideshare.net/Ridlo/notao-bpmn-v-12-3754516 , 2010. Acessado em 30 de outubro de 2013.
SOUZA, C. A. de; SACCOL, A. Z. Sistemas ERP no Brasil (enterprise resource planning): teoria e casos. São Paulo: Atlas, 2003.
STAREC, C.; GOMES, E. Gestão estratégica da informação e inteligência competitiva. São Paulo: Saraiva, 2006.
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004.
91
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
APÊNDICE A - Questionário de avaliação
Questionário sobre o processo de melhoria estabelecido pela ferramenta auxiliar
CustomEasy.
Objetivo:
Este questionário tem por finalidade a avaliação do processo de melhoria em variadas
rotinas diárias ou mensais, manuais ou trabalhosas em processos de negócio do Centro
Universitário UNIVATES.
Resumo:
A ferramenta proposta neste trabalho visa automatizar a customização de sistemas de
informações gerenciais por meio da definição de regras e a criação de gatilhos de ações,
permitindo adicionar à aplicação existente um novo comportamento, sem, no entanto,
modificar o comportamento original desta. Com isso, poderá ser minimizada a necessidade de
customização de software, além de aumentar sua aderência aos processos organizacionais.
Etapas para avaliação:
1. Apresentação presencial da ferramenta CustomEasy, uma breve descrição de sua
mecânica de funcionamento.
2. Explicação referente dados notificados ao usuário (informações verificadas e
notificadas na ferramenta).
3. Preenchimento do questionário de avaliação abaixo com as respostas do avaliador
conforme sua experiência de utilização
4. Envio do questionário respondido para o aluno por e-mail ou entrega presencia
92
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
Perfil do avaliador
Nome:
Área de Atuação:
Experiência ¹:
¹ Descrição das experiências e qualificações do avaliador, apresentando a sua capacitação para essa avaliação.
1) Quanto ao processo de melhoria estabelecido:
a) Você considera a proposta deste processo de melhoria estabelecida pelo CustomEasy aderente para o atual processo realizado pelo setor?
Sim ( ) Não ( ) Por quê? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
b) Que tipo de melhoria a ferramenta auxiliar poderia agregar no seu dia-a-dia? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
c) Você considera que este processo de melhoria estabelecido pelo CustomEasy é claro e intuitivo? Sim ( ) Não ( ) Por quê? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
d) O que você considera que poderia ser melhorado ou acrescentado ao CustomEasy? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
e) O quanto você considera que um sistema auxiliar poderia apoiar o sistema de gestão utilizado pela Instituição?( ) Não apoia, atrapalham( ) Não apoia( ) Indiferente ( ) Apoia parcialmente ( ) Apoia consideravelmente
93
BD
U –
Bib
liote
ca D
igita
l da
UN
IVAT
ES
(htt
p://w
ww
.uni
vate
s.br/
bdu)
2) Quanto ao software proposto para esse fim:
a) Você considera que o software poderia ser utilizado em um ambiente real? Sim ( ) Não ( ) Por quê? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________b) Você considera que o software apresenta informações simples e eficientes? Sim ( ) Não ( ) Por quê? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
c) Você considera que os termos utilizados no software são fáceis de compreender? Vocabulário adequado ao público alvo? Sim ( ) Não ( ) Por quê? __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________d) O quanto o software pode atender quanto a necessidade de gerência de erros e processos manuais? ( ) Não atende totalmente ( ) Não atende parcialmente ( ) Indiferente ( ) Atende parcialmente ( ) Atende totalmente
________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
94