Functionalities-Based ERP Class System Implementation and Development

Abstract

Background: The main objective of the study is to facilitate the development and implementation of customised ERP systems by defining an ontology based on mutually exclusive database schemas for various business needs, resulting from the type of activity and the specificity of the market and industry. The need arises from the contradicting duality of the approach, indicating the need to choose between adapting standard solutions to the requirements of specific customers and developing new systems. Methods: Data on the schemes for processes performed and information needed and produced were collected from seventeen companies. The aggregate and synthesis of the research data was carried out to identify common and area-specific solutions. The SOL concept was introduced and implemented. Results: As a result, an ontology providing a universal approach to the analysis of processes was developed in order to automatically describe business processes by assigning companies to business models. Conclusions: The effect of the work on the indicated stage of the project is the development of a knowledge base containing standard models of the ERP class system built of many components. The solution to the research task is an ontology containing the developed structures and mechanisms to allow one to select the system functionality depending on the problems identified in the enterprises.

1. Introduction

Contemporary companies are complex structures, and, to be managed, usually they need IT support to deal with continuously increasing amounts of data on customers, products, processes, suppliers, etc. Solutions enabling integrated management of all company resources are ERP systems. ERP (enterprise resource planning) systems are integrated platforms that manage all aspects of a business. They support financial management, human resources, supply chain management, and manufacturing.

Implementing an ERP system requires a pre-implementation analysis. It would seem that there should be one described and commonly used approach to run such an analysis; however, system developers usually use their own experience to analyse the businesses of their potential customers. In previous years, attempts were made to build one top-level ontology that would be both nontrivial and readily accepted by a wide population of various communities responsible for the implementation of IT systems. They were abandoned due to the difficulties resulting from the many solutions used and the pace of changes implemented in the systems themselves. The work related to the review of existing ontology-based approaches to IT systems development and engineering includes [1,2,3,4]. However, in the literature on IT systems ontologies, we have not found an approach that would be flexible and customised. When analysing the business conditions in the Polish market of ERP systems, it was noticed that there is a need to offer two categories of ERP systems, namely, solutions based on standard modules that can be adapted to the specific activities and processes implemented in the organisation and unique process-based business solutions that cannot be built on the basis of standard applications or because their customisation is too complex and unprofitable. For the first group, larger ERP systems provide an embedded IDE development environment for customisation and continuous development of the provided (standard) software model. However, it turns out that one software model is not enough, though there is a possible base of solutions that can be applied under all conditions. Therefore, a question arises: should customisation of the system to the company’s processes be divided into two stages, with the first stage of selecting from a set of solutions of the initial (base) model and a second stage of detailed adaptation to the functional specifics and increasing software automation? This question became the reason for conducting research in the form of a case study for software implemented by one of the ERP software developers and vendors with an integrated IDE development environment. The scope of research was defined based on the specificity of solutions implemented by the developer, which were characterised by a very high degree of software customisation to meet the needs of customers (often, the entire system was created according to the customer’s requirements, and no standard modules were used). Based on the research question and the experience of the research partner, the main goal of the research was defined as the development of an approach to the analysis of processes for further companies, based on the developed ontology, in order to automatically describe business processes by assigning companies to model business models. Hence, the contribution of the paper is the presentation of a functionalities-based ontology approach for ERP class system implementation and development. The goal was achieved, and on the basis of the research results, the ontology related to the implementation and development of ERP systems was developed. The ontology obtained was validated by identifying the problems, assigning solutions, and using cases to them (there may be more than one of them in a given solution). Therefore, the ontology made a universal structure of the ERP class system design process and a framework for developing customised and specific enterprise solutions. To present the research results, the following structure of the paper is implemented: In the literature review section, the idea of integrated IT systems, the structure of the ERP system, and the concept of ontology are presented. In the methodology section, the research methodology is described. The solution is described in the problem solution section and is concluded in the last section.

2. Review of the Literature

2.1. Integrated IT Systems: Concept Development

