Analysing Scalability Factors in Open Source ERP Systems Supporting ORM for SME’s

Analysing Scalability Factors in Open Source ERP Systems Supporting ORM for SME’s

Navita Jindal

Faculty of CSE Department RIMT-IET, Mandi Gobindgarh Punjab,INDIA

Kanwalvir Singh Dhindsa Faculty of CSE & I.T Department BBSBEC, Fatehgarh Sahib Punjab, INDIA

Abstract

An enterprise resource planning (ERP) system is an attempt to create an integrated product that manages the majority of operations in a company. This paper majorly focuses on evaluating Open Source ERP systems mainly OpenERP as a suitable alternative to its commercial counterparts. Open ERP uses modern methodologies and programming patterns to tackle the challenges of a growing modern Small to Middle Scale Enterprise. Open Source ERP systems such as OpenERP, From an Enterprise point of view, can be seen as a suitable alternative to its commercial counterparts.This paper provides

Tier III and Others, 37%

SAP, 22%

Mircosoft Dynamics, 10%

Oracle, 15%

Tier II, 16%

insights to new SMEs about scalability issue in Open Source ERP system and want to find out how much scalability is achieved by Open Source ERP system for SME.

Keywords

Open Source ERP Development, OpenERP, SAPAG, ORM, SME, Python

1. Introduction

   The organizations require many information systems to support their business processes [1]. In an order to remain competitive, it is a requirement of the organization to get the information supplied by each department into a common entity. ERP is a software architecture that helps to integrate all the information that continuously being produced inside the enterprise. ERP is a software architecture that facilitates the flow of information among the different functions within an enterprise. Similarly, ERP facilitates information sharing across organizational units and geographical locations.

   1.1 Major ERP Vendors

   In the mid-to-late 1990s and even today, SAP has been the ERP market leader with the four other vendors rounding out the top five. A SAP rank highest of the three vendors. Figure 1.1 below shows the revenue of five ERP firms.

   Figure 1.1: Total revenues of the top five ERP firms [2].

   The first group consists of five companies known in industry are SAP AG, Oracle and Microsoft. These companies attempted to create end to end solutions for the entire enterprise, hoping that corporate customers will purchase almost all of their critical enterprise applications from a single vendor. The reasoning behind this strategy is twofold. Firstly, for enterprise applications it is important to communicate and interact with each other seamlessly. [3]. Secondly, customers may prefer to rely on one major vendor for most of their software needs, because having a single vendor simplifies contracting and relationship management and creates a single point of accountability for all software problems.

2. OpenERP Development Lifecycle (Spiral Development Model)

   With new technologies such as web services, the applications design has completely changed. This transformation allows to have integrated processes going from a centralized and integrated architecture to a centralized and communicating architecture. This architecture is more agile by reusing objects for different concepts [8]. The Spiral model combines the idea of iterative projects (prototyping) with the systematic control aspects of the Waterfall model. The Spiral model allows an incremental delivery of the solution through the spiral. The model includes risk management within the system customization. Opposite to the Waterfall model, the documents are produced when they are needed,

   containing information required at that point in the process.

   The goal of the spiral model is to have a continuous stream of products available for users review. It is a dynamic project approach necessary to maintain a momentum. Figure 2.1 below shows the spiral model of OpenERP.

   Figure 2.1: Lifecycle of OpenERP [7].

   Methodologies of Waterfall or Spiral start with a global view of the clients needs, but OpenERP architecture and agility allow giving quicker tangible results to the client. It makes it possible to easily evaluate the real progress of the project and to control its adequacy with the scope, deadlines and budget allocation, reducing the risk of implementing an unsuitable solution for the client.

