Acessibilidade / Reportar erro

Stein: proposta de um sistema ERP para construção civil

Stein: proposal for an ERP system for the construction industry

Resumo

Um Enterprise Resource Planing (ERP) é um sistema de gestão empresarial que permite integrar os fluxos de informação de uma empresa. A implantação de sistemas ERP na construção civil é altamente suscetível a falhas, devido aos requisitos e à complexidade da área. Com o propósito de desenvolver um sistema ERP efetivo, é necessário ter uma análise de requisitos prévia, além de manter o contato com os interessados e demais envolvidos até a entrega do produto. Contudo, diversas escolhas técnicas influenciam na qualidade final do produto, e não foram identificadas na literatura propostas técnicas que auxiliem nessas escolhas. Dessa forma, o objetivo do presente trabalho é propor uma arquitetura para a implementação do sistema, no formato de um modelo de diagrama de blocos, para auxiliar na construção de um ERP, definindo os principais módulos de softwareque esse sistema deve possuir. O modelo proposto é baseado na arquitetura de microsserviços. Foram levantados e elencados os módulos do sistema e seu fluxo de comunicação, de modo a evitar problemas técnicos encontrados durante o ciclo de vida do software. Também foram sugeridas tecnologias que podem ser utilizadas para a construção do ERP, tais como API REST e banco de dados.

Palavras-chave:
Planejamento de recursos da empresa; Diagrama de blocos; Construção civil; Processo de implementação

Abstract

An Enterprise Resource Planning (ERP) is a business management system that allows the integration of a company's information flows. The implementation of ERP systems in the construction industry is highly susceptible to failure, due to the requirements and complexity of the area. With the purpose of developing an effective ERP system, it is necessary to have a prior requirements analysis, in addition to maintaining contact with stakeholders and others involved until the product is delivered. However, several technical choices influence the final quality of the product and no technical proposals that can help in these choices have been identified in the literature. Thus, the objective of this study is to propose an architecture for the system’s implementation, in the format of a block diagram model to help in the construction of an ERP, defining the main software modules that an ERP system must have. The proposed model is based on microservices architecture. The system’s modules and their communication flow were surveyed and listed in order to avoid technical problems encountered during the software life cycle. Technologies that can be used to build the ERP, such as REST API and Database, are also suggested.

Keywords:
Enterprise resource planning; Block diagram; Civil construction; Implementation process

Introdução

Um Enterprise Resource Planning (ERP) é um softwareque permite a integração completa do fluxo de informações de todas as áreas funcionais de uma empresa a partir de um banco de dados acessado via interface gráfica unificada, ou seja, uma tela (ABU-SHANAB; ABU-SHEHAB; KHAIRALLAH, 2015ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015.). O compartilhamento e a integração dos processos de negócio promovem um alto nível de eficiência e gerenciamento de contratos (HADIDI; ASSAF, 2017HADIDI, L. A.; ASSAF, S. A. A systematic approach for ERP implementation in the construction industry. Journal of Civil Engineering and Management, v. 23, n. 5, p. 594-603, oct. 2017.).

O uso de ERP para integrar os processos de uma empresa traz diversos benefícios, entre os quais possibilidade de eliminar a duplicação de esforço e dados; melhoria dos processos; efetividade no tratamento com fornecedores; aumento da produtividade; aumento da satisfação do cliente; facilidade na comunicação corporativa; auxílio na inteligência do negócio; e ajuda aos gerentes no processo de tomada de decisões (ABU-SHANAB; ABU-SHEHAB; KHAIRALLAH, 2015ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015.; DENIC et al., 2016DENIC, N. M. et al. Key factors for successful implementation of ERP systems. TehnickiVjesnik - Technical Gazette, v. 23, n. 5, oct. 2016. ).

Em contrapartida, as principais desvantagens dessa categoria de softwareestão ligadas a seu desenvolvimento e implementação. Entre elas se destacam, de acordo com Denic et al. (2016)DENIC, N. M. et al. Key factors for successful implementation of ERP systems. TehnickiVjesnik - Technical Gazette, v. 23, n. 5, oct. 2016. , o tempo e o custo elevados para colocar o sistema ERP em condições de funcionamento. Além dessas desvantagens, os problemas de compatibilidade com outros sistemas existentes e risco substancial se houver apenas um vendedor ou uma equipe técnica pouco qualificada afetam negativamente na aceitação de um ERP.

Especificamente na área da construção civil, esses softwaressão vistos como um investimento de alto custo, em decorrência de necessidades de mudanças culturais dos processos, investimentos em treinamentos e atualizações da infraestrutura de Tecnologia da Informação (TI). Isso é agravado nessa área, principalmente por conta da complexidade dos negócios, do ambiente, dos aspectos particulares de cada projeto/cliente, do tempo, do custo e da montagem da infraestrutura para o sistema operar. Tudo isso leva a uma taxa de fracasso muito grande na fase de implantação desses sistemas (HADIDI; ASSAF, 2017HADIDI, L. A.; ASSAF, S. A. A systematic approach for ERP implementation in the construction industry. Journal of Civil Engineering and Management, v. 23, n. 5, p. 594-603, oct. 2017.). Além disso, a implantação total de um sistema ERP é mais importante que a implantação parcial dele, pois empresas que implantam o sistema ERP parcialmente têm queda de produtividade, enquanto empresas que implantam o sistema ERP completamente têm aumentada sua produtividade (CASTRO et al., 2020CASTRO, J. P. da C. et al. Avaliação da aceitação do ERP a partir do Modelo UTAUT: uma visão qualitativa em um estudo de caso múltiplo. Evaluation of ERP Acceptance from the UTAUT Model: a qualitative view in a multiple case study. Management in Perspective, v. 1, n. 2, p. 208-232, jul. 2020.).

A construção de um sistema ERP para qualquer área é altamente suscetível a falhas, pois é um softwaredifícil de ser implementado e mantido (ABU-SHANAB; ABU-SHEHAB; KHAIRALLAH, 2015ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015.). Esse fato é comprovado pela alta taxa de fracasso dos projetos: cerca de 90% dos projetos terminam acima do orçamento, 40% são parcialmente implantados e 20% falham completamente (SOUSA; BARROS NETO, 2020SOUSA, A. M. H.; BARROS NETO, J. P. Is it possible to implement ERP in the production function of civil construction? Gestão & Produção, v. 27, n. 3, 2020. ; HADIDI; ASSAF, 2017HADIDI, L. A.; ASSAF, S. A. A systematic approach for ERP implementation in the construction industry. Journal of Civil Engineering and Management, v. 23, n. 5, p. 594-603, oct. 2017.; CHAKRAVORTY; DULANEY; FRANZA, 2016CHAKRAVORTY, S. S.; DULANEY, R. E.; FRANZA, R. M. ERP implementation failures: a case study and analysis. International Journal of Business Information Systems, v. 21, n. 4, p. 462-476, 2016.).

Os principais fatores para o sucesso do produto são o planejamento de todo o ciclo de vida do ERP e a escolha correta da arquitetura do sistema (SOUSA; BARROS NETO, 2020SOUSA, A. M. H.; BARROS NETO, J. P. Is it possible to implement ERP in the production function of civil construction? Gestão & Produção, v. 27, n. 3, 2020. ; ABU-SHANAB; ABU-SHEHAB; KHAIRALLAH, 2015ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015.). O planejamento começa a partir dos requisitos, que devem ser claros e concisos, além de refletir corretamente o que se espera do sistema. A arquitetura do softwaredirá como os módulos do sistema estão interligados e define a comunicação entre eles. Além disso, ela minimiza os recursos humanos necessários para construir e manter determinado sistema (MARTIN, 2019MARTIN, R. C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio de Janeiro: Alta, 2019.).

Outro aspecto importante para o sucesso de um sistema é o modelo de implementação que será seguido. Sousa e Barros Neto (2020)SOUSA, A. M. H.; BARROS NETO, J. P. Is it possible to implement ERP in the production function of civil construction? Gestão & Produção, v. 27, n. 3, 2020. apresentam três diferentes modelos para a implementação de um sistema ERP, os quais contemplam o ciclo de vida do software, partindo da definição dos requisitos até o uso do sistema.

Denic et al. (2016)DENIC, N. M. et al. Key factors for successful implementation of ERP systems. TehnickiVjesnik - Technical Gazette, v. 23, n. 5, oct. 2016. destacam todo o ciclo de vida do software, sendo uma opção de modelo para a construção dele. Dado que esses modelos são restritos ao ciclo de vida do software, não abordam uma proposta para a construção da arquitetura do sistema e a comunicação entre os componentes de software.

Diante da lacuna identificada na literatura, o modelo proposto busca auxiliar de forma técnica a construção de um sistema ERP. Desse modo, a presente questão é explorada: como construir um modelo para desenvolver um sistema ERP na área da construção civil que promova o sucesso do projeto?

Acredita-se que, com a modelagem correta do sistema, as demais etapas podem ser realizadas com maior assertividade, aumentando, assim, a aceitação e as chances de sucesso dos sistemas ERP propostos na construção civil, o que impacta diretamente na eficiência e nos lucros da empresa, principalmente empresas de pequeno porte. Além disso, conforme apontado por Castro et al. (2020)CASTRO, J. P. da C. et al. Avaliação da aceitação do ERP a partir do Modelo UTAUT: uma visão qualitativa em um estudo de caso múltiplo. Evaluation of ERP Acceptance from the UTAUT Model: a qualitative view in a multiple case study. Management in Perspective, v. 1, n. 2, p. 208-232, jul. 2020., as empresas que implantaram totalmente um sistema ERP conseguiram registrar aumento na produtividade, mostrando a importância da aceitação de um sistema ERP. Portanto, o objetivo do presente trabalho é propor uma arquitetura para a implementação do sistema, no formato de um modelo de diagrama de blocos, para auxiliar na construção de um ERP, definindo os principais módulos de softwareque um sistema ERP deve ter. A proposta apresenta a forma gráfica de como seria realizada a interligação de todo o sistema, facilitando, assim, a etapa de desenvolvimento que mais gera erros do ciclo de vida.

Referencial teórico

Fatores de sucesso

Um fator de sucesso são elementos que influenciam no sucesso de um produto (RUSSO; SILVA, 2019RUSSO, R. D. F. S. M.; SILVA, L. F. Critérios de sucesso e fatores de sucesso: é crítico distinguir o significado de ambos. Revista de Gestão e Projetos, v. 10, n. 2, ago. 2019. ). Sousa e Barros Neto (2020)SOUSA, A. M. H.; BARROS NETO, J. P. Is it possible to implement ERP in the production function of civil construction? Gestão & Produção, v. 27, n. 3, 2020. realizaram uma pesquisa exploratória para encontrar os fatores críticos de um ERP. Os autores apontaram como principais fatores a cultura do planejamento, o perfil profissional da equipe responsável pelo ciclo de vida do software e o modelo de gestão adotado para a construção do sistema. Além disso, a partir da literatura, foram apresentados três modelos para a construção de um ERP, que se iniciam com a definição da necessidade dos clientes: o modelo de Nascimento (2007)NASCIMENTO, F. P. Uma proposta metodológica para uma implantação de um ERP orientada a gestão de mudanças. Florianópolis, 2007. Dissertação (Mestrado em Administração) - Universidade Estadual de Santa Catarina, Florianópolis, 2007., que contém mais etapas e preza pelo delineamento de cada uma; o modelo de Souza e Zwicher (2003)SOUZA, C. A.; ZWICKER, R. Big-bang, small-bang ou fases: estudo dos aspectos relacionados ao modo de início de operação de sistemas ERP. Revista Administração Contemporânea, v. 7, n. 4, p. 9-31, 2003., mais direto e focado nas etapas do ciclo de vida do software;e o modelo de Bajwa e Garcia (2004)BAJWA, D. S.; GARCIA, J. E. An integrative framework for the assimilation of enterprise resource planning systems: phases, antecedents, and outcomes. Journal of Computer Information Systems, v. 44, n. 3, p. 81-90, 2004., que dá maior destaque às fases de definição dos requisitos.

Por outro lado, Abu-Shanab, Abu-Shehab e Khairallah (2015)ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015. realizaram uma avaliação com 60 gerentes e executivos da Jordânia para avaliarem os fatores críticos do sucesso de um projeto de sistema ERP. Os autores encontraram 23 fatores de sucesso, entre os quais se destaca a clareza na definição dos objetivos do sistema e nas escolhas de arquitetura. Os principais fatores delineados pelos autores são o suporte da alta administração na construção do sistema, o treinamento do usuário final, a intercomunicação e a competência da equipe de desenvolvimento. Assim sendo, uma das chaves para o sucesso se encontra na destreza técnica da equipe, mas o principal ponto é a competência humana, porque os objetivos devem estar claros para todos.

Dessa forma, a construção de um ERP, assim como de qualquer outro software, envolve diversas escolhas, iniciando-se com a definição correta da tecnologia com que o sistema será implementado até a escolha da equipe para executar o projeto. Para tanto, os requisitos devem estar claros e concisos, definindo-se o que é necessário ser implementado. Posteriormente, a equipe será responsável por decidir como realizar a construção, definição feita a partir de alinhamentos estratégicos. A comunicação, portanto, é outro fator de alta relevância para o sucesso de um ERP. Equipes de desenvolvimento de software geralmente empregam metodologias ágeis, como oSCRUM. Este é compatível com os pontos levantados, pois preza a comunicação e alinhamentos diários, além de ciclos rápidos e entregas contínuas em períodos de uma a duas semanas.

Requisitos

Um requisito é uma característica que um produto deve atender para ser aceito (PAULA FILHO, 2009PAULA FILHO, W. P. P. Engenharia de software: fundamentos, métodos e padrões. Rio de Janeiro: Ltc, 2009. ). Dessa forma, o não atendimento de um requisito impacta diretamente na satisfação do cliente e na qualidade do produto. Na construção de um softwareos requisitos são de vital importância. O Guia para o Corpo de Conhecimento de Engenharia de Software(em inglês, Guide to the Software Engineering Body of Knowledge - SWEBOK) dedica um capítulo exclusivo para tratar os requisitos de um software, além de conter tópicos sobre o correto levantamento e manutenção dos requisitos (BOURQUE; FAIRLE, 2014BOURQUE, P.; FAIRLEY, R. E. Guide to the Software Engineering Body of Knowledge, Version 3.0. IEEE Computer Society, 2014. Disponível em: Disponível em: https://www.swebok.org . Acesso em: 25 maio 2022.
https://www.swebok.org...
). Portanto, o requisito descreve os itens que a solução de um problema deve conter, crucial para a aceitação de qualquer produto.

Szitas (2004)SZITAS, Z. Technical requirements in enterprise resource planning systems. In: INTERNATIONAL SPRING SEMINAR ON ELECTRONICS TECHNOLOGY: MEETING THE CHALLENGES OF ELECTRONICS TECHNOLOGY PROGRESS, 27., Bankya, 2004. Proceedings […] Bankya, 2004. apresenta diversos requisitos que um sistema ERP deve contemplar. Ele os divide em requisitos de usuário, de interface gráfica, de sistema e de banco de dados. Para o usuário, o sistema deve conseguir automatizar todos os processos da empresa, armazenar os dados e apresentá-los ao usuário, seja em forma de lista ou de relatório, para facilitar a tomada de decisões. A interface gráfica deve ser clara, concisa, fácil de usar e manusear. Os requisitos de sistema dizem respeito à facilidade de manutenção e extensão do software. Por fim, em relação ao banco de dados do sistema, este deve ser modelado para tolerar altas cargas de acesso, prover segurança aos dados e ser extensível.

Tecnologias e Arquitetura

Ao construir sistemas complexos, como um ERP, existem duas arquiteturas que podem ser seguidas. A primeira é a arquitetura monolítica, onde o código do sistema é descrito como um grande bloco, que inclui diversos serviços. A segunda é a arquitetura de microsserviços, onde os serviços são escritos e executados de forma independente. Esta última permite uma melhor manutenção, reusabilidade e escalabilidade do que a anterior. A monolítica, no que lhe concerne, dificulta o trabalho de uma equipe no código, além de não conseguir atender a aplicações de larga escala (AL-DEBAGY; MARTINEK, 2018AL-DEBAGY, O.; MARTINEK, P. A comparative review of microservices and monolithic architectures. In: IEEE INTERNATIONAL SYMPOSIUM ON COMPUTATIONAL INTELLIGENCE AND INFORMATICS, 18., Budapest, 2018. Proceedings […] Budapest, 2018.; CHEN et al., 2017CHEN, X. et al. Restful API architecture based on Laravel framework. Journal of Physics: Conference Series, v. 910, p. 012016, oct. 2017.). Dessa forma, com base nos requisitos levantados, o uso da arquitetura de microsserviços é preferível na criação de um sistema ERP, pois facilita o desenvolvimento e a manutenção do software. A Figura 1 mostra o exemplo de uma aplicação para loja de livros, com módulos divididos em microsserviços.

A independência dos microsserviços pode ser verificada na Figura 1, em que, caso um serviço fique indisponível, não há impacto nos demais serviços prestados. Por exemplo, caso o serviço de entrega fique indisponível, o sistema continuará funcionando, pois os módulos do sistema são independentes entre si. Por outro lado, se o sistema fosse construído utilizando a arquitetura monolítica, os usuários não conseguiriam acessar os demais serviços até que o serviço de entrega fosse normalizado. Isso é importante em um sistema complexo como um ERP, pois o usuário deve interagir com o sistema independentemente dos problemas de disponibilidade de um serviço específico.

Um banco de dados (BD) é responsável por armazenar os dados relacionados (ELMASRI; NAVATHE; PINHEIRO, 2005ELMASRI, R.; NAVATHE, S. B.; PINHEIRO, M. G. Sistemas de banco de dados. 4a. ed. São Paulo: Pearson Educación, 2005. ). Ele é responsável por armazenar todos os dados de um sistema; por exemplo, as informações de uma aplicação de lista telefônica são armazenadas em um BD. Os dados armazenados em um BD são gerenciados por um sistema gerenciador de banco de dados (SGBD). Este é responsável por facilitar as operações do banco de dados, tornando tudo transparente para o usuário (CARRARO, 2019CARRARO, C. S. Proposta de estratégia para análise de escalabilidade do SGBD MySQL. Caxias do Sul, 2019. Trabalho de Conclusão de Curso (Bacharel em Ciência da Computação) - Universidade de Caxias do Sul, Caxias do Sul, 2019. ). Existem diversos bancos de dados disponíveis no mercado, como PostgresSQL, SQL Server e Oracle Database. Assim sendo, a persistência dos dados em qualquer sistema é importante, pois com isso será possível recuperá-los e realizar operações sobre eles.

Outro aspecto importante, também destacado na Figura 1, é a escolha da comunicação entre os serviços. Existem duas maneiras mais comuns: o uso de API REST (Representational State Transfer) ou mensageria. O estilo arquitetural REST é uma especificação da comunicação entre sistemas heterogêneos em aplicação web. O uso do REST permite a criação de uma arquitetura simples, escalável, eficaz, segura e confiável (CHEN et al., 2017CHEN, X. et al. Restful API architecture based on Laravel framework. Journal of Physics: Conference Series, v. 910, p. 012016, oct. 2017.). Por outro lado, há a mensageria, que trabalha em uma lógica de programação assíncrona, o que possibilita que os microsserviços se tornem ainda mais independentes, aumentando a coesão e reduzindo o acoplamento. No presente trabalho, a comunicação foi ilustrada no modelo com API REST, o que não limita o desenvolvedor de utilizar mensageria.

Materiais e métodos

O desenvolvimento do modelo foi dividido em cinco etapas: revisão sistemática/levantamento de requisitos; refinamento de requisitos; identificação dos módulos do ERP; construção do modelo de diagrama de blocos; e construção dos protótipos de tela. Essas etapas estão apresentadas na Figura 2.

As próximas seções expõem as etapas citadas na Figura 2. Cabe ressaltar que parte do material levantado no primeiro passo, revisão sistemática, foi utilizado para construir o referencial teórico do presente artigo.

Figura 1
Arquitetura de microsserviços com API REST

Figura 2
Fluxograma do desenvolvimento do trabalho

Revisão sistemática

Com o propósito de levantar requisitos e dados sobre ERP na área da construção civil, foi feita uma revisão sistemática, que se baseou nos passos propostos por Gil (2002)GIL, A. C. Como elaborar projetos de pesquisa.4. ed. São Paulo: Atlas, 2002. quanto ao delineamento de uma revisão bibliográfica. A Figura 3 mostra a sequência de passos definidos para a revisão sistemática.

Para apoiar a seleção dos relatos durante as etapas da revisão, foram estabelecidos alguns critérios de escolha, que atuaram como filtros de seleção dos trabalhos, referentes ao problema. São os seguintes:

  1. descartar artigos que não expõem as vantagens e desvantagens dos ERP;

  2. descartar artigos que não contribuem com a listagem de requisitos;

  3. descartar artigos que não estão no tema da construção civil; e

  4. descartar artigos que, mesmo atendendo aos critérios anteriores, não sustentam suas análises em uma revisão consistente ou survey.

Na leitura exploratória foi realizado um levantamento geral dos relatos ligados ao problema abordado. Para tanto, foram escolhidas as bases do Web of Science e Google Scholar como fontes de busca. Em seguida, a partir de testes nas bases e avaliação dos resultados obtidos, foi construída uma string de busca, composta das seguintes palavras-chave:

  1. (“Construction industry” OR “Automation in construction” OR “Construction management” OR “Construção civil”) AND;

  2. (“Enterprise Resource Planning” OR “ERP”) AND;

  3. (“Fatores de sucesso” OR “Processo de implantação” OR “Success” OR “Failure” OR “Requirement” OR “Analysis” OR “Architecture” OR “Challenges” OR “Solutions”).

Mediante a aplicação da string citada, nessa etapa foi listado o total de relatos encontrados nas bases.

Prosseguindo, na leitura seletiva foram selecionados os trabalhos com potencial para serem analisados em mais detalhes. A seleção se deu pela leitura do título e do abstract de cada relato encontrado. Essa etapa teve como resultado o número de relatos total após a seleção e a eliminação dos duplicados.

Já na leitura analítica foi realizada a leitura dos artigos integralmente. Com base nos critérios de escolha, os trabalhos foram selecionados pela análise do abstract, introdução e conclusão, de modo a listar a metodologia e os resultados dos trabalhos. Esta etapa foi dividida em dois subpassos:

  1. divisão de relatos: foi selecionado do conjunto de artigos obtidos no Passo 2 um subconjunto para leitura completa, com base nos critérios de seleção; e

  2. leitura de relatos em texto completo: os artigos do subconjunto criado foram lidos em texto completo e, em paralelo, foram confeccionados os fichamentos.

Ao final dessa etapa, foram obtidos como resultados o número de relatos da divisão, o número de relatos avaliados e elegidos e o número de relatos avaliados e excluídos.

Por fim, na leitura interpretativa foram listados, a partir do material analisado, os requisitos mais importantes para um ERP na área da construção civil. Para tanto, foi realizada uma análise pontual e comparativa de cada trabalho elencado no Passo 3. Ao final, foram obtidos o número de estudos incluídos em síntese qualitativa/quantitativa e os principais requisitos de um ERP para a área. O Quadro 1 lista os trabalhos resultantes da revisão e suas informações relevantes para a presente pesquisa.

Dados bibliométricos

Ao aplicar todo o processo de busca da revisão, foi obtida a quantificação dos artigos. A Figura 4 mostra o gráfico gerado no Web of Science, do número de artigos inicial.

Com a aplicação da leitura exploratória, os outros passos da revisão foram realizados. É importante destacar que ao longo de toda a análise os requisitos eram descartados e listados. Os resultados de cada etapa da revisão são os seguintes:

  1. leitura exploratória: 46 relatos encontrados nas bases;

  2. leitura seletiva: 40 relatos totais após a seleção e a eliminação dos duplicados;

  3. leitura analítica: 8 relatos avaliados e elegidos e 32 relatos avaliados e excluídos; e

  4. leitura interpretativa: 8 estudos incluídos em síntese qualitativa e quantitativa.

Figura 3
Fluxograma da revisão sistemática

Figura 4
Gráfico do número de artigos por ano (46 relatos)

Resultados

Para a construção do modelo do sistema ERP seguiram-se as etapas a seguir.

  1. levantamentode requisitos: foi realizada uma revisão de literatura de modo a coletar insights e requisitos para a construção do modelo. Esse passo se sucedeu conforme descrito na seção anterior, e o resultado é detalhado no Quadro 1. Durante a leitura dos trabalhos, os requisitos eram tabulados e assinalados conforme tipo, potencial para o uso em ERP e critério de aceitação. Tais critérios foram os seguintes:

  • - Critério 1 (C1) - Redução de custos: o atendimento do requisito permite que a empresa reduza os custos e aumente os lucros?

  • - Critério 2 (C2) - Melhoria na eficiência: o atendimento do requisito permite que a empresa melhore os processos, tornando-os mais rápidos e eficientes?

  • - Critério 3 (C3) - Auxílio na tomada de decisões: o atendimento do requisito permite que a empresa melhore a forma como as decisões são tomadas, provendo maneiras de mensurar as consequências a partir de dados consolidados?

  • - Critério 4 (C4) - Aumento da satisfação do usuário: o atendimento do requisito permite que o usuário utilize da melhor forma o sistema e se sinta satisfeito com o processo para realizar uma ação no software?

Para cada requisito levantado, essas perguntas eram respondidas com “sim” ou “não”. Caso o requisito atendesse a algum desses critérios, era selecionado; caso contrário, era descartado:

  1. validação de requisitos: foram realizadas reuniões de alinhamento no formato de brainstorming entre os autores, de forma que os principais requisitos fossem analisados por pares. Cada autor colocava os principais requisitos encontrados em discussão. O requisito era então aprovado caso ambos concordassem;

  2. identificação dos módulos/microsserviços: durante a etapa de levantamento dos requisitos, também eram elencados os principais módulos que um sistema ERP deveria possuir. Os módulos foram listados com base nos resultados da revisão sistemática dos trabalhos. Em um primeiro momento, tais módulos foram colocados juntos e analisados por similaridade. Na segunda análise, foram separados em grupos por nível de semelhança. Depois, eles foram categorizados, e os mais similares eram convertidos em apenas um. Ao final, foram levantados os sete módulos que um sistema ERP da construção civil deve possuir. A Figura 4 apresenta esses módulos e seus microsserviços; e

  3. definição da comunicação entre os módulos: os módulos foram analisados dois a dois, de forma que a comunicação entre eles foi representada com um traço. A Figura 5 mostra essa comunicação. Tal conexão foi desenvolvida com base nas boas práticas de desenvolvimento para arquiteturas de microsserviços, para evitar alto acoplamento, além de facilitar manutenções e melhorias contínuas no sistema.

Na literatura, os autores buscam levantar os requisitos, os módulos e/ou fatores de sucesso de um sistema ERP a partir de algum questionário, ou survey. Por exemplo, o trabalho de Chung, Skibniewski e Kwak (2009)CHUNG, B.; SKIBNIEWSKI, M. J.; KWAK, Y. H. Developing ERP systems success model for the construction industry. Journal of Construction Engineering and Management, v. 135, n. 3, p. 207-216, mar. 2009. empregou uma survey para levantar dados quanto aos requisitos do software por parte de especialistas. Por outro lado, o trabalho de Méxas, Quelhas e Costa (2012)MÉXAS, M. P.; QUELHAS, O. L. G.; COSTA, H. G. Prioritization of enterprise resource planning systems criteria: Focusing on construction industry. International Journal of Production Economics, v. 139, n. 1, p. 340-350, Set. 2012. empregou um questionário entre 79 especialistas em ERP brasileiros para obter informações quanto aos critérios e subcritérios para a escolha de sistemas ERP. Os autores que optam por essa metodologia para a coleta de dados os compilam e destacam os achados mais importantes. Contudo, nenhum deles se preocupa em gerar um modelo descritivo de como deve ser realizada a implementação de um ERP. Os autores se preocupam com a perspectiva de especialistas e de usuários, o que é, de fato, muito importante, mas existe também a perspectiva técnica, que impacta diretamente na construção e no consequente uso do sistema. O presente trabalho compilou esses dados consolidados na literatura e complementou com a perspectiva técnica, resultando na geração de um modelo de blocos para a construção de um sistema ERP.

Diante dos trabalhos levantados, os fatores de sucesso de um ERP podem ser categorizados em fatores humanos e fatores técnicos. No quesito humano, encontra-se a comunicação entre o time e o foco empregado por este para o cumprimento dos objetivos do projeto, com o suporte da alta administração da empresa que construirá o sistema (SOUSA; BARROS NETO, 2020SOUSA, A. M. H.; BARROS NETO, J. P. Is it possible to implement ERP in the production function of civil construction? Gestão & Produção, v. 27, n. 3, 2020. ). Por outro lado, o fator técnico encontra-se na escolha correta da arquitetura do sistema e em sua construção, que deve ser baseada em algum modelo, como o apresentado neste trabalho (ABU-SHANAB; ABU-SHEHAB; KHAIRALLAH, 2015ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015.). Além disso, a escolha de um sistema ERP está ligada ao fator financeiro e ao fator de negócios da empresa compradora, o que pode influenciar na escolha do sistema e em sua implantação (MÉXAS; QUELHAS; COSTA, 2012MÉXAS, M. P.; QUELHAS, O. L. G.; COSTA, H. G. Prioritization of enterprise resource planning systems criteria: Focusing on construction industry. International Journal of Production Economics, v. 139, n. 1, p. 340-350, Set. 2012.). Sendo assim, devem-se considerar diversas variáveis, desde a construção até a implantação de um sistema ERP.

Quadro 1
Trabalhos relacionados

Outro aspecto interessante é em relação ao contexto do ERP na indústria 4.0. Um dos pilares dessa indústria é a internetdas coisas (IoT), que possibilita a coleta de informações de diversos artefatos, como as vibrações de um prédio. Extrair, transformar e carregar informações (ETL, do inglês, Extract-Transform-Load) é um processo de integração de dados de diferentes fontes e de geração de informações a partir deles. Um ERP que coleta dados das obras em diferentes momentos seguindo esse processo pode auxiliar na tomada de decisões (DIOUF; BOLY; NDIAYE, 2018DIOUF, P. S.; BOLY, A.; NDIAYE, S. Variety of data in the ETL processes in the cloud: state of the art. In: INTERNATIONAL CONFERENCE ON INNOVATIVE RESEARCH AND DEVELOPMENT, Bangkok, 2018. Proceedings […] Bangkok, 2018. ). Isso é importante para a área da construção civil, pois uma pequena empresa pode utilizar diferentes fontes de dados para realizar a gerência. Um sistema ERP poderia realizar esse processo nativamente. Na literatura, no entanto, não foram encontrados na revisão sistemática relatos de requisitos ou trabalhos voltados para esse tópico, o que pode ser uma boa oportunidade de aprofundamento da pesquisa em trabalhos futuros, dado que o presente escopo não aborda essa questão.

Principais requisitos levantados

Ao final do processo de revisão sistemática, foram elencados os principais requisitos para o desenvolvimento de um sistema ERP na área da construção civil indicados pelos artigos analisados. Os Quadros 2 a 4 mostram os requisitos obtidos. Todos os requisitos de usuários elencados são categorizados como requisitos funcionais, enquanto que os de interface de usuário são classificados como não-funcionais.

Quadro 2
Requisitos de usuário e interface de usuário

Quadro 3
Requisitos de sistema

Quadro 4
Requisitos de bancos de dados e armazenamento

Cada quadro representa um grupo de requisitos que o sistema ERP deve contemplar. O Quadro 2 diz respeito aos requisitos de usuário e de interface gráfica. Para o usuário o importante é que o sistema responda da forma esperada para as entradas, que seja intuitivo e simples de usar (CASTRO et al., 2020CASTRO, J. P. da C. et al. Avaliação da aceitação do ERP a partir do Modelo UTAUT: uma visão qualitativa em um estudo de caso múltiplo. Evaluation of ERP Acceptance from the UTAUT Model: a qualitative view in a multiple case study. Management in Perspective, v. 1, n. 2, p. 208-232, jul. 2020.), além de facilitar o desenvolvimento e a automatização das atividades, provendo formas de visualizar os resultados a partir de listas, tabelas, relatórios, etc. Nesse grupo, o principal a ser atendido é alinhar praticidade a facilidade de uso.

O grupo de requisitos de sistema, apresentados no Quadro 3, indica o que este deve contemplar para ser fácil construí-lo e mantê-lo. Para o sistema no qual a equipe técnica atuará, deve-se pensar sempre na facilidade da construção, manutenção e melhorias contínuas, além de buscar construir um sistema pouco acoplado, no qual os módulos operem independentemente.

Por fim, para a persistência dos dados, os requisitos listados no Quadro 4 indicam que o banco utilizado e a infraestrutura devem ser altamente estáveis e confiáveis, de modo a evitar problemas de indisponibilidade e inconsistências, além de prover formas de seguir as delimitações da LGPD, pois é um ponto crucial para a operação confiável do sistema.

Construção do modelo de diagrama de blocos

O modelo lógico do sistema foi construído utilizando a ferramenta Diagrams.net. Esse modelo representa todo o levantamento realizado de requisitos e informações. A Figura 5 apresenta os módulos levantados; no total foram sete. Cada módulo é responsável por gerenciar uma parte do sistema. A construção de um software em módulos facilita a manutenção, aumenta a clareza do código e melhora o desempenho da aplicação (HURLER; HOF; ZITTERBART, 2004HURLER, B.; HOF, H.-J.; ZITTERBART, M. A general architecture for wireless sensor networks: first steps. In: INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS WORKSHOPS, 24.,Tóquio, 2004. Proceedings […]Tóquio, 2004.). As responsabilidades de cada um dos sete módulos identificados são descritas a seguir:

  1. compras: este módulo irá gerenciar as compras que a empresa realiza durante toda a sua operação, devendo armazenar dados de notas fiscais, valores gastos em compras, manifestos e pedidos, entre outros. Além disso, deve possibilitar a busca rápida por informações e permitir realizar cálculos para prestação de contas, inclusive a extração de relatórios de gastos em períodos específicos;

  2. vendas: a principal função deste módulo é gerenciar os dados referentes às vendas, realizar o cálculo de lucro, prover meios para verificar a lucratividade das vendas/vendedores e permitir a extração de insights eficientemente. Também, prover meios para vender os produtos eficientemente, ao se empregar um modelo de recomendação baseado em inteligência artificial, por exemplo;

  3. recursos humanos: módulo responsável por fazer o gerenciamento de pessoas e equipamentos de trabalho, desde computadores pessoais a equipamentos de proteção individual (EPI). Além de ser responsável por gerenciar todos os contratos e subcontratos da empresa, deve permitir o acompanhamento da vida profissional de uma pessoa na empresa e auxiliar nos processos, tais como aumento de salário, férias e banco de horas;

  4. contabilidade: responsável por realizar o controle do dinheiro da empresa. Todos os módulos que realizam algum tipo de movimentação financeira se comunicam com esse, que deve gerar relatórios de lucratividade e fazer buscas para a realização de auditorias, entre outros. É um dos módulos que exige mais confiabilidade por parte da persistência de dados, pois os cálculos realizados por ele podem impactar em processos legais;

  5. projetos: este módulo engloba todas as operações que envolvem alguma categoria de projeto da empresa, como a realização de uma obra de um prédio. Ele deve contemplar funcionalidades de acompanhamento do progresso dos projetos, realização de orçamentos, alocação de recursos e simulação de gastos, entre outros;

  6. relatórios: responsável por gerar relatórios, listas e análise de tendência de qualquer área da empresa. Esse módulo utiliza dos dados dos outros módulos para realizar suas operações; e

  7. banco de dados: este módulo é responsável por gerenciar os dados da empresa, armazenando, recuperando e excluindo dados conforme interação com o software. Ele se comunica com todos os outros módulos. Outro quesito importante que o módulo de banco de dados deve propiciar é a possibilidade de migração de dados de outros sistemas de forma simples, sem a necessidade de intervenção humana. Sugere-se o uso do banco de dados Postgresql, visto que este segue o padrão de objetos relacionais, o que permite realizar herança em tabelas ou sobrecarregar métodos, aspectos interessantes para uma arquitetura de microsserviços (HRISTOZOV, 2019HRISTOZOV, K. MySQL vs PostgreSQL: choose the right database for your project. 2019. Disponível em: Disponível em: https://developer.okta.com/blog/2019/07/19/mysql-vs-postgres#:~:text=Postgres%20is%20an%20object%2Drelational,more%20closely%20to%20SQL%20standards . Acesso em: 5 dez. 2021.
    https://developer.okta.com/blog/2019/07/...
    ).

A Figura 5 apresenta o modelo de diagrama de blocos para auxiliar na construção de um sistema ERP. Os módulos são representados por retângulos brancos, enquanto seus principais componentes são representados pelos retângulos internos e a comunicação entre os módulos é representada por linhas.

Figura 5
Arquitetura do ERP e comunicação entre os módulos de microsserviços

Nota: (a) Tela principal; (b) tela do módulo de projetos; (c) tela do módulo de relatórios; e (d) tela do módulo de compras.

Figura 6
Protótipos de tela

A comunicação é realizada bidirecionalmente. Isso significa que o módulo de compras pode se comunicar com o financeiro, por exemplo, para solicitar a aprovação de uma compra, e o módulo financeiro pode se comunicar com o módulo de compras para, por exemplo, verificar as compras realizadas em determinado período. Todos os módulos se comunicam com o banco de dados, que pode se localizar em um servidor na própria empresa ou em nuvem.

No modelo proposto, optou-se por representar a comunicação com API REST. Contudo, devido ao fato de o modelo ser genérico nesse quesito, é possível implementar qualquer opção. Além desses aspectos técnicos do sistema, deve-se pensar na construção do ERP de forma que permita a integração com as tecnologias da indústria 4.0, como inteligência artificial (IA), Big Data e IoT (SANTOS; MANHÃES; LIMA, 2022SANTOS, M.; MANHÃES, A. M.; LIMA, A. R. Indústria 4.0: desafios e oportunidades para o Brasil. Disponível em: https://ri.ufs.br/bitstream/riufs/10423/2/Industria_4_0.pdf. Acesso em: 5 abr. 2022.
https://ri.ufs.br/bitstream/riufs/10423/...
). O uso do REST, por exemplo, permite a comunicação dos sensores com o sistema ERP (ZHANG et al., 2011ZHANG, X. et al. The implementation and application of the internet of things platform based on the REST architecture. In: INTERNATIONAL CONFERENCE ON BUSINESS MANAGEMENT AND ELECTRONIC INFORMATION, Guangzhou, 2011. Proceedings[…] Guangzhou, 2011.). O uso de um módulo responsável pelo banco de dados permite que as ferramentas de Big Data e IA sejam executadas e retirem insights dos dados, auxiliando na tomada de decisões da empresa.

Protótipos de tela das principais funcionalidades do produto

A partir dos requisitos levantados e dos módulos definidos, foram desenvolvidos quatro protótipos de tela, que correspondem às principais funcionalidades do produto, sendo um conceito semelhante ao de minimal viable product (MVP). A Figura 6 apresenta os protótipos de tela. Na Figura 6a está apresentada a tela inicial, que dá acesso a todos os módulos do sistema. Na Figura 6b está apresentada a tela do módulo de projetos, que traz a listagem dos projetos e o status desse módulo. A Figura 6c ilustra a tela de relatórios selecionados para exibição. Por fim, na Figura 6d está apresentada a tela de compras, que permite o acesso às funcionalidades do módulo.

Com base nas limitações da pesquisa, como trabalhos futuros sugerem-se:

  1. revisão de literatura voltada para o estudo da relação entre ERP e indústria 4.0;

  2. refinamento do modelo para abranger outros módulos que não estão tão claros na literatura;

  3. pesquisa de campo em empresas construtoras de diferentes portes que implementam ERP para adquirir outros requisitos funcionais e não funcionais a serem considerados que não foram levantados nesta pesquisa;

  4. validação do modelo proposto com funcionários de construtoras da região; e

  5. implementação de um minimal viable product do modelo proposto.

Referências

  • ABU-SHANAB, E.; ABU-SHEHAB, R.; KHAIRALLAH, M. Critical success factors for ERP implementation: the case of Jordan. International Arab Journal of e-Technology, v. 4, n. 1, p. 1-7, jan. 2015.
  • AL-DEBAGY, O.; MARTINEK, P. A comparative review of microservices and monolithic architectures. In: IEEE INTERNATIONAL SYMPOSIUM ON COMPUTATIONAL INTELLIGENCE AND INFORMATICS, 18., Budapest, 2018. Proceedings […] Budapest, 2018.
  • BAJWA, D. S.; GARCIA, J. E. An integrative framework for the assimilation of enterprise resource planning systems: phases, antecedents, and outcomes. Journal of Computer Information Systems, v. 44, n. 3, p. 81-90, 2004.
  • BOURQUE, P.; FAIRLEY, R. E. Guide to the Software Engineering Body of Knowledge, Version 3.0. IEEE Computer Society, 2014. Disponível em: Disponível em: https://www.swebok.org Acesso em: 25 maio 2022.
    » https://www.swebok.org
  • CARRARO, C. S. Proposta de estratégia para análise de escalabilidade do SGBD MySQL. Caxias do Sul, 2019. Trabalho de Conclusão de Curso (Bacharel em Ciência da Computação) - Universidade de Caxias do Sul, Caxias do Sul, 2019.
  • CASTRO, J. P. da C. et al Avaliação da aceitação do ERP a partir do Modelo UTAUT: uma visão qualitativa em um estudo de caso múltiplo. Evaluation of ERP Acceptance from the UTAUT Model: a qualitative view in a multiple case study. Management in Perspective, v. 1, n. 2, p. 208-232, jul. 2020.
  • CHAKRAVORTY, S. S.; DULANEY, R. E.; FRANZA, R. M. ERP implementation failures: a case study and analysis. International Journal of Business Information Systems, v. 21, n. 4, p. 462-476, 2016.
  • CHEN, X. et al Restful API architecture based on Laravel framework. Journal of Physics: Conference Series, v. 910, p. 012016, oct. 2017.
  • CHUNG, B.; SKIBNIEWSKI, M. J.; KWAK, Y. H. Developing ERP systems success model for the construction industry. Journal of Construction Engineering and Management, v. 135, n. 3, p. 207-216, mar. 2009.
  • DENIC, N. M. et al Key factors for successful implementation of ERP systems. TehnickiVjesnik - Technical Gazette, v. 23, n. 5, oct. 2016.
  • DIOUF, P. S.; BOLY, A.; NDIAYE, S. Variety of data in the ETL processes in the cloud: state of the art. In: INTERNATIONAL CONFERENCE ON INNOVATIVE RESEARCH AND DEVELOPMENT, Bangkok, 2018. Proceedings […] Bangkok, 2018.
  • ELMASRI, R.; NAVATHE, S. B.; PINHEIRO, M. G. Sistemas de banco de dados. 4a. ed. São Paulo: Pearson Educación, 2005.
  • GIL, A. C. Como elaborar projetos de pesquisa.4. ed. São Paulo: Atlas, 2002.
  • HADIDI, L. A.; ASSAF, S. A. A systematic approach for ERP implementation in the construction industry. Journal of Civil Engineering and Management, v. 23, n. 5, p. 594-603, oct. 2017.
  • HASHEELA-MUFETI, V.; SMOLANDER, K. What are the requirements of a successful ERP implementation in SMEs? Special focus on Southern Africa. International Journal of Information Systems and Project Management, v. 5, n. 3, p. 5-20, jan. 2017.
  • HRISTOZOV, K. MySQL vs PostgreSQL: choose the right database for your project. 2019. Disponível em: Disponível em: https://developer.okta.com/blog/2019/07/19/mysql-vs-postgres#:~:text=Postgres%20is%20an%20object%2Drelational,more%20closely%20to%20SQL%20standards Acesso em: 5 dez. 2021.
    » https://developer.okta.com/blog/2019/07/19/mysql-vs-postgres#:~:text=Postgres%20is%20an%20object%2Drelational,more%20closely%20to%20SQL%20standards
  • HURLER, B.; HOF, H.-J.; ZITTERBART, M. A general architecture for wireless sensor networks: first steps. In: INTERNATIONAL CONFERENCE ON DISTRIBUTED COMPUTING SYSTEMS WORKSHOPS, 24.,Tóquio, 2004. Proceedings […]Tóquio, 2004.
  • MARTIN, R. C. Arquitetura limpa: o guia do artesão para estrutura e design de software. Rio de Janeiro: Alta, 2019.
  • MÉXAS, M. P.; QUELHAS, O. L. G.; COSTA, H. G. Prioritization of enterprise resource planning systems criteria: Focusing on construction industry. International Journal of Production Economics, v. 139, n. 1, p. 340-350, Set. 2012.
  • NASCIMENTO, F. P. Uma proposta metodológica para uma implantação de um ERP orientada a gestão de mudanças. Florianópolis, 2007. Dissertação (Mestrado em Administração) - Universidade Estadual de Santa Catarina, Florianópolis, 2007.
  • PACKT. Microservice architecture pattern. 2022. Disponível em: Disponível em: https://subscription.packtpub.com/book/web-development/9781789133608/1/ch01lvl1sec03microservice-architecture-pattern Acesso em: 28 maio 2022.
    » https://subscription.packtpub.com/book/web-development/9781789133608/1/ch01lvl1sec03microservice-architecture-pattern
  • PAULA FILHO, W. P. P. Engenharia de software: fundamentos, métodos e padrões. Rio de Janeiro: Ltc, 2009.
  • RUSSO, R. D. F. S. M.; SILVA, L. F. Critérios de sucesso e fatores de sucesso: é crítico distinguir o significado de ambos. Revista de Gestão e Projetos, v. 10, n. 2, ago. 2019.
  • SANTOS, M.; MANHÃES, A. M.; LIMA, A. R. Indústria 4.0: desafios e oportunidades para o Brasil. Disponível em: https://ri.ufs.br/bitstream/riufs/10423/2/Industria_4_0.pdf Acesso em: 5 abr. 2022.
    » https://ri.ufs.br/bitstream/riufs/10423/2/Industria_4_0.pdf
  • SOUSA, A. M. H.; BARROS NETO, J. P. Is it possible to implement ERP in the production function of civil construction? Gestão & Produção, v. 27, n. 3, 2020.
  • SOUZA, C. A.; ZWICKER, R. Big-bang, small-bang ou fases: estudo dos aspectos relacionados ao modo de início de operação de sistemas ERP. Revista Administração Contemporânea, v. 7, n. 4, p. 9-31, 2003.
  • SZITAS, Z. Technical requirements in enterprise resource planning systems. In: INTERNATIONAL SPRING SEMINAR ON ELECTRONICS TECHNOLOGY: MEETING THE CHALLENGES OF ELECTRONICS TECHNOLOGY PROGRESS, 27., Bankya, 2004. Proceedings […] Bankya, 2004.
  • ZHANG, X. et al The implementation and application of the internet of things platform based on the REST architecture. In: INTERNATIONAL CONFERENCE ON BUSINESS MANAGEMENT AND ELECTRONIC INFORMATION, Guangzhou, 2011. Proceedings[…] Guangzhou, 2011.

Datas de Publicação

  • Publicação nesta coleção
    14 Nov 2022
  • Data do Fascículo
    Jan-Mar 2023

Histórico

  • Recebido
    20 Jun 2022
  • Aceito
    17 Ago 2022
Associação Nacional de Tecnologia do Ambiente Construído - ANTAC Av. Osvaldo Aranha, 93, 3º andar, 90035-190 Porto Alegre/RS Brasil, Tel.: (55 51) 3308-4084, Fax: (55 51) 3308-4054 - Porto Alegre - RS - Brazil
E-mail: ambienteconstruido@ufrgs.br