Integrated IT systems are defined as information systems used to support the management of economic entities and implemented with specialised software. Integral IT management systems were created as a result of the development of science and technology, in particular in the fields of computer-aided product design, process design, quality assurance, and manufacturing [5]. They combine the use of IT to support the technical preparation of production and control production processes with the management of activities of the entire organisation [6].

An integrated IT system in an enterprise, in a broad sense, is a modularly organised software that covers areas of the enterprise’s activity such as marketing, planning, supply, the technical preparation and control of production, the distribution of finished products, sales, service, financial and accounting work, or the management of human resources [7,8]. As a consequence, the support of enterprise management processes is combined with comprehensive computer manufacturing systems. To achieve its high efficiency, it is necessary to develop information resources common to the entire organisation along with the principles of their collection, processing, and transmission, as well as uniform rules for the use of system development tools and procedures [9,10,11,12,13,14].

Contemporary IT systems were created as a result of the improvement and development of systems such as CAD (computer-aided design), CAM (computer-aided manufacturing, computer-assisted manufacturing, and integration of the design and production phase), CIM (computer-integrated manufacturing, computer-assisted manufacturing, logistics, and production technology support systems), and CAE (computer-aided engineering). Efforts have been made to link the demand for products with the demand for the resources necessary for their production [15,16]. This is how the MRP (material requirements planning) system was developed. As a consequence of its continued development and transformation into MRPII (manufacturing resources planning), the system also includes modules for business planning, sales, and production capacity, as well as production scheduling, HR and payroll management, and financial accounting [14,17,18]. The MRPII is already an integrated multi-access IT system.

The next step in the development of integrated systems was the definition of bilateral mechanisms to optimise planning and create the possibility of integration with external entities within the supply and sales chain. Thus, a broader integrated system appeared: ERP (enterprise resource planning) [19,20]. The dissemination of the Internet made it possible to expand the ERP system with the ability to access the database based on a Web browser for both organisation members and customers and suppliers, with the integration of the ERP system with other systems over the Internet, and with interfaces for analytical systems and business process modelling tools [21]. This solution is called ERPII.

The result of the next stage of development was ERP III, also called cloud ERP [22]. In this solution, it is possible to plan the company’s resources with particular emphasis and focus on mobility (benefiting from mobile devices). In addition, the possibilities of integration and data exchange have been expanded not only between the organisation and its business partners but also between institutions such as banks, social insurance institutions, and public administration. Companies that use this solution are able to meet the demands of real-time decision making and the concept of a real-time company. According to this concept, the company gains a competitive advantage due to the elimination of delays in management decisions made by management staff and the ability to maintain continuity in the implementation of key processes [23,24]. However, the most important thing is the possibility of using mobile devices, such as smartphones or tablets. The availability of the system from the level of personal devices allows for accessible access to company data, as well as for quick reactions.

Summarising, all of the systems discussed in the section are connected, yet they differ in complexity and range, starting from material-flow-focused MRP through manufacturing-resources-orientated MRPII and enterprise-resources-encompassing ERP to mobile and cloud-using ERP III. The last stage of development, ERP III, has more of a technical nature but opens new opportunities and aligns with the contemporary approach to IT systems.

2.2. The Structure of an ERP System

ERP systems from the very beginning undergo gradual, year-by-year development, gaining new functions and possibilities. Today, ERP systems that cover these functions and possibilities consist of many modules (packages) that support almost all areas of the enterprise [24,25]. Moreover, each of the modules may have additional functionalities that increase their possibilities of being used to improve the company’s operations [26,27,28,29,30,31,32,33].

In a typical structure of an ERP class system, the key elements are the relationships between its elements together with the indication of the main objects widely described in the literature [34,35,36,37,38,39,40,41,42,43].

In the case of a large integrated ERP system, the relationships between the modules and their functional content differ in each installation due to industry, market, and process differences. In addition, they must be constantly modified in line with the changing conditions of the business environment. Therefore, the scope of functions of a given module often changes, and reporting and automation must be possible in all areas of the system. An example of a network of detailed dependencies and connections between modules in one of the ERP integrated system implementation solutions is presented in Figure 1:

The concept of a module is often replaced by the concept of an area that represents the scope of the process in the field of operational management. An example of operational management standardisation is APICS (American Production and Inventory Control Society), which allows us to classify functional areas as modules of the ERP system. In an integrated system, this modularity is very often conventional, and its framework is determined only by the process assumptions of the functional unit. The examples of groups that standardise the areas of process management and their nomenclature are as follows: INV (inventory transaction subsystem), WMS (warehouse management system), MPS (master production scheduling), CRP (capacity requirements planning), MRP (manufacturing resource planning), MRPII (MRP + CRM), DEM (demand management), DRP (distribution resource planning), MES (manufacturing execution system), FPI (financial planning interface), PUR (purchasing), EDI (electronic data interchange), and CRM (customer relationship management). ERP (enterprise resource planning) determines the sum of all enterprise resource management groups, and in the GERP (Gardens enterprise resource planning) system, functional areas are integrated as presented in Figure 2.

2.3. Ontologies

The concept of ontology requires clarification due to its importance in scientific research and the multiplicity of definitions. The word ontology itself has a long history in philosophy. Ontology as a branch of philosophy is the study of what is, types and structures of objects, properties, events, processes, and relations in every area of reality. The term “Ontology” is often used by philosophers as a synonym for “metaphysics”. Sometimes, ontology is used in a broader sense to refer to the study of what may exist [1,2,39]. Ontology seeks to describe a full classification of entities in all spheres of science, and in computer science, it is a formal language used for formal naming and definition of the categories, properties, and relations between the concepts, data, and entities that substantiate one, many, or all analysed domains. The classification should be final in the sense that it can serve as an answer to questions such as what are the classes of entities needed to fully describe and explain all events in the universe [1,40]? When creating an ontology, objective criteria for its validation are needed for its evaluation [41,42,43,44]. A preliminary set of design criteria for ontologies was presented, aimed at sharing knowledge and interoperability between information systems based on a common conceptualisation [44]. The following criteria were distinguished: clarity—the ontology should clearly and communicatively present the intended meaning of defined terms, and definitions should be objective and formulated in natural language; coherence—ontology consistency refers to inference according to definitions and informally defined concepts, such as those described in documentation and examples in natural language; extensibility—the ontology should be designed to anticipate the use of a common vocabulary, offering a conceptual foundation for a number of expected tasks, and the presentation should be structured so that the ontology can be extended and specialised; minimal encoding bias—conceptualisation should be defined at the level of knowledge without depending on the specific encoding at the symbol level; and minimal ontological commitment—an ontology should require a minimum ontological commitment sufficient to support the intended knowledge-sharing activities and should contain as few statements as possible about the world being modelled, allowing the parties involved in the ontology the freedom to specialise and create copies of the ontology as needed. Ontology assessment is essential for the broad adoption of ontologies, both in web semantics and in other semantically integrated technologies. If the ontology is not validated, errors and omissions can occur, resulting in the inability to be complex in the ontology [45]. On the other hand, people who construct an ontology need a way to evaluate it.

3. Methodology

The research presented is a part of the project developed by the authors of the paper and entitled “GAMSmart—development of an innovative technology for the production and development of ERP class software, ensuring agile, fast, and flexible development, implementation, and development of a system tailored to the target requirements and specificity of a given enterprise” under Measure 1.2., “Strengthening the innovative potential of enterprises in Wielkopolska”, as part of the Wielkopolska Regional Operational Programme for 2014–2020, implemented by Gardens-Software sp. z o.o. from Poznań together with the team of the Faculty of Management Engineering at the Poznań University of Technology.

The implementation of the research was designed as a three-step procedure that included the following:

• Conducting a case study on existing software operating in a company—a step repeated to collect data from various companies and various industries (17 iterations).
• The development of an approach to the analysis of processes for other companies, based on the designed ontology, in order to automatically describe business processes by assigning companies to model business models.
• Identifying and analysing the differences in the business models of different companies at the level of individual solutions.

The research carried out first was the basis for developing the outcomes presented in the article.

The subjects of the investigation were 17 companies representing various industries. The objectives of the investigation were the processes and their execution with the support of existing IT systems (integrated or not).

The methodology of the research consisted of the observation of work under real conditions, interviews, data aggregation and synthesis, inductive reasoning (reduction), and the expert method. To facilitate data collection from observation, a dedicated IT tool was designed and implemented (developed by Gardens-Software). It was used to record and organise the data collected during the implementation of Task 1. Based on the data collected and clustered during brainstorming sessions conducted in project meetings, it was possible to formulate decision problems, which reflected the decisions made in companies.

To complete Step 2, an ontology was needed to be the basis for pre-implementation analysis and software customisation. The ontology was developed according to the methodology presented by Noy and McGuinness (2001). It is a view based on the TOP to BOTTOM logic and includes the following stages: Stage 1: using existing methodologies; Stage 2: definition of useful terms in existing methodologies; Stage 3: defining classes and their hierarchy; Stage 4: defining attributes; and Stage 5: developing class instances. When creating an ontology, a series of questions must be formulated to which the developed ontology must respond. Establishing the domain and scope of the ontology should begin with defining the domain and scope, answering the following questions. (Q1) What is the domain, i.e., the set of objects of the created ontology, and how wide is the scope taken into account in the created ontology? (Q2) What is the purpose of creating the ontology? (Q3) What question will the created ontology answer? (Q4) Who will receive the ontology and who will maintain it? The answers to these questions enabled the definition of the ontology, and the ontology enabled the development of the universal structure of the ERP system based on solutions to the decision problems identified in the research conducted. The team developing the ontology included the Gardens-Software Board and key IT experts and academics from Poznan University of Technology (research areas: management, project management, IT systems, and IMS). The team had 5 brainstorming sessions concluded in reports reviewed by Gardens-Software experts and one independent academic reviewer.

4. Solution to the Problem

The developed ontology exploits the following terms: (1) A business process is a sequence (sequence) of logically ordered activities, as a result of which a specific effect (result) of an activity (product or service) is created, which is used by the customer (external or internal); (2) basic business processes, which are the essence of the business and the primary source of added value, e.g., supply, production, marketing, and sales; (3) auxiliary business processes, which support the main processes, e.g., accounting, recruitment, and technical support; (4) a business model, a description of the company’s activity, which can be presented in the form of a map of basic and auxiliary processes; (5) a business model, which is a description of typical processes carried out in a given type of enterprise (production, trade, or service); (6) criteria for grouping, where specific variables allow one to combine use cases into disjoint groups, e.g., by operational (business) problem, all cases solving a given problem, or type of solution (multi-element, parametrised, or global); (7) functional solution (SOL), which is a set of use cases allowing for the implementation of a specific function of the system; (8) parameter, a variable that allows one to specify the way the use case works; and (9) list of problems—specific problems related to the implementation of a given process. These terms are used in the ontology development process composed of answers to the questions presented in the previous section. To answer Q1, the domain and scope of the ontology were defined. In research, the domain of ontology is a set of business processes implemented in enterprises regardless of the sector or size of the business unit. The set of business processes was identified on the basis of participant and nonparticipant observations, supplemented with simulations of key (value-adding) processes implemented in enterprises, expert knowledge of research participants, and desk research carried out by the research team. Therefore, the recognised domain and scope are broad, making the ontology universal. The answer to Q2 is the purpose of the developed ontology, which is to systemise an approach to the analysis of processes for companies (current and potential customers), using the proposed ontology, to enable assigning companies to standard business models. Q3 refers to potential benefits from the ontology, and these include grouping business processes with the following criteria: (1) sector, which are processes specific to manufacturing, trading, and service enterprises, and (2) business space, which comprises processes related to individual business tasks (supply, production, customer service, accounting, warehousing, etc.). The grouping is followed by use case identification. As part of the use case, the stakeholder performs tasks in a specific way described in a scenario. The steps (tasks) are characterised according to the following criteria: (1) way of performing the tasks: the implementation of tasks may depend on the parameters entered or the decisions made; (2) parameter: the way of performing the task depends on the parameters characterising the entered data; and (3) decision: the decision determines the next steps of the scenario. The structure of the ontology is presented in Figure 3. Figure 3 shows the schematic structure of the developed ontology along with the relations between its elements.

The developed ontology was used to define a structure for the ERP system. The structure was universal and customisable to meet the requirements of potential customers representing various business sectors. The basic assumption for structure definition was to use decision problems instead of typical ERP modules. The basis for the identification of decision problems was interviews with enterprises and studies of existing software. The interviews and observations were carried out in 17 companies representing various sizes and business sectors. They were organised as industrial visits, which usually took two full working days. As a result of the aggregation and synthesis of research results, 300 model use cases were formulated. Each use case was described and parameterised. Additionally, 125 solutions were developed and described in response to the identified problems. For the analysed cases, 150 system operation scenarios were described as a response to formulated decision problems in 10 separate business spaces (e.g., sales, finance, warehouse, and production). The data collected and organised according to the developed ontology formed a knowledge base that can be used as a source of problem solutions that can be implemented depending on the needs and requirements of potential customers. Thus, the ontology obtained was validated by identifying problems and assigning solutions and use cases to them (there may be more than one of them in a given solution). Therefore, the ontology is a universal structure of the ERP system design process and a framework for developing customised and enterprise-specific solutions.

5. Validation

The ontology was developed for Gardens-Software, in a state-supported project, and has been used since 2020 in more than 10 projects. It was used for product (system) development for service and manufacturing companies—customers of Gardens-Software. Product developers were using the ontology to build the architecture of customised solutions following the SOLs logic and original approach developed by Gardens-Software in cooperation with the Poznan University of Technology. In their work, they had a chance to confront the ontology with real-life cases. Hence, to assess the quality and originality of the solution presented in the paper, a series of interviews with experts in product development who had used the ontology was conducted in September 2023. We approached experts and selected 11 who assessed their competence in ERP systems implementation as 4 or higher on a 1–5 scale, with 1 being the lowest and 5 being the highest, and who had experience covering more than 10 implementations, which gave a scope of over 100 ERP implementations in various companies (differing with size, scope of activities, and industry). The experts were employees of Gardens-Software as the ontology developed is IP-protected and the company’s own solution.

In the first round of questions, experts were asked about the terminology implemented in the ontology. The key terms were listed and their definitions were confronted with their understanding and interpretation of experts. For the term business process, 10 out of 11 experts fully agreed with the definition in the ontology (5 on 1 to 5 scale), while 1 expert simply agreed (4 on 1 to 5 scale). For the terms business model, SOL, and list of problems 9 out of 11 experts fully agreed with the definition in the ontology (5 on a 1 to 5 scale), while 2 experts simply agreed (4 on a 1 to 5 scale). For the terms grouping criteria and use-case parameter, 8 experts fully agreed with the definition in the ontology (5 on a 1 to 5 scale), while 3 experts simply agreed (4 on a 1 to 5 scale). Thus, experts fully endorsed terms used in the ontology (for presented terms, more than 80% of respondents agreed with the definitions presented).

The next questions were also theoretical, concerning the structure of the ontology and the relations that were used. A total of 82% of respondents fully agreed with the structure presented, while the rest accepted the approach (answered 4 on a 1 to 5 scale).

Moreover, experts appreciated the practical implications of the ontology and its usefulness for pre-implementation analysis and system description. We asked the experts whether the terms specific to each company and the processes it performs can be assigned to universal terms used in the ontology, and 9 out of 11 experts believed it is absolutely possible (5 on a 1 to 5 scale), while 2 thought it is possible (4 on 1 to 5 scale). That makes the ontology flexible and practical.

We also wanted to know whether the terms used in the ontology are consistent with the terms used in companies that want a new customised ERP system developed. A total of 9 out of 11 experts found them fully consistent (5 on a 1 to 5 scale), while 2 thought they were consistent (3 and 4 on a 1 to 5 scale). What is more, more than 90% of experts found the ontology universal (respondents selected 5 (fully agree) on a 1 to 5 scale).

The ontology was designed based on the company’s experience, which was confronted with an academic approach. The result of the undertaking proved to be useful and, according to experts, is being used in their daily work on ERP implementation, facilitating their work and increasing customer satisfaction.

6. Conclusions

The objective of the research presented in the article was to introduce a solution to facilitate the development and implementation of the ERP system. The goal was achieved by formulating the formal background for the structure of the ERP system, namely, the functionalities-based ontology approach for the implementation and development of the ERP class system. The developed ontology was used in the research, and, as a result, a knowledge base was developed containing many standard components and functional solutions (SOLs) to identified decision problems. The knowledge base is the source of components of an ERP system that can be selected based on the recognised characteristics of a company (potential customer). Gardens-Software, the company that was the beneficiary of the project partially presented in the paper, built the first version of the knowledge base, allowing the creation of a base model of functionality (an initial set of solutions focused on the company’s processes) for further, more detailed customisation at the stage of ERP system implementation in the enterprise. Therefore, the ontology and approach were tested and used by Gardens-Software in product development and customer service successfully.

The developed ontology was subjected to internal evaluation by the ontology development team and was subjected to expert evaluation. The following criteria for evaluating the ontology were used: clarity, consistency, transparency, extensibility, minimum formalisation commitment, and minimum ontological involvement. Ontology should effectively convey the intended meaning of defined terms. Definitions should be objective and use formal axioms, and a full definition (defined by sufficient and necessary conditions) is preferable to a partial definition (defined by necessary or sufficient conditions). All views should be described in natural language. The developed ontology covers the basic concepts; their definitions are presented in the natural language. Another criterion is coherence. This is the criterion for the inference mechanism. The ontology should be consistent; that is, it should sanction inferences that are consistent based on the definitions. If the sentence to be derived from the axioms is inconsistent with the definition or an informally given example, then such an ontology is not consistent. The description of the ontology presents a structure that sanctions inference as a result of the relational definition of the basic elements of the ontology. The extendibility criterion states that the ontology should be designed in such a way that it is possible to use a common dictionary. A terminological basis should be provided for the scope of the expected tasks, and the representation should be carried out in such a way that the ontology can be extended and narrowed down in a monotonic manner. The developed ontology allows us to define new terms on the basis of an already functioning dictionary in such a way that there is no need to change the existing definitions. The developed ontology is extensible; it is possible to introduce new elements at any level of the hierarchy without having to change the definition. The evaluation principle from the point of view of minimal encoding bias is an engineering analysis in which the physical values are modelled by the equations of variables with numbers as values. The author of the definition describes quantities by physical values as a physical dimension, i.e., time, length, mass, and energy are examples of a physical dimension. The structure of the ontology and the scope of its application clearly indicate the qualitative nature of the description of the elements. If it is necessary to use quantitative parameters, they are described in appropriate quantities. The last criterion is minimal ontological commitment, meaning that an ontology should have as few assumptions and limitations as possible and, at the same time, only those that are necessary for knowledge representation systems because there is a risk that in the future, new definitions may not be in line with the future needs of representation. The developed ontology is universal, which means that it does not contain assumptions and limitations other than those necessary for knowledge representation systems. The developed ontology meets all evaluation criteria, which means that it is structured correctly. Another example of ontologies developed in the field of knowledge management for information systems that can be used is, among others, the CYC project [44]. Furthermore, ontology references can be found in [46,47,48,49,50,51,52]. Nevertheless, the ontology developed is dedicated to a specific approach to product development designed and implemented by Gardens-Software, which makes it difficult to compare it with other solutions described in the literature.