3. Proposed Work

   OpenERP provides almost all the information that is needed to pursue companys business opportunities effectively. In order to be productive with all the information it is essential that person can use normal communication tools by interfacing them with OpenERP, and not be limited just to OpenERPs interface. The Sales Module in OpenERP allows keep track of companies Sales Profiles and tasks, even if when the user is not a sales person. It provides an easy way to follow up companys suppliers and customers. OpenERPs Sales Module provides basic functionality for Quotation Management. The aim is to develop a module which possesses full Quotation management capabilities. The developed module has integrated all the activities of sales under the enterprise. The module provides voting capabilities available to all users in the company. OpenERP sales module provides basics for Quotation management and to test module for its performance issues. Successful comparison between OpenERP and commercial counterparts is needed for OpenERP module supporting ORM (Object

   Relationship Mapping). Since SMEs produce specific amount of information every minute, hence it is required that any module thus developed in OpenERP is capable of withstanding such load. Thereafter the module has been tested with existing modules for performance comparison in light of its Reading, Writing, Inserting and Deletion of data produced randomly in the enterprise from various sources. At end, it has been analyzed that the performance of created module (Quotation Management) against other four modules is better in every aspect.

   XML-RPC is known as a web service. Web services are a set of tools that build distributed applications on top of existing web infrastructures. These use the Web as a kind of "transport layer" but it doesn't offer a direct human interface via the browser. Extensible Markup Language (XML) provides a vocabulary for describing Remote Procedure Calls (RPC), which is then transmitted between computers using the Hypertext Transfer Protocol (HTTP).RPC gives Enterprises/developers a mechanism for defining interfaces that can be called over a network. These can be as simple as a single function call or as complex as a large API.XML- RPC therefore allows two or more computers running different systems and programs to share processing. The RPC approach helps developers to dont care about underlying details, in other words XMP-RPC works as an abstraction layer between Server and Clients (OpenERP Server and OpenERP Clients). Hence, XML-RPC becomes very useful in test any systems implementations without worrying about its internals.

4. Workflow of the Quotation Management

   The workflow arrows define the condition to be checked to go to the next node. These can either be a condition on the object, on the user interface or on the security (the user must be sales manager to validate the order). Figure 4.1 in the Quotation Management workflow shown below, a draft of Vote is created at saving time according to the values filled in some specific fields. The Quote can be drafted by any user the drafted quote can then be opened by the administrator or the user himself if he or she passes the appropriate ecurity levels. Any opened quote can be canceled any time even after it has been drafted.

   Figure 4.1: Quotation Management workflow

   A Quote has been open it is remains in the state of waiting, i.e. it waits either for complete approval of no of user votes on that particular module, so that the administrators can decide to take an action regarding that quote. The Quotes life comes to a halt when it has received sufficient no of votes or the quote has been directly approved by the managers of the project. At any time the process the users can view the votes being contributed to the quote in the ERP. Figure 4.2 below displays a Pie chart of vote count and quote favors.

   Figure 4.2: Voting Statistics of Quote Maintained by Quotation Management Module (OpenERP GTK interface).

   Figure 4.2 above shows the Voting statistics that where conducted by various users in the Quotation module over a single Opened quote. The users can vote a single time but they can revoke their given vote anytime. The Vote statistics described above are dynamic in nature they come from ORM query made by the module.

5. Advantage of Proposed Module

1. The Quotation Management module helps track various Quotes that are being issues by the users in the ERP system in a convenient way.

2. The Module also helps users by letting them vote on any particular Quote at any given time with various vote values. This helps as user favors and objections can be analyzed accordingly.

3. The Module provides Graphic views and Reports to analyze the Vote Statistics given by the users of the system for both GTK client and Web interface.

4. The Module is Completely Object Oriented providing ORM layer for database access and MVC architecture.

5. The Quotation Management Module also maintains Categories and Subcategories of Quotes by providing the Child-Parent relationships between categories.

6. The Quotation Management module can be used in both Desktop and web Environment i.e. extra efforts for developing a module especially for web is eliminated including maintaining Compatibility between browsers.

7. The Module is Asynchronous in nature, hence can be viewed on both interfaces simultaneously.

8. The Quotation Management module can be configured to provide transparency to both users and clients of the system.

9. The Quotation Management module can easily be extended via ORM classes available in OpenERP.

10. The module provides search functionality to find any quote according to description, user or both.

11. The module also provides administration capabilities for further configuration of the module under Quotation Management>Configuration.

1. Comparing Proposed Module with Existing Module

   ERP collects and combines data from the separate modules to provide the company or organization with enterprise resource planning [6]. Although there can be major benefits for customers of ERP, the implementation and training costs are expensive. Many companies experience problems when implementing ERP software, such as failing to specify their operation objectives, absence of a strong commitment or positive approach to change, failing to deal with organizational differences, failing to plan the change to ERP properly, inadequate testing. All these factors can mean the difference between having a successful implementation of ERP or an unsuccessful one. In this work, Execution times for read, write, delete and insert operation for number of records of created module and already existing module of OpenERP is evaluated using XML RPC. In this

   paper all the simulation results obtained are discussed and results are shown in form of graph.

   The parameters for performance are described below:

   S No.	Parameter	Description
   1.	Execution for read	Time	It is time taken for view/read a set of records.
   2.	Execution time for write	It is time editing/writing records.	taken number	for of
   3.	Execution time for delete	It is time taken for record to be deleted.
   4.	Execution time for insert	It is time taken for number of new records to be inserted.

   Table 6.1: Parameter for performance comparison

2. Comparative Performance of various Modules

Results obtained for idea, sales, CRM, Accounting, base and execution time (seconds) for number of records in term of read, write, update and delete operation is discussed in the following sections.

1. Insert Operation

   The performance in terms of execution time (Y- axis) for created module (Idea) is compared with different modules for insertion of given number of records (X-axis) as shown in above Figure 7.1.

   Figure 7.1: Insert Performance Measure of No of Records V/s Execution Time

   Following are the observations from comparison:

   1. The Base module is benchmark for any module in OpenERP, the developed module provides

      slightly lower insertion rate as compared to base module.

   2. The proposed module (idea) takes less time as compared to other modules in OpenERP.

   3. The Accounting module due to cumbersome design is slowest of all modules tested.

   4. Insertion rate in OpenERP modules using XML-RPC shows steady rise as number of records grow.

   5. For 10,000 records the developed modules (idea) takes about 521 seconds which is slightly higher than the base but better than other modules considered.

2. Write operation

   The performance in terms of execution time (Y- axis) for created module (Idea) is compared with different modules for insertion of given number of records (X-axis) as shown in above Figure 7.2.

   Figure 7.2: Write Performance Measure of No of Records V/s Execution Time

   Following are the observations from comparison:

   1. The Base module is benchmark for any module in OpenERP, the developed module provides slightly lower write rate as compared to base module.

   2. The proposed module (idea) takes less time as compared to other modules in OpenERP.

   3. Data write operations are statistically take more time than other operations like Read/Delete/Insertion so it is required to optimize modules for write operations to enhance the performance.

   4. The optimized module (Idea) shows better performance than all other modules. Optimized module's line follows the similar curvature as the base module line whereas other module lines show significant deviation for more than 1000 records.

3. Delete operation

   The performance in terms of execution time (Y- axis) for created module (Idea) is compared with different modules for insertion of given number of records (X-axis) as shown in above Figure 7.3.

   Figure 7.3: Delete Performance Measure of No of Records V/s Execution Time

   Following are the observations from comparison:

   1. Delete operations are usually rare operations as compared to other operations.

   2. Time consuming Optimizations on Delete Operations should be kept at a minimum.

   3. Deletion optimized modules show better performance than all other modules.

   4. For 10,000 records the developed modules takes about 40 seconds which slightly higher than the base 28.

4. Read operation

The performance in terms of execution time (Y- axis) for created module (Idea) is compared with different modules for insertion of given number of records (X-axis) as shown in above Figure 7.4.

Figure 7.4: Read Performance Measure of No of Records V/s Execution Time

Following are the observations from comparison:

1. The Base module is benchmark for any module in OpenERP, the developed module provides slightly lower read rate as compared to base module.

2. Even in Read Operation the proposed module (idea) takes less time as compared to other modules in OpenERP.

3. Data reads operations are statistically executed more often than other operations like Write/Delete/Insertion so it is required to optimize modules for read operations.

4. The optimized modules show better performance than all other modules, only exception is base which is benchmark for comparison.

8. Result Summary

In section 7 earlier details about all operations(Read/Write/Insert/Delete)on given set of records created module has shown the performance It can be easily drawn from the results shown above that OpenERP server can provide more that 1000 records/min for various modules. The proposed module provides slightly better performance than that of other module.

Table 8.1: Result Summary

Following are the summarized points from above table:

1. The base module was taken as benchmark for module Comparison in OpenERP

2. For all operations compared here, the proposed module (idea) takes less time as compared to other modules in OpenERP.

3. Many modules in OpenERP have cumbersome design and are slower than optimized modules. One such example is the Accounting module.

4. Insertion/Read/Deletion/Writing rate in OpenERP modules using XML-RPC shows Linear Co-relation rise as number of records grow.

5. The optimized module shows better performance than all other modules, except base.

9. Conclusions

Open ERP is a complete solution for SMEs. To save money for small businesses, open source products may provide an affordable alternative. OpenERP employs a MVC Architecture (MVC) to enable broader application adaptability, faster deployments and lower cost of ownership than is possible with products utilizing earlier generation enterprise software architectures. Without procedural coding or Complex SQL commands, OpenERP Model- driven Architecture enables rapid application development. OpenERP is an integrated Enterprise Resource Planning (ERP) and Customer Relations Management (CRM) software solution that combines the power of point of sales, distribution and inventory, e-commerce, accounting, and workflow systems within one robust application. For such purposes Traditional ERPs systems with lot of experience should be preferred over new ERP implementations such as OpenERP.

It is concluded that:

1. Many Modules in OpenERP have cumbersome design and are slower than optimized module. One such example is the Accounting module.

2. The performance of created module (Quotation Management) against other four modules is better in every aspect. For all operations, the proposed module takes less time as compared to other modules in OpenERP.

3. OpenERP scales much better in case of SMEs, providing faster Implementations with fewer costs with community support.

4. OpenERP modules provide linear correlation with number of records, i.e. as no. records increase it is easier to scale the already developed system into newer one.

5. Native SQL is proven to give more performance, however when we consider

   development time, XML-RPC Interfaces prove to be much more efficient.

6. Also, it can be concluded from the work is that all atomic operations in OpenERP provide performance that surpasses any requirement produced by any SME in general.

1. Future Scope

   In Future, the developed module can further be extended to encapsulate various aspects of an Enterprise. ORM performs nicely for small to mid- scale query and transactions. However for large amount of data processing native SQL is believed to be much faster than an ORM implementation. A native SQL and ORM performance comparison over large amount of dataset can be analysed. A complete OpenERP implementation in a SME can be studied closely for further illustration of OpenERP superiority. However, the OpenERP server still has many issues regarding authentication and cryptography of modules applying public key Cryptographic techniques like SHA-1 or Digital Signature can also be used to further improve security of a module.

2. References

1. Rittammanart, N., Wongyued, W., & Dailey, M. N., 2008."ERP application development frameworks: case study and evaluation", In Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology, ECTI-CON 2008. 5th International Conference,

   Vol. 2, No. 5, pp. 173-176. IEE

2. Klaus, H., Rosemann, M., & Gable, G. G., 2000. What is ERP?, Information systems frontiers, Vol. 2, No. 2, pp. 141-162.

3. Carstea, C., 2009. "The Power of Open Source ERP", International Conference on Manufacturing Engineering, Quality and Production Systems, Vol. 1, No. 1, pp. 151-157.

4. DeCampos, R., DeCarvalho, R. A., & Rodrigues, J. S., 2007. Enterprise modeling for development processes of open-source ERP, 18th Production and Operation Management Society Conference, Dallas, TX, USA, May 2007, pp. 3-8.

1. Kusters, R. J., Heemstra, F. J., & Jonker, A., 2009. ERP Implementation Costs: A Preliminary

   Investigation, In Enterprise Information Systems, Berlin, Heidelberg, Springer, pp. 95-107.

2. Gripe, F.G.dos S., Rodello, I.A., 2011. A theoretical analysis of key points when choosing Open Source ERP systems, Journal of Information Systems and Technology Management, Vol. 8, No. 2, pp. 441-458.

3. Johansson, B., & de Carvalho, R. A., 2009. "Management of requirements in ERP development: a comparison between proprietary and open source ERP", In Proceedings of the 2009 ACM symposium on Applied Computing, New York, NY, USA, pp. 1605-1609

4. Umble, E.J., Haft, R.R. and Michael, M., 2003. Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research, Vol. 146, No. 2, pp. 241-257.

5. Upadhyay, P. and Dan, P. K., 2009. ERP in Indian SMEs: A Post Implementation Study of the Underlying Critical Success Factors, International Journal of Management, Vol. 1, No. 2, pp. 1-10.

6. Upadhyay, P., Jahanyan, S. and Dan, P.K., 2011. Factors influencing ERP implementation in Indian manufacturing organizations: A study of micro, small and medium-scale enterprises, Journal of Enterprise Information Management, Vol. 24, No. 2, pp. 130-145.

7. Wu, J.H. and Wang, Y.M., 2006. Measuring ERP success: the ultimate users view, International Journal of Operations & Production Management, Vol. 26, No. 8, pp. 882-903.

8. Snider, B. and Balakrishnan, J., 2009. ERP implementation at SMEs: analysis of five Canadian cases, International Journal of Operations & Production Management, Vol. 29, No. 1, pp. 4-29.

9. Momoh, A., Roy, R. and Shehab, E., 2010. Challenges in enterprise resource planning implementation: state-of-the-art, Business Process Management Journal, Vol. 16, No. 4, pp. 537-565.

10. Mertins, K. and Jochem, R., 2005. Architectures, methods and tools for enterprise engineering, International Journal of Production Economics, Vol. 98, No. 2, pp. 179-188.

11. Jacobs, F.R. and Weston, F.C., 2007. Enterprise resource planning (ERP)A brief

history, Journal of Operations Management, Vol. 25, No. 2, pp. 357-363.