Comparison of Development Possibilities of Information System: Case Study
Total Page：16
File Type：pdf, Size：1020Kb
Masaryk University Faculty of Informatics Comparison of development possibilities of information system: case study Master’s Thesis Bc. Jan Hrubeš Brno, Fall 2016 Declaration Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Bc. Jan Hrubeš Advisor: Ing. Leonard Walletzký, Ph.D. i Acknowledgement First of all, I would like to thank my tutor Professor Ing. Leonard Walletzký, Ph.D. for his support and guidance in curating the topic and content of this study. Also, I would like to thank my family, girlfriend and friends for moral support while writing this thesis. In addition, I am obliged with great appreciation and gratitude to all co-workers from studied company for valuable information. Finally, I must express my immense thanks to all people who share objective resources online and contributed to make this thesis success- ful. iii Abstract The purpose of this thesis is to present and describe information system roles and issues in a specific medium sized e-commerce com- pany as well as identifying the key motivation drivers to look for a replacement or alternative system. Such alternative is proposed taking advantage of open-source ERP systems and evaluated from econom- ical perspective to provide a decision material for studied company. Research is concluded with evaluation of its positive and negative out- comes. Although the implementation resulted to be more expensive than a maintenance of legacy information system, relevant benefits were discovered as well. This study should serve as decision material for studied company as well as referential guide for similar companies worldwide. iv Keywords ERP Systems, ERP Implementation, E-Commerce, Open-source, Odoo, Total Cost of Ownership v Contents 1 Introduction 1 1.1 Motivation ..........................2 1.2 Problem ............................2 1.3 Hypotheses ..........................3 1.4 Organization of Thesis ....................4 2 Electronic Commerce 5 2.1 Introduction ..........................5 2.2 Transaction Models ......................5 2.3 Current Trends in E-Commerce ................6 2.4 Information Systems in E-commerce .............7 3 ERP Systems 9 3.1 ERP Systems Classification ..................9 3.2 ERP Delivery Models ..................... 11 3.3 ERP Acquisition Models ................... 12 3.3.1 Build or Buy Decision . 13 3.4 Core Components of ERP ................... 14 3.5 ERP Systems in SME ..................... 16 3.5.1 ERP Systems Adoption in SME . 17 3.5.2 ERP Systems Adoption Models . 18 3.5.3 Barriers of ERP Adoption in SME . 19 3.6 ERP System Life Cycle .................... 20 3.7 Open-source ERP Systems .................. 22 3.8 Total Cost of Ownership ................... 23 3.8.1 TCO for Cloud Services . 24 4 Study Methodology 27 4.1 Analysis ............................ 27 4.2 Development Possibilities Design .............. 28 4.3 Economical Evaluation .................... 28 5 As Is State Analysis 29 5.1 Company Introduction .................... 29 5.2 Business Architecture Analysis ................ 30 5.2.1 Marketing . 31 vii 5.2.2 Procurement . 32 5.2.3 Accounting . 33 5.2.4 Warehousing . 33 5.2.5 Customer Support . 34 5.2.6 IT operations . 34 5.3 Application Architecture Analysis .............. 35 5.3.1 Legacy System Evolution . 35 5.3.2 Components of Application Ecosystem . 36 5.4 Technology Architecture Analysis .............. 39 5.4.1 Linux server . 40 5.4.2 Windows server . 41 5.5 Observed Issues ........................ 41 5.6 Conclusion .......................... 45 6 Development Possibilities 47 6.1 Discussion on Possible Development ............. 47 6.2 Open-source vs Commercial Alternative ........... 48 6.3 Alternative System Selection ................. 49 6.4 Odoo ERP Evaluation .................... 50 6.5 Proposed Architecture ..................... 51 6.6 Conclusion .......................... 52 7 Economic Evaluation 55 7.1 Total Cost of Ownership for Odoo .............. 55 7.1.1 Initiation Phase . 55 7.1.2 Evaluation Phase . 57 7.1.3 Transition Phase . 58 7.1.4 Operation Phase . 59 7.1.5 Additional Costs . 61 7.2 Total Cost of Ownership for Legacy System ......... 62 7.3 Conclusion .......................... 64 8 Evaluation and Conclusion 65 8.1 Hypothesis Evaluation .................... 65 8.2 Conclusion .......................... 66 Bibliography 69 viii List of Tables 3.1 Cost types and related cost factors [20] 25 6.1 Comparison between open-source systems by Saleh Al-Saleem [22] 50 7.1 Initiation costs 56 7.2 Evaluation costs 57 7.3 Service costs 58 7.4 Implementation, configuration, integration and migration costs 59 7.5 Support costs 59 7.6 Training costs 60 7.7 Maintenance and modification costs 61 7.8 Productivity loss costs 62 7.9 Sum of all costs for Odoo implementation 62 7.10 Legacy IS Service costs 63 7.11 Legacy IS Maintenance and Modification Costs 63 7.12 Sum of all costs for legacy IS operation 64 ix List of Figures 3.1 Business structure before ERP [5] 9 3.2 Traditional ERP system components 10 5.1 Organizational Structure 31 5.2 Legacy IS ecosystem 37 5.3 Linux server setup 40 6.1 Proposed Alternative Ecosystem 52 7.1 Cost of strategic decision, selection of services [20] 55 7.2 Cost factor of expenditure of time [20] 56 7.3 Cost factor of training 60 xi 1 Introduction What does it take to achieve a competitive edge in today’s connected world? A business must be able to timely evaluate its operations and make sense of its overall business effectiveness by collecting informa- tion without any interruptions or delay. That is the main reason why businesses invest great amount of resources in computing systems which are either developed in-house or outsourced. Often as a consequence of growth, companies divide into depart- ments where every department such as Human Resources (HR), Sales, Finance, Marketing or Procurement becomes its own entity and de- velop or purchase business applications to fit its own departmental needs. As a result, companies can deploy information systems with little or no integration abilities thereby severely slowing down the ability of executive management to make informed decisions [1]. By definition, a legacy system is a reference to such computer or software systems that are not able to be upgraded to the latest versions. But it does not mean that the legacy systems are defined by age. Instead, they are defined by the lack of the original support and incapability of meeting the latest organizational requirements. Due to the investments made in the legacy systems, companies tend to reject a change until they start being behind in the market or their customers start to complain about their inability to process and deliver orders in a timely fashion. If the legacy systems have been formed as mission-critical computing systems, then companies are also resistant to replace them with the latest enterprise resource planning (ERP) systems [2]. Should small and medium e-commerce companies focus on pri- mary field of business instead of dedicating expensive IT resources to build in-house information systems? Are commonly used ERP sys- tems flexible enough to adapt to established business processes? What is the estimated economical burden for such legacy IS replacement? These questions are discussed and concluded in this study with both specific suggestions for studied company and general information for alike enterprises. 1 1. Introduction 1.1 Motivation The purpose of this thesis is to present and describe information system (IS) roles and issues in a specific medium sized e-commerce company as well as identifying the key motivation drivers to look for a replacement or alternative IS architecture. Moreover, this research finds such alternative and seeks to calculate economical burden result- ing from its implementation. Research is concluded with evaluation of its positive and negative outcomes. Motivation is laid on a question, whether it is better to develop a custom made ERP solution (as done in studied company) or acquire third-party/open-source ERP system or components that are proofed, maintained and actively developed by community. This study should serve as a decision material for studied com- pany as well as referential guide for similar e-commerce companies worldwide. 1.2 Problem Developing a custom ERP solution in-house to manage a wholesale and distribution business results in good alignment of software with established business processes. However, many more or less obvious issues exist. The benefits gained from a completely customized solu- tion are often outweighed by the resources necessary to maintain such a “perfect fit” system. During my internship in IT department of a company focused on e-commerce business, I have realized several issues related to internal custom built information system. Firstly, the core competency in studied company is not in creating an ERP system. The problem connected with developing the system in-house is its high demand of resources and requirement of large investments into the technology and skills needed to keep the system up and running. Secondly, any in-house built system is generally not provided with outside support. ERP vendors have teams of people or community with a vast range of expertise in areas such as development, data migration, consulting, reporting, process management, training and 2 1. Introduction more. When a system developed in-house is not working properly, developers from IT department have to fix it on their own. This is often a painful and time-consuming process which takes resources away from managing other IT processes. Last major issue arises from the fact that completely customized in- house built systems are way more difficult to maintain and upgrade. In- house developed solutions often require continuous customization in order to manage changing processes, especially for a growing business. All of these small additions make the system architecture inconsistent and even faulty and leave other developers stuck when the person who developed them leaves the company.