UM SISTEMA PARA AUTOMATIZAR A CUSTOMIZAÇÃO DE PROCESSOS DE NEGÓCIO EM SISTEMAS DE INFORMAÇÕES GERENCIAIS

Transcrição

1 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.

2 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.

3 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.

4 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.

5 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.

6 LISTA DE FIGURAS FIGURA 1 - O ALINHAMENTO DE TI SEGUNDO MODELO DE CHAN...13 FIGURA 2 - FLUXO BÁSICO DE UM PROCESSO DE NEGÓCIO...14 FIGURA 3 - TRATAMENTO INTEGRADO DE INFORMAÇÕES...21 FIGURA 4 - INTERAÇÃO DA INFORMAÇÃO NO PROCESSO DECISÓRIO...22 FIGURA 5 - A INFORMAÇÃO COMO MATÉRIA-PRIMA PARA A FORMULAÇÃO DA ESTRATÉGIA...24 FIGURA 6 - EVOLUÇÃO DAS APLICAÇÕES EMPRESARIAIS...28 FIGURA 7 - ÁREAS DE APLICAÇÃO DE UM SISTEMA ERP...30 FIGURA 8 - FUNCIONALIDADES DE UM SISTEMA ERP...31 FIGURA 9 - EXEMPLO DE ESTRUTURA ORGANIZACIONAL (VERTICAL E HORIZONTAL)...33 FIGURA 10 - VISÃO DEPARTAMENTAL E VISÃO DE PROCESSOS...33 FIGURA 11 - EVENTOS, OBJETOS DE FLUXO DA BPMN...35 FIGURA 12 - ATIVIDADES, OBJETOS DE FLUXO DA BPMN...35 FIGURA 13 - GATEWAYS, OBJETOS DE FLUXO DA BPMN...35 FIGURA 14 - FLUXO DE SEQUÊNCIA, OBJETO DE FLUXO DA BPMN...36 FIGURA 15 - NÍVEIS DE CUSTOMIZAÇÃO DE PRODUTO...37 FIGURA 16 - PARADIGMA PROCURA-CONSOLIDA-EXECUTA...41 FIGURA 17 - EXEMPLO DE UM DIAGRAMA DE CASO DE USO...44 FIGURA 18 - EXEMPLO DE ESTRUTURA DE CLASSE EM UML...45 FIGURA 19 - EXEMPLO DE DIAGRAMA DE COMPONENTES...45 FIGURA 20 - EXEMPLO DE DIAGRAMA DE ATIVIDADES...46 FIGURA 21 - ARQUITETURA DO CUSTOMEASY...49 FIGURA 22 - DIAGRAMA DE CASOS DE USO...50 FIGURA 23 - MENU PRINCIPAL DO SISTEMA...51 FIGURA 24 - TELA DE CADASTRO DE SERVIDORES DE BANCO DE DADOS...52 FIGURA 25 - TELA DE CADASTRO DE SERVIDORES DE WEB SERVICES...53 FIGURA 26 - TELA DE CADASTRO DE REGRAS...54 FIGURA 27 - TELA DE CADASTRO DE REGRA DE BANCO DE DADOS...55 FIGURA 28 - TELA DE CADASTRO DE REGRA DE WEB SERVICE...56 FIGURA 29 - TELA DE CADASTRO DE UMA AÇÃO...56 FIGURA 30 - TELA DE CADASTRO DE UMA AÇÃO DE BANCO DE DADOS...57

7 FIGURA 31 - TELA DE CADASTRO DE UMA AÇÃO DE WEB SERVICE...58 FIGURA 32 - TELA DE CADASTRO DE UMA AÇÃO DE FIGURA 33 - TELA DE CADASTRO DE FREQUÊNCIAS...60 FIGURA 34 - EXEMPLO DE NOTIFICAÇÃO ENVIADA PELO CUSTOMEASY...61 FIGURA 35 - DIAGRAMA DE ATIVIDADES DO SISTEMA CUSTOMEASY...62 FIGURA 36 - DIAGRAMA DE CLASSES...63 FIGURA 37 - DIAGRAMA E.R. DO SISTEMA CUSTOMEASY...69 FIGURA 38 - CONFIGURAÇÃO DO PROGRAMA DISPARADOR DE AÇÕES...73 FIGURA 39 - CONFIGURAÇÃO DE AGENDAMENTO...74 FIGURA 40 - ALGORITMO DO PROGRAMA PRINCIPAL DO CUSTOMEASY...74 FIGURA 41 - ORGANIZAÇÃO DO PROJETO DENTRO DO IDE NETBEANS...77 FIGURA 42 - PROCESSO DE INCLUSÃO MANUAL DE SOLICITAÇÕES DE COMPRA, SEM O CUSTOMEASY...79 FIGURA 43 - PROCESSO DE INCLUSÃO MANUAL DE SOLICITAÇÕES DE COMPRA, COM O CUSTOMEASY...79 FIGURA 44 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR DE COMPRAS...80 FIGURA 45 - PROCESSO DE CÁLCULO DE DEPRECIAÇÃO, SEM O CUSTOMEASY81 FIGURA 46 - PROCESSO DE CÁLCULO DE DEPRECIAÇÃO, COM O CUSTOMEASY...82 FIGURA 47 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR DE PATRIMÔNIO...82 FIGURA 48 - PROCESSO DE CÁLCULO DA FOLHA DE PAGAMENTO, SEM O CUSTOMEASY...83 FIGURA 49 - PROCESSO DE CÁLCULO DA FOLHA DE PAGAMENTO, COM O CUSTOMEASY...84 FIGURA 50 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR DE RECURSOS HUMANOS...85 FIGURA 51 - PROCESSO DE SELEÇÃO DE TÍTULOS PARA PAGAMENTO, SEM O CUSTOMEASY...86 FIGURA 52 - PROCESSO DE SELEÇÃO DE TÍTULOS PARA PAGAMENTO, COM O CUSTOMEASY...86 FIGURA 53 - NOTIFICAÇÃO ENVIADA PARA O USUÁRIO DO SETOR FINANCEIRO...87

8 LISTA DE TABELAS TABELA 1 - DESCRIÇÃO DA CLASSE REGRA...64 TABELA 2 - DESCRIÇÃO DA CLASSE REGRABD...64 TABELA 3 - DESCRIÇÃO DA CLASSE REGRAWS...65 TABELA 4 - DESCRIÇÃO DA CLASSE ACAO...65 TABELA 5 - DESCRIÇÃO DA CLASSE ACAOWS...65 TABELA 6 - DESCRIÇÃO DA CLASSE ACAOBD...66 TABELA 7 - DESCRIÇÃO DA CLASSE ACAO TABELA 8 - DESCRIÇÃO DA CLASSE SERVERBD...66 TABELA 9 - DESCRIÇÃO DA CLASSE SERVERWS...67 TABELA 10 - DESCRIÇÃO DA CLASSE LOG...67 TABELA 11 - DESCRIÇÃO DA CLASSE FREQUENCIA...67 TABELA 12 - DESCRIÇÃO DA CLASSE RETORNO...68 TABELA 13 - DESCRIÇÃO DA TABELA REGRAS...70 TABELA 14 - DESCRIÇÃO DA TABELA REGRASBD...70 TABELA 15 - DESCRIÇÃO DA TABELA REGRASWS...70 TABELA 16 - DESCRIÇÃO DA TABELA ACOES...71 TABELA 17 - DESCRIÇÃO DA TABELA ACOESBD...71 TABELA 18 - DESCRIÇÃO DA TABELA ACOESWS...71 TABELA 19 - DESCRIÇÃO DA TABELA ACOES TABELA 20 - DESCRIÇÃO DA TABELA SERVERSBD...72 TABELA 21 - DESCRIÇÃO DA TABELA SERVERSWS...72 TABELA 22 - DESCRIÇÃO DA TABELA LOGS...72 TABELA 23 - DESCRIÇÃO DA TABELA FREQUENCIAS...73

9 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

10 SUMÁRIO 1 INTRODUÇÃO Motivação Objetivos Metodologia Roteiro do restante do trabalho REFERENCIAL TEÓRICO Sistemas de Informações Gerenciais Importância dos sistemas de informações gerenciais para as empresas Gestão Estratégica da Informação Estratégia e Informação Estratégia e Competitividade: algumas abordagens de estratégia O alinhamento com a TI Enterprise Resource Planning Evolução dos Sistemas Integrados de Gestão Empresarial (ERP) Definição de Sistema ERP Arquitetura e Principais Funcionalidades de um ERP Gestão por processos Mapeamento de processos BPMN - Business Process Modeling Notation Evento Atividade Gateways Fluxo de Sequência Gaps Customização Desafios Testes Arquiteturas Orientadas a Serviço e Web Services Web Services Arquiteturas Orientadas a Serviço O protocolo SOAP XML Extensible Markup Language UML - Unified Modeling Language Diagrama de casos de uso Diagrama de classes...44

11 Diagrama de Componentes Diagrama de Atividades TRABALHO PROPOSTO Levantamento de requisitos do sistema Arquitetura do CustomEasy Casos de Uso Cadastrar Servidores Cadastrar Regras Cadastrar Ações Fornecer Informações Receber Notificações Diagrama de Atividades Modelo de Classes Modelo Relacional Verificação de Regras e execução de Ações Tecnologias utilizadas Organização dos arquivos Java dentro do projeto Netbeans VALIDAÇÃO DA FERRAMENTA Processo de inclusão manual de solicitações de compra Processo de cálculo mensal de depreciação de bens Processo de cálculo da folha de pagamento Processo de seleção de títulos a pagar Avaliação dos resultados CONSIDERAÇÕES FINAIS...89 REFERÊNCIAS...90 APÊNDICE...92

12 12 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).

13 13 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

14 14 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 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

15 15 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, integrarse à 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

16 16 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

17 17 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

18 18 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.

19 19 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.

20 20 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)

21 21 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 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.

22 22 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.

23 23 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 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 destacase 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,

24 24 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.

25 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) 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.

26 26 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 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.

27 27 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) 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 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á

28 28 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).

29 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.

30 30 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) 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

31 31 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.

32 32 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.

33 33 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.

34 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, conseguese 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.

35 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 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 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

36 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 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

37 37 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.

38 38 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 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 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

39 39 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 Web Services Os web services (WS) têm ganho respaldo desde que o termo foi introduzido, no ano 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.

40 40 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 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.

41 41 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 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).

42 42 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 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.

43 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 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.

44 44 Figura 17 - Exemplo de um Diagrama de Caso de Uso Fonte: Bezerra (2007) 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.

45 45 Figura 18 - Exemplo de estrutura de classe em UML 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).