Comparison of Development Possibilities of Information System: Case Study

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

iii Abstract

The purpose of this thesis is to present and describe information system 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 system. Such alternative is proposed taking advantage of open-source ERP systems and evaluated from economical perspective to provide a decision material for studied company. Research is concluded with evaluation of its positive and negative outcomes. 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 information 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 departments where every department such as Human Resources (HR), Sales, Finance, Marketing or Procurement becomes its own entity and develop 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 primary field of business instead of dedicating expensive IT resources to build in-house information systems? Are commonly used ERP systems 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 resulting 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 company 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 solution 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.

1.3 Hypotheses

The literature overview suggests that IS must evolve to successfully support business activities in a company. Also, its implementation should not only be feasible, but should also help to establish flexible environment to support internal business processes and let the company grow. Therefore, I have set the general research hypotheses as following:

H0: Studied company and alike SMEs should benefit from utilizing open-source ERP system over custom in-house developed solution.

This hypothesis should imply from and be supported with following complementary statements:

H1: Using open-source ERP system would lead to cost reductions over the in-house developed IS.

H2: Using open-source ERP system would benefit enterprise through improved flexibility and scalability.

3 1. Introduction 1.4 Organization of Thesis

The first chapter has introduced the the motivation and problems discussed in this thesis. Chapter 2 and 3 goes through the frame of reference for the thesis, including literature overview of e-commerce, ERP systems and Total Cost of Ownership (TCO) calculation. Chapter 4 describes the research methodology and steps that have been taken during the work with the thesis. Chapter 5 goes into detail of studied company and analyses its current state and needs from different perspectives. Also, this chapter summarizes issues regarding used information system that have been discovered throughout the analysis. Chapter 6 uses these issues as a foundation for developing an alternative architecture. This chapter concludes on proposed application ecosystem to overcome discovered problems and bring other potential benefits for the company. Chapter 7 evaluates both old and new architecture from economical perspective and estimates their financial burden in form of TCO. The final chapter, chapter 8, presents the evaluation of hypotheses, conclusions and goes further into detail concerning the lessons that the studied company may learn from the results. Also, discussion on possible future work related to this topic is included.

4 2 Electronic Commerce

This chapter provides a literature overview of E-Commerce, its business models and existing approaches to related information systems. E-commerce (or Electronic commerce), is a term for any type of business, or commercial transaction, that involves the transfer of information across the Internet. Currently, e-commerce is exclusively used via the Internet, but before the Internet was widely available, a form of electronic transactions occurred over Electronic Data Interchange (EDI) [3].

2.1 Introduction

The term e-commerce is often used interchangeably with term E- business. Although, E-business refers to a broader definition of e- commerce, not just the buying and selling of goods and services, but also servicing customers, collaborating with business partners, con- ducting e-learning, and processing electronic transactions. The term e-tail is also sometimes used in reference to transaction processes for online shopping [3]. Today, barely any modern business producing or selling goods dare to exist without its online presence. Moreover, purely E-Commerce (virtual) companies emerge. According to data from the E-Commerce Foundation1, web sales totaled 455.3 billion euros in 2015 and are estimated to reach 509.9 billion euros in 2016. E-commerce conducted using mobile devices and social media is on the rise as well. Online spending on mobile device has doubled between 2014 and 2015, reach- ing a share of 25 percent of total e-commerce transactions.

2.2 Transaction Models

Currently, there are three major types of transaction models adopted by e-commerce:

1. http://www.ecommercefoundation.org/

5 2. Electronic Commerce

1. Business-to-consumer (B2C) model is a business or transactions conducted directly between a company and consumers who are the end-users of its products or services. 2. Business-to-business (B2B) is a type of commerce transaction that exists between businesses, such as those involving a manu- facturer and wholesaler, or a wholesaler and a retailer. 3. Consumer-to-Consumer (C2C) is a type of electronic commerce in which consumers buy, sell, or trade products and services from one another through a third party website. B2C model is also called as "E-tail" which stands for electronic retail or sometimes also online shopping.

2.3 Current Trends in E-Commerce

As e-commerce shopping model is under rapid growth, market competition seeks for new technological innovations. In 2016, following features were integrated by leading e-commerce companies.

Multi-device Shopping Many digital consumers are adopting a multi-device approach when it comes to online shopping. While PCs and laptops still remain as main online shopping devices, consumers tend to switch between mobiles and tablets when browsing products of their interests. According to GlobalWebIndex2, 52 % of consumers start shopping on one device and finish their order on another. Therefore, it is crucial to support such devices and develop responsive e-shop with good user experience.

Personalization and Contextual Shopping The next big trend is personalization. This term means that the home- page, product listings, transactional e-mails3 or other parts of the website might change, depending on customer’s preferences.

2. https://www.globalwebindex.net 3. E-mails triggered by user’s action on a website

6 2. Electronic Commerce

Preferences may be set by various factors. They can reflect customer’s behavior on the website, products he already purchased, his current location etc. It is obvious that e-commerce businesses are based on one or more technical solutions to power its internal operations. Next section briefly reviews commonly used systems and describes key components for e-commerce business model.

2.4 Information Systems in E-commerce

At the beginning of the e-commerce era, retailers mostly adopted vertically integrated solutions4 to control the entire e-commerce value chain. However, they began to realize that to achieve agility, a better approach would be to focus on certain core capabilities and then create a partner ecosystem around them [4]. From a technical point of view, this means it is advised to have a lightweight e-shop platform with core e-commerce functionality which can be extended by additional systems from third party vendors. "In a typical e-commerce ecosystem, integration and inter-operability become critical factors to enable seamless coordination among the systems." [4] Furthermore, an increasing adoption of cloud computing technology could results in more challenging integration scenarios involving cloud services. Thus, an e-commerce platform is required that suits the advanced needs for flexible and agile service integration. Nowadays, a typical e-commerce infrastructure can be described as cooperation between e-shop platform (e.g. Magento5, Shopify6...) and other information systems supporting order fulfillment and other business operations (e.g. ERP, CRM...). In next chapter, I will briefly introduce such information systems and their adoption in small to medium businesses.

4. Addressing needs of specific industry or market 5. https://magento.com 6. https://www.shopify.com

3 ERP Systems

Traditionally, organizations were divided into different units (for example sale, production, logistics, accounting, etc.) based on their functions. Each department had its own goals and objectives, which from their point of view were in line with the company goals. Also, it func- tioned in isolation and had data collection and analysis performed separately (Figure 3.1). In this type of company no-one knew what the other was doing, which tended to cause a chaos in the organization [5].

Figure 3.1: Business structure before ERP [5]

To solve the isolation issue, the enterprise system was developed by integrating the information systems and enabling smooth flow of information across different section and department. Information about all the aspects of the organization is stored centrally and is made available to all the departments. Khazaeli [5] defines ERP system as an integration of all the processes and data of an enterprise into a comprehensive integrative structure (Figure 3.2).

3.1 ERP Systems Classification

E-Retailers extending from an offline channel with brick and mortar1 stores have an ERP system to manage its operations. When introducing an online channel the retailer adds an online shop component to the system that allows customers to order goods or services online. Thus the e-commerce platform in this case consists of a lightweight online shop and the ERP system. A pure online retailer on the other hand might implement a more comprehensive e-commerce platform architecture. Such platforms

1. physical presence in a building or other structure

9 3. ERP Systems

Figure 3.2: Traditional ERP system components not only provide an online shop but also a rich set of back office functionality tailored to business requirements. Depending on the complexity and size of the business an ERP component might not be present at all [6]. The ERP tools that a company selects often depend not only on specific business processes it wants to improve, but also on whether it is selling products or services. Businesses that sell products often have manufacturing, supply chain and distribution functions that the ERP system must address. For organizations that sell services, ERP capabilities such as project management for service engagements and support for field services and sales operations are very important [6]. Two approaches currently exist for enterprise software in terms of application composition.

1. All-in-one systems: These systems include necessary modules to perform wide range of business processes. Their extensive

10 3. ERP Systems

coverage may bring functional overhead, which is not appropriate for e.g. small companies. On the other hand, these systems offer high universality and flexibility. 2. Best of Breed (BoB) systems: Infrastructure of services from various vendors, where each service provide company with detail functionality for one type of business operations (e.g. marketing service, accounting service). Complex service or- chestration is required for successful implementation.

Gargeya claims, that "all-in-one ERP systems are the most preferable method as the businesses replace the legacy system. However, ERP system implementation is one of the most challenging project and is not easy to achieve." [7]

3.2 ERP Delivery Models

Another classification perspective is laid on whether ERP functions should be installed and used as a software product or acquired as a service. According to Luttighuis [8], ERP hosting is a solution for companies seeking to cut down on maintenance costs. When ERP is offered on a component basis, ERP components may even be outsourced one by one, or ERP modules from different vendors may be used. Two kinds of ERP system distribution can be recognized:

∙ Product-based: An on-premise ERP system is one or more servers at the actual location of a business. Some companies prefer to have the infrastructure on site so they can fix any issues on their own accord. Also, some businesses do not want to stand a risk of information leak as a result of poor cloud security. ∙ Service-based: ERP as a service (SaaS), or in the cloud, is when a company stores all of its integrated data in a sever hosted by a third-party vendor. These services charge an upfront fee, but there’s no maintenance and upgrade costs to the partnering company. Cloud-based options offer a more flexible solution and create an agile work-space for businesses that use cloud ERP.

11 3. ERP Systems

On-premise ERP systems usually require large upfront and ongo- ing investments to purchase and manage the software and the related hardware, servers, and facilities necessary to run it. For cloud-based ERP, initial costs are typically much lower because a company implements the software to its requirements and access is provided through internet connection. Next section will discuss approaches that companies use to acquire an ERP system.

3.3 ERP Acquisition Models

Kroenke [9] explained how an organization acquires application software or sources of them. The first approach is to purchase the commercial off-the-shelf software (COTS) which provides the customer an exact or fixed recurring cost. However, due to universal character of such systems, some applications in the suit do not fit the organizational requirements. The second software sources can be obtained by buying off-the- shelf software with partial customization included in acquired pack- age. This software is more expensive than the previous one, but on the other hand, such system will be better fit than pure off-the-shelf software. The last group is tailor-made software or custom-developed software. This software is obtained by hiring a vendor or in-house developers to make a custom software so that the applications exactly fits with company requirements. Nowadays, this list must be extended by open-source systems that are free to obtain and provide an easy way of customization for a company. Research conducted by Wilhelm [10] indicates that customization in ERP application increases the risk of failure and cost of the project significantly increases comparative to none customized implementation. Higher levels of dissatisfaction among ERP application users have been observed due to customization and BPR2 related issues, im- pacting mainly on cost and duration of the project. ERP vendors have

2. Business Process Reengineering

12 3. ERP Systems

also admitted that generally a customer spends more to implement than to buy the software itself.

3.3.1 Build or Buy Decision While building custom software is expensive, the long-term benefits may worth it. However, a company must dedicate significant amount of energy, resources, and time to its development. These tasks associated with custom software may initially make a off-the-shelf solution seem like the better option, but there are several reasons to consider [11].

Arguments for Commercial Systems Firstly, third-party party ERP systems are proofed by many companies and are ready to be used. Companies following standard business model requiring ERP systems are given a software, which supports related processes and are highly optimized for its purpose. Also, quality ERP systems are built with great amount of resources and effort. Vendor has deep understanding of problems related to ERP systems and is able to build a technically effective and modern platform[1]. Vendor and community expertise is also a significant benefit. Sup- port and training can be obtained from various sources, which also lead the company to implement the industry best practices in software utilization and processes management. Wilhelm [10] claims, that integration of third-party ERP systems can be decomposed according to the implementation strategy and thus easily quantified in terms of costs calculation. Also, experiences from other companies and community may be available to contribute to a successful implementation.

Arguments for Custom Systems In essence, the custom solution is designed with the company in mind and so it completely fits the company requirements. Moreover, itis less likely the business processes will have to change to fit the ERP solution.

13 3. ERP Systems

From legal perspective, the company has full ownership of the final product as well as its source code and the knowledge gained while developing it. Such argument minimizes the risk of product or support discontinuity. Custom system can also bring another degree of competitive advantage. Company has a tool to differentiate from the competition and do specific processes more effectively or in a completely different way. Helo [12] claims, that in the case of a COTS, it can be less costly as the costs of development have already been assumed by the vendor, so choosing this option gives the advantage of not needing to spend on development which the money can be used toward other company resources or projects. But on the other side, an important factor to be considered about COTS is the system compatibility. The company may have certain existing programs that may not be compatible with the ERP system that they acquire. According to [12], building custom software can bring a lots of benefits, but companies should only pursue that strategy if a better software can provide a competitive advantage relative to its competitors, or it is building a large business that can spread the implementation costs over a large number of clients.

3.4 Core Components of ERP

Despite the wide variability in company needs for ERP, there is a core set of ERP components for both front-office and back-office operations that most companies seek for [11]:

Finance

Companies want to record, track and consolidate all of their sales and operational information in a central accounting system. ERP financial software delivers this capability with centralized general ledger, accounts receivable, accounts payable and payroll systems.

14 3. ERP Systems

HR ERP offers a centralized HR system that enables organizations to track personnel hours and employee performance evaluations across the organization as well as handle benefits and manage talent and staff development.

Purchasing / Procurement ERP purchasing module streamlines the procurement process from purchase-order issuance and vendor management to payments and reporting. ERP purchasing module also has the ability to automatically route approvals of purchase orders and payments to the appropriate corporate decision makers.

Supply Chain An ERP system that encompasses not only the company’s internal operations, but the operations of supply chain business partners and suppliers in the production of goods from raw materials, inventory and supplies gives companies much needed visibility into their manufacturing processes.

Distribution / Warehousing ERP distribution and warehousing systems offer automation that enables the company’s sales force to link customer quotes and orders directly into inventory management, fulfillment and accounting systems. This ensures that orders are filled in a timely manner. Many ERP distribution systems also include comprehensive warehouse management functions that ensure that inventory in warehouses is optimized to meet the company’s supply chain requirements.

Inventory An inventory management system optimizes inventory stocking and consumption and provides for both manual and automatic inventory forecasting. Companies can set order policies for individual parts

15 3. ERP Systems and assemblies. The software also issues reports on inventory excep- tion and potential oversupply conditions, and has the ability to track inventory across multiple locations.

Business Intelligence Organizations increasingly want data analytics that enable them to examine information about the business. To facilitate this, ERP systems provide pre-designed reports that companies use to assess business sales and operations, along with the ability to perform data mining and to develop custom reporting.

Customer Relationship Management The CRM subsystem is a centralized repository of customer information that customer-facing organizations across the company can use and access. It includes information about company interactions with prospects, customers, clients and partners, and can track all of these interactions across marketing, sales, service and any other customer- facing department. CRM includes sales force reporting, tracking and automation, marketing, service and support. Using CRM helps companies leverage their core customer relation- ships, which is key to the success of small retailers competing with large chains. They can use customer data to become more familiar with top customers, to offer targeted marketing promotions and to improve their total customer experience [13]. Although BI and CRM subsystems are not traditionally included in ERP systems, they are often offered as an extension due to high popularity and demand for such functionality [11].

3.5 ERP Systems in SME

"Existing literature suggest that Small to Medium Enterprises (SME) may be differentiated from larger enterprises by a number of key characteristics as personalized management, severe resource limitation, flat and flexible structures etc." [14] Another major characteristics of SMEs is the absence of proper and formal IS practices and skills. In the present era of globalization, it is obvious that the survival of SMEs

16 3. ERP Systems will be determined by their ability to adapt to advanced information systems. Traditional ERP systems were designed to support in-house processes and supply chains that rarely changed. Modern logistics are far more fluid, and stakeholders demand personalized services. ERPcan bring flexibility and real-time decision support to businesses which allow converting flexibility into efficiency and responding to customer demand before the customer even asks [14]. Also, SME tend to be influenced by number of factors while selecting an information systems. Such factors could be related to lack of resources such as knowledge and skill, availability of time and money. Medium businesses have also adopted a cautions approach towards ERP applications due to the lack of information with strategic direction and associated risks involved in ERP implementation.

3.5.1 ERP Systems Adoption in SME It is not necessary for SME to select costly and well-known commercial ERP systems, such as SAP or Oracle. They should consider cheaper alternatives that suffice their business needs. It is also important to note that selecting an appropriate solution for SME is difficult as it must align with existing information technology management and business needs [10]. Several criteria should be accounted when selecting an appropriate ERP system: ∙ Product affordability: SME should always consider its financial situation. ∙ Domestic support: ERP systems are highly sophisticated and require great degree of expertise. It is beneficial to choose a system with good local support. ∙ Technically upgradeable: SME should select a system that is easily upragadable and thus able to follow changes in technology. ∙ Latest Technology: Fast-paced technology environment requires an easily implementable product with friendly user interface and capability to adopt any future modifications.

17 3. ERP Systems

SME is also significantly dependent on implementation process. Wilhelm [10] defines three categories of implementation strategies:

∙ Organizational strategies comprising of project management, organizational structure, change strategy development and deployment, managerial style, ideology, communication and so forth.

∙ Technical strategies contain technical aspects of ERP implementation such as, ERP installation, configuration, complexity and capable technical staff to handle the complexities, time-cost factors and so forth.

∙ People strategies including management and staff related issues towards change management, training and level of staff engage- ment in a project.

3.5.2 ERP Systems Adoption Models Many researchers have described ERP implementation stages and tried to identify standard steps in the implementation process. One of ERP implementation models was described by Wallace [11], based on his study conducted in three anonymous companies and with consultations of 20 ERP practitioners. This model consists of five phases including four pre-implementation phases (focus, as-is analysis, to-be proposition, construction and testing) and one actual implementation phase (go live). This model is briefly described below:

∙ The Planning (focus) phase consists of initial project activities such as, formation of steering committee, project team selection, project guide development and project plan creation.

∙ The Analysis (as-is) phase consists of business process analysis, initial ERP system installation, business process mapping on ERP functions and project team training etc.

∙ The Design (to-be) phase includes, high level and detailed de- signing for user acceptance, interactive prototyping with constant communication with ERP users.

18 3. ERP Systems

∙ The Construction (construction and testing) phase consists of comprehensive configuration development, population of real data in test instance, interfaces building and testing, creation and testing of reports, system and user testing.

∙ The Actual implementation phase (go live) includes, network building, installation of desktops and organizing the user training and support.

3.5.3 Barriers of ERP Adoption in SME

Despite ERP system presumptions to benefit companies and a consid- erable capital investment, not all ERP implementations are completed successfully. ERP implementations have commonly delayed estimated schedule and overrun initial budget [12]. According to Helo [12], “unlike other information systems, the major problems of ERP implementation are not technologically related issues such as technological complexity, compatibility, standardization, etc. but mostly about organization and human related issues like resistance to change, organizational culture, incompatible business processes, project mismanagement, top management commitment, etc.” Huin [14] claims, that one of the major constraint faced by SMEs implementing ERP system is the adaptability of such system. To increase the adaptability of ERP applications, vendors introduced different integration techniques such as Enterprise Application Integration (EAI) and also improved application design and modules to facilitate implementation handling capabilities of business, regardless of its size. Wilhelm [10] described great issues in relation to ERP implementation that includes possible resistance of staff to adapt to the product. If staff sees ERP applications as an inconvenience for their job, they will develop negative attitude towards it. To overcome the possible resistance to change, management will have to communicate with its employees in a more effective way. Com- munication strategies could be useful to educate users about benefits of ERP applications. In many cases ERP projects fails due to lack of

19 3. ERP Systems communication and if problems are addressed appropriately, positive benefits could be reached [14]. Last but not least, a major barrier of ERP implementation in SME is naturally a lack of resources and less control over its business operations. Research conducted by Beaumaster [15] identified and categorized problematic issues regarding the ERP implementation. Specific cat- egorizations of the issues can be viewed as: management process issues, organizational environment issues, leadership issues, technical systems issues, and personnel issues.

∙ Management process issues speak to the functional operation of an organization such as budgeting, personnel, and general management.

∙ Organizational environment issues are identified as factors which are less tangible such as organizational culture, change, and behavior.

∙ Leadership issues relate to the areas which involve the interac- tion and direction of the organization executive.

∙ Technical systems issues are mainly those referring to the hardware and software considerations of information technologies.

∙ Personnel issues are those issues surrounding each individual in the organization.

Therefore, ERP implementations need accurate estimation, preparation with a holistic view, and systematic management of the entire ERP life cycle. All stages of ERP system maturity will be described in following section.

3.6 ERP System Life Cycle

Acquisition and implementation of an ERP system is minor investment in terms of both human and financial resources. When a system is successfully implemented, it goes to maintenance mode and organizations start reaping its benefits. After a longer period, it becomes

20 3. ERP Systems

difficult and expensive to maintain the system and extend its features. Therefore, a process of re-implementation as well as new cycle starts [16] . ERP life cycles, which span over 10 to 20 years of effective operating life, are often confused with ERP Implementation Life Cycle. According to Management Study Guide3, phases of ERP life cycle are following: 1. Introduction: The introduction of an ERP system starts with vendor selection or development and ends with deployment and running phase. 2. Optimization: After the system is live and rolled out, there is a period of uncertainty. Lack of understanding causes a lot of confusion among users and some software bugs will inevitably appear. With retraining, some customization and assistance from a help desk, this phase should not last longer than one year. 3. Maintenance: This is the longest period of life cycle, when the organization start reaping value of its investment. Need for some changes continue such as new reports, different work- flows, some localization on taxes etc. For a complicated system, there may be a third party consultant helping maintenance at site. 4. Extending Values: This phase is usually simultaneous with the maintenance phase. New or changed business processes necessitate minor or moderate changes in the system. If a lot of customization has been done, costs related to system extension may be prohibitive. 5. Decaying Performance: For an enterprise, business needs and technological requirements continue to evolve. Cost, complexity and difficulty to modify the existing system emerge. Fixing existing system is no more viable and provides diminishing return. Alternatives are investigated and decision of re-implementation should be taken.

3. http://www.managementstudyguide.com/erp-life-cycle.htm

21 3. ERP Systems

6. Re-implementation: Similar to Introduction phase as mentioned above. As organizations have more knowledge now, initial process will be carried out more professionally. Companies will likely adopt better solution with minimum need of customization, so that the next cycle gives a better Return on Investment (ROI). Companies should always strive to select the best software in terms of business processes alignment. Proper fit will vastly mitigate issues emerging throughout the whole ERP life cycle. Next section will introduce open-source EPR systems, their benefits and drawbacks.

3.7 Open-source ERP Systems

Currently, market leaders in developing and implementing ERP systems are SAP, Oracle, Microsoft and Sage. These vendors provide extensive ERP solution, usually at a very high cost. For this reason, SMEs mostly cannot afford an investment in such system. As a result, open-source ERP systems become popular as they are less expensive compared to proprietary ERP systems and allow the same level of compatibility across different platforms, tools, plugins etc. [11]

Advantages ∙ Less expensive As already explained, open source ERP system minimize business cost of organization in a long run. i.e., open source ERP system does not require any license to run the system. ∙ Flexibility Open source ERP systems provide more flexibility than proprietary ERP systems. In many cases, while implementing open source ERP system in a large company, a new interface is created to meet the business needs of the organization making it less complex in nature. ∙ Absolute Ownership Organizations have full control over the system they invested and the source code. Everything (both

22 3. ERP Systems

technical and domain information) related to open source ERP system is available online and further knowledge can be gained from open source communities.

Disadvantages ∙ Uncertainty The functionality, effectiveness and return of investment potential of the open-source ERP system is not guar- anteed by any major ERP vendor, nor is there any warranty. The company has to fully rely on the skill set if its own employees.

∙ Less professional support Part of the value of a commercial ERP system is made through support services. Big open-source projects have their own active communities which provide only limited support. The ERP development team will have to devote some of its resources to create an internal system support role.

∙ High risk There are other risk issues such as the viability of the software provider, the possibility that the open source software may be changed to a closed source in the future, or legal issues that may arise around the open source ERP system.

Although the acquisition of open-source system is usually free of charge, the overall implementation has many additional costs. A method of economic evaluation of an ERP system implementation is described in next section.

3.8 Total Cost of Ownership

The Total Cost of Ownership, usually abbreviated as TCO, is a financial estimate designed to help management to take financial decisions with full knowledge of the facts. Rather than just looking at the purchase price of a product or service, the TCO looks at the complete cost from purchase to disposal [17]. It summarizes the initial purchase price and other costs that incurred during the life of the product, such as service, repair, and insurance. Although, there is a high level of complexity in measuring the costs, as they can be both direct and indirect [7]. For example, whereas

23 3. ERP Systems software and hardware costs are tangible and easily quantified, the personnel costs are much more difficult to quantify. Management responsible for investment decisions often focus on the quantifiable, direct costs and let those decide the project’s budget. The TCO concept is very similar to product life cycle cost [18] and often uses 2 or 3 years as time horizon for estimation. According to Fisher [19], there is no generic TCO model and the cost estimation method should be customized to local conditions. In fact, many ERP suppliers and vendors have developed their own TCO models and methods of cost estimation in order to show customers the total and yearly costs of their systems.

3.8.1 TCO for Cloud Services Walterbush [20] presents an analytical model for the calculation of the TCO of Cloud Computing Services deployed in a public Cloud. His model’s focus is on the systematic identification and calculation of cost factors and also provides support to start-up companies not operating an internal IT infrastructure. His model is quite static in the manner of fix cost types and factors. In some cases, an additional cost factors might be added if necessary according to a company specifics. The possible cost types and factors are listed in Table 3.1. In ERP implementation process, TCO is mostly calculated to inves- tigate the costs and compare different scenarios in order to find the option offering the lowest totals. However, the purpose of TCO models is not to provide an identical image of reality but to deliver a simplified, abstract view. Thus, instead of including all relevant costs into the TCO analysis, the complexity is usually reduced by working on the basis of assumptions and by including only a limited number of carefully selected cost factors [20]. Next chapters will introduce the analytical part of this thesis, com- mencing with study methodology.

24 3. ERP Systems

Cost type Cost factors Strategic decision, selection of Expenditure of time (eot), con- services sulting services (cons), information for decision-making (inf) Evaluation and selection of ser- Expenditure of time (eot), con- vice sulting services (cons), information for decision-making (inf) IaaS charge Computing power (cp), storage capacity (sto), in-bound data transfer (inb), outbound data transfer (outb), provider internal data transfer (intdt), number of queries (que), domain (dom), SSL cer-tificate (ssl), licence (lic), basic service charge (bsc) SaaS charge Access to the service system (acc), user (use) Implementation, configuration, Expenditure of time (eot), port- integration and migration ing process (port) Support Expenditure of time (eot), support costs (sc), prob-lem solving (ps) Initial and permanent training Preparation time of internal employees (prept), participating time of internal employees (part), in-struction material (mat), external consulting ser-vices (cons) Maintenance and modification Expenditure of time (eot) System failure Loss per period (loss)

Table 3.1: Cost types and related cost factors [20]

4 Study Methodology

The main purpose of this study is to analyze IS used in a specific company, find development possibilities to overcome its issues and assess economical feasibility of such improvement. Costs, risks and benefits should be taken into account during evaluation of selected methods of improvement. Regarding this purpose, I developed a research framework to be able to create practical deliverable that might be useful not only for the studied enterprise, but also as a general knowledge for SMEs in similar situation. This chapter describes selected research method which should serve as a foundation for how to conduct the whole study. The case study is divided into three parts, taking advantage of Wallace’s model for ERP system adoption [11]: as-is state analysis, design of alternative development possibilities phase and economical evaluation phase.

4.1 Analysis

As stated in literature overview, business ecosystem of virtual companies is closely aligned with information systems used within the company. ERP systems should be considered as an inter-department artifact and thus evaluated from different perspectives. For this reason, I constructed the as-is state using the Enterprise Architecture Framework TOGAF 9.11, defining business ecosystem from business architecture, technology architecture and application architecture perspectives. This framework enables creation of high-level business ecosystem that is feasible to develop for SME and is sustainable in the long term period. All data for the as-is state analysis were gathered using two methods. The first method involved personal research of all information and documents provided by the company itself as well as data stored in the legacy IS. The second method was based on personal inter-

1. http://www.opengroup.org/subjectareas/enterprise/togaf

27 4. Study Methodology views with representatives from each department. Both methods were supported by my position as a member of IT department in studied company with almost unlimited access to all important resources.

4.2 Development Possibilities Design

Second part discussed an alternative development possibilities addressing requirements and issues discovered in previous analysis. I focused on selection of development approach which resolves all issues, complies with company requirements and brings other complementary benefits. In this part, I discussed and summarized possible development approaches. Subsequently, I performed a decision between open-source and commercial alternatives and concluded with functional fit evaluation of selected candidate.

4.3 Economical Evaluation

When a reasonable candidate was found, last part covered economical evaluation of its implementation. Since an assessment of the financial benefits is complicated for their intangible character, I analyzed proposed architecture through its cost of implementation. Calcula- tion was made according to the Walterbush model of Total Cost of Ownership for both current and proposed architectures. Outcomes from the evaluation were compared with given hypotheses from previous section. The validation of hypotheses together with valuable insights from the process of comparison may be potentially useful to other similar researches.

28 5 As Is State Analysis

In this section, I will introduce the current state of analyzed company for this case study. Analysis is divided into three perspectives: business architecture, application architecture and technology architecture. Complete review would have a vast extent, so this part excerpts only important and critical parts and processes related to the legacy IS. Last section of this chapter is devoted to a summary of all observed issues.

5.1 Company Introduction

Subject of this case study is a medium-sized e-commerce enterprise called Maternia s.r.o. with headquarters in Prague, Czech Republic. For potentially confidential information, name of all company’s e- commerce sites will remain anonymous in this study as requested by the company executives. It is one of the largest internet-based retailer in Europe focused on selling contact lenses and accessories. Company is purely e-commerce driven (virtual), meaning that all transactions are made via online store or affiliated network of partners. Turnover is rising annually with total of 598 millions CZK in 2015, which is approximately 32 % more according to 2014, which totaled 450 millions CZK. Turnover as well as number of employees classify the company as an SME. The company was established in 2007 as a Czech online store. Nowadays, it has separate retail websites for 14 countries in Europe - Czech Republic, Slovakia, Austria, Germany, Switzerland, Italy, Den- mark, Sweden, Spain, France, United Kingdom, Greece, Bulgaria and Romania. Company is constantly discovering new market opportu- nities to extend its European coverage and also offers international shipping to other countries in Europe. In terms of human resources, company has 65 employees located in Prague and Nova Bystrice, Czech Republic, distributed into several departments. Headquarters, Marketing, IT and Customer Support departments are based in Prague, whereas Nova Bystrice houses Pro- curement, Logistics, Warehouse and Sales departments. Two warehouses are owned by the company to suffice logistics requirements. First and biggest is located in Nova Bystrice and covers

29 5. As Is State Analysis shipments to majority of European markets. Second, much smaller is located in Vicenza, Italy, and handles approximately 40% of Italian orders. One more warehouse used to be in United Kingdom, but was closed for economical reasons. With its leading position in contact lenses market and rapid growth, company is under constant transformation from both managerial point of view and facilities requirements. Warehouse capacity is being doubled every year for the last 4 years, employees counts are also rising, mainly in IT and Customer Support departments. As a result of constant growth, the company is now looking for a new management approach and strategy. It’s major focus is on establishing solid processes to reduce its costs and administrative overhead, as well as increase both managerial and executive flexibility. On top of that, company is also considering to sell glasses, sunglasses and self-branded products. All these needs make the business an ideal candidate for proper ERP implementation, as it is expected to bring cost savings together with higher flexibility and agility of the business in long term perspective. In next section, I will briefly describe business architecture and processes currently established.

5.2 Business Architecture Analysis

For this analysis, I decided to describe architectures according to TO- GAF framework1. According to TOGAF business standard, a knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Application, Technology). Regarding IS analysis, e-commerce company is highly application-driven and its processes are tightly aligned with application requirements. Therefore, business and process analysis is the first activity that needs to be done. Object Management Group (OMG)2 states, that business architecture is the structure of the enterprise in terms of its governance structure, business processes, and business information. From the various structures for modeling the business requirements of the en-

1. http://www.opengroup.org/subjectareas/enterprise/togaf/ 2. http://www.omg.org/

30 5. As Is State Analysis

Figure 5.1: Organizational Structure

terprise the description of business processes (activities) seem to be the most appropriate. The core business of the company is built around retail with contact lenses and related accessories. According to the interviews with department representatives, I distributed the core processes into following groups: marketing, procurement, warehouse management, customer support and IT operations. Complete organizational structure is described on Figure 5.1. In following parts, I go through established departments in the company and introduce main functional dispositions and processes currently used. Besides, I have also classified several supporting groups of processes, such as: human resources management, maintenance of infrastructure, management of documents and records and internal assets management. Although these processes do not have a dedicated department, they are necessary for internal business requirements.

5.2.1 Marketing Marketing department encompass 7 employees, 2 of which are external contractors taking care of PPC3 campaigns and affiliate networks. The interviews concluded in these key processes:

3. Pay Per Click advertisement

31 5. As Is State Analysis

∙ Direct Marketing Planning, realization and evaluation of in- bound marketing strategies

– Email marketing – PPC campaigns – Search Engine marketing – Affiliate marketing – Display Advertising

∙ Price analysis Discovering competitors’ prices, segmentation of customers from affiliate networks, setting product prices

∙ Customers’ behavior analysis Examining customers behavior in e-shop, analysis of their interests, needs and fears

∙ Product management Keeping product data up to date and ac- cordingly to marketing goals, altering products data according to localization specifics

Nowadays, marketing plays a vital role in extremely saturated field of e-commerce business. Companies need a high flexibility and modern marketing tools to sustain in competitive environment with lowest customer acquisition costs possible.

5.2.2 Procurement Procurement department consist of 3 employees and their general re- sponsibilities are to search, select, contract, order, protect and evaluate goods and services required by business activities. Following processes are fulfilled by procurement department in the company:

∙ Suppliers management Establishing contracts with goods suppliers, negotiating goods prices and delivery due dates

∙ Logistics management Establishing contracts with logistic companies to cover European transport at lowest prices possible

32 5. As Is State Analysis

∙ Management of external services Handling cooperation with other third party services like payment gateways (PayPal, World- Pay etc.), marketing tools and other software used within the company

∙ Goods procurement Setting automatic propositions for goods, placing manual supply orders, managing stock levels

Procurement is a crucial department from economical perspective. High competition on many markets diminishes the prices and sustainable markup can only be achieved by lowest prices from suppliers.

5.2.3 Accounting Accounting department is partly detached in terms of information systems as it uses DUEL software (described later) to deal with legal compliance. Department consists of 4 employees and handles following processes:

∙ Payments management Processing and tracking payments, invoices, generating bank payments, handling currency exchanges

∙ Treasury management Forecasting based on sales, purchases and invoices

∙ Assets management Handling transactions for company assets

∙ Legal compliance Keeping track on governmental and law reg- ulations and ensuring full compliance

∙ Supplementary tasks Inventory value overview, taxes settle- ments

5.2.4 Warehousing Warehouse department is responsible for logistics and goods handling. Department involves 15 employees and I have identified following processes:

∙ Inventory handling Accepting goods, barcode scanning, quality checking, organizing warehouse, shipping goods

33 5. As Is State Analysis

∙ Orders handling Fulfilling orders, packing parcels, processing returns

∙ Supplementary tasks Handling communication with logistics partners, printing and organizing shipment documents, providing other departments with stock level and expiration dates information

All operations in warehouse tend to be optimized to suffice high workload. Warehouse staff dispatch 2000 packages daily in average and accepts and sorts several pallets of goods.

5.2.5 Customer Support Customer Support represents the most numerous department and consists of 20 employees. Each localized e-shop has its own country manager accompanied with customer care assistants. Key processes are following:

∙ Phone support Answering calls from customers and dealing with variety of issues

∙ Email support Processing e-mails and tickets from customers and resolving their issues

∙ Social media communication Publishing news and promotions, communicating with customers

∙ Localization tasks Translating information for localized content, e-mails and promotions, helping with local law compliance

5.2.6 IT operations IT department is responsible for internal technology assets, IT support and development of legacy IS. Department includes 4 in-house developers and 2 external contractors who take care of following activities:

∙ Application development Developing, integrating and fixing application components, optimizing e-shop for better performance and responsiveness, realizing marketing needs

34 5. As Is State Analysis

∙ Internal IT support Helping other company employees with IT related issues and tasks

∙ Assets maintenance Maintaining internal hardware and software resources

Purchasing, financing and warehousing departments are geograph- ically separated from the rest of the company departments. Informa- tion flow is handled via legacy IS and company instant messaging platforms described in following section, which focuses on software and services used within the company.

5.3 Application Architecture Analysis

To thoroughly understand ERP system requirements in studied company, next necessary step is an application architecture analysis. In this part, I will describe an as-is state of the legacy IS implementation as well as all connected services.

5.3.1 Legacy System Evolution Regarding the application-driven nature of the company, the very first software architecture was developed in 2007 when the company was founded. To minimize costs and leverage development skills of former founders, the whole system was built in-house including only bare business functionality: e-commerce application for customers with simple back-office functionality for tracking orders. As the company evolved and more complex business requirements arouse, more modules were implemented ad-hoc by the founders, who at that time also represented an IT department for the company. System was enriched of procurement capabilities to handle purchases from suppliers and kept inventory records to satisfy warehouse needs. This continuous evolution led to the current state of monolithic application running on a single server and handling all kinds of ERP related business processes, from order taking, warehousing, logistics, procurement, pricing, CRM and marketing, except for accounting and customer support applications (as described in previous section). E- shop subsystem is also tightly coupled within the whole architecture.

35 5. As Is State Analysis

The whole system is powered by obsolete Zend Framework 1.104, which is slightly customized to provide required functions and therefore restrained to be updated to any newer versions (current is 2.4). Framework follows basic MVC5 concept without any advanced princi- ples like message brokering or ORM6.

5.3.2 Components of Application Ecosystem As I already stated, the whole application is monolithic and does not provide an easy way of modularization. However, several BoB7 services are connected to stay up-to-date with latest business tools. All such components are hard-coded into the system by company developers. Complete application ecosystem can be seen on Figure 5.2. In next paragraphs, I will describe all elements of application architecture.

Accounting Software Accounting department use DUEL8 software that helps to keep track of all invoices as well as follow all governmental and law obligations. Cooperation between legacy IS and DUEL is one-way only, based on automatized invoice export into the accounting software. Any systematic reporting, analysis and other data regarding accounting processes must be therefore accessed via DUEL software. All accounts receivable are send to the accounting department manually in ad-hoc manner.

Customer Support Services Customer Support department takes advantage of two information systems: ZendDesk9 and Daktela10. Both systems are completely de-

4. https://framework.zend.com/ 5. Model View Controller 6. Object-relational mapping 7. Best of Breed 8. https://www.jezeksw.cz/duel/ 9. https://www.zendesk.com/ 10. https://www.daktela.com/

36 5. As Is State Analysis

Figure 5.2: Legacy IS ecosystem

tached from the legacy IS. ZendDesk is a primary software to handle tickets and customers emails. Voice calls are covered by Daktela service that provides VoIP communication and related statistics. All reports about customers’ satisfaction and staff performance must be accessed directly in the particular system.

Marketing Services Marketing services integrated for back-office operations are KlipFo- lio11 and several Google family products, such as Google Analytics12 and AdWords13. KlipFolio is a primary tool for data dashboards and business analysis. It connects directly to the legacy IS database (described later) to digest its data. Google Analytics provide on-site user

11. https://www.klipfolio.com/ 12. https://www.google.com/analytics/ 13. https://www.google.com/adwords/

37 5. As Is State Analysis behavior analysis and conversion tracking. AdWords is used for PPC advertising.

Project Management Service Project management and agile work approach are handled via Trello14 service. Trello is the visual collaboration tool, where several boards are established for company’s projects and departments. Each board is further organized by project or work-flow requirements. Trello also keeps majority of related documents.

Internal communication Services Company use Slack as a primary real-time communication service. Communication is divided into several channels and a new can be created for any purpose. Company is subscribed for free version, which allows to log up to 10 000 messages in history.

E-Shop Subsystem All e-shops and CMS15 operations are integrated into ERP functionality and run on one platform, where every country has its own localized GUI16. Departments like Customer Support or Marketing can easily filter orders, customers, campaigns etc. for one specific country. Sys- tem can also use data for reports from all countries together as they all share the same database layer. This approach of shared code for all e-shops simplifies company growth to other markets, although, on the other hand, brings many complications in terms of localization discrepancies. For instance, modifications tailored for different law requirements must beeither reflected to the other countries as well, or hard-coded specifically for each county, which often cause confusion and unexpected system behavior for developers. Legacy IS also provides different GUI for suppliers, pick-up point partners and back-office (administration).

14. https://trello.com/ 15. Content Management System 16. Graphical User Interface

38 5. As Is State Analysis

∙ Suppliers have the ability to review supply orders and due dates

∙ Pick-up point partners can track parcels sent to their POS17 and see commissions

∙ Administration offers all back-office functionality further divided by specific privileges to perform tasks in particular departments

The whole system is under continuous development and new features are being developed as needed. At the same time, old and obsolete features are being deeply refactored18 due to inevitable technological debt, which makes the application core increasingly unstable and unpredictable. Monolithic architecture and single-server provision often causes severe issues in whole IS when even a dull developer’s mistake is made i.e. in e-shop front-end module. On the other hand, in comparison with traditional ERP systems, legacy IS features some competitive advantage tools, such as price comparison engine and collaboration tool for opticians. Price comparison tool helps to match product prices against company’s main competitors. Such data are used to setup most beneficial markups for products. Opticians subsystem manage offline marketing channel by cooper- ating with local opticians, who based on individual agreement offer company’s products to their customers in exchange for revenue share. Although these functions are above the general ERP system functionality, they help the company to stay on the edge of the market. In next section, I will describe the technology behind the legacy IS.

5.4 Technology Architecture Analysis

The last perspective that needs to be analyzed is technology architecture. In this part, I will introduce all hardware and technology assets used within the company and to power application systems.

17. Point of Sale 18. Refactoring is a process of restructuring existing computer code

39 5. As Is State Analysis

Figure 5.3: Linux server setup

The hardware infrastructure comprises of two server machines hosted as a service (IaaS) by 3rd party provider Web4U19 and employees’ computers. Both servers are located in Czech Republic and fulfilled by SLA20 with granted reliability and hardware performance. Both servers are managed, meaning that the service provider is responsible for system administration.

5.4.1 Linux server First server is powered by Linux operating system and serves as a main hardware for the whole legacy IS. According to the application architecture needs, this machine runs Apache server with PHP inter- pret module, MySQL database as a main storage engine for all data and Memcache server to improve application performance. Server setup can be seen on Figure 5.3. This machine is fully responsible for all business operations and thus brings a high risk of data loss or operational outage. Any en- vironmental issues or external attacks can bring the whole system down. However, this issue can be perceived as a common risk for any technology-driven (virtual) company. Third-party company provider

19. https://www.web4u.cz/ 20. Service level agreement

40 5. As Is State Analysis was chosen not only to alleviate this risk, but also to lower the costs implied from in-house (on-premise) server management. However, another critical factors exist, one of which is an absence of any backup or slave machine for service outage situations. Therefore, the whole monolithic IS architecture is still very vulnerable to any service malfunction.

5.4.2 Windows server

Second server runs Microsoft Windows and powers accounting software DUEL. As well as for primary IS server, no backup server is maintained. On the other hand, risk exposed in critical situations is dramatically lower as only accounting service may be affected. Besides server machines, all company employees, who require a computer to support their daily routine tasks, are provided with a company laptops. These workstations are mainly Microsoft Windows systems with several exceptions running Apple OS X systems. All computers are up-to-date with latest versions of software to prevent risks in forms of security or compatibility. The topology of the network is scattered. All branches have their own networks maintained by internet providers. However, cloud hosted IS does not require any special conditions and system can be accessed from any place with sufficient internet connectivity. In next section, I will summarize discovered issues from business, application and technology architecture perspectives.

5.5 Observed Issues

While being a part of legacy IS development team, the company ran into several less or more severe incidents. These incidents were mainly caused by insufficient application and technology architecture, but some of them also reflected poor design of business processes. Following paragraphs depicts the most significant issues partly mentioned in previous as-is analysis. For better clarity, I have divided all problems into groups described in following paragraphs.

41 5. As Is State Analysis

Mismatched Functionality Firstly, business processes in studied company are evolving faster than the legacy IS can support. As a result of continuous enhancements, System is becoming slow and difficult to use. Also, every improvement brings a high risk of faulty behavior as it usually involve big refactoring. This group includes two kinds of problems: missing functionality and malfunction of existing components. In terms of missing functionality, I have identified these issues:

∙ Missing support for other product types - legacy system can only work with contact lenses and accessories, product management is not flexible enough to handle other business units

∙ Missing HR and Asset management systems - all information about employees and internal assets are stored in spreadsheet files or not at all

∙ Missing document management system - all invoices and other documents are kept personally and shared ad hoc without any central repository

∙ Missing business intelligence reporting - most of executive reports are made manually from MySQL database by CEO

∙ Missing order fulfillment fraud reporting - company is not able to detect and review frauds during the order fulfillment process

∙ Insufficient inventory data sharing - employees (mainly customer support) are not able to view complete information about products in a warehouse like expiry date and have to ask the warehouse staff via internal communication tools

I have also identified numerous code malfunction. Smaller problems appeared on daily basis, while the most critical issues were following:

∙ Invalid inventory records - system occasionally presents wrong numbers about stock levels, which causes several side effects.

42 5. As Is State Analysis

Mainly, an automatic supply ordering is faulty as it has wrong input data. Also, wrong information about items on stock is presented to the customer support and customers as well. ∙ Inability to pair incoming goods with supply orders - suppliers for various reasons tend to send more products than ordered, which also amplifies previous issue. Such malfunction results in excessive stock blocking financial dispositions of the company. ∙ Side-effect bugs - many issues arise on daily basis due tohigh complexity of the code Currently, legacy IS requires constant maintenance of at least 5 hours a day of a developer time. New features can be introduced only with help of the others.

Expensive Bug Tracking Constant evolution of the system also creates very complex and unpredictable environment. Application bugs are hard to track and fixing them often cause cascade effect resulting in another malfunction. New developers are often unable to participate in such operations.

Slow Development Insufficient flexibility and complicated development of the systemis harmful for overall business innovation and growth. Business reports take time to develop which considerably slows down any executive decisions. As stated above, development of new features often cascades in several bugs in other parts of the system. As a result, thorough code review is needed prior to any version release. Another factor is missing documentation, which causes a lot of duplicate code as developers are not aware of already included features.

Single Server Architecture Single server architecture together with monolithic application presents a huge risk for any application-driven company. Hosting service outage stops all business processes including e-shop as a point of sale.

43 5. As Is State Analysis

Also, latency of the system can be affected when any component of the system is under extensive load. As described in section 5.4, one Apache server is powering the whole monolithic application. In case of crash of any component, the whole system is down. PHP interpreter errors can be especially dangerous, as they make the whole system inaccessible, even though the problem is related to e.g. a mistake on e-shop product detail page.

Insufficient Security Company is not paying attention to security measures until any severe incident occurs. Constantly evolving system glued by many components from various developers has many vulnerabilities to both internal and external data leaks.

Unfriendly user interface Although the e-shop front-end is following all modern web development approaches, back-office administration lack of user friendly interface. Each functionality has different appearance and different behavior conventions. Such inconsistency leads to long lasting confusion for new employees as well as significant workload for IT support.

Missing Test Suite Even the most critical parts of the system are not covered by automatized testing suite. New releases are pushed to the production server with no assurance or proof of compatibility and harmlessness. During my cooperation with the company, it has happened many times that a new release caused a system crash, which took several minutes to fix and stopped the business from generating profit.

Missing Interfaces Another result of continuously developed system is an absence of any modularization capability and API21. Thus, integrating third- party components (e.g. new delivery company, mailing service) is

21. Application Programming Interface

44 5. As Is State Analysis

complicated and brings inconsistency to the system, as every developer finds its unique way to achieve successful integration. Furthermore, this issue also affects the extensiveness of the system as a whole.

Inefficient Data Model Company data stored in the MySQL database lack of good design prin- ciples and normalization, which results in plenty of data duplicates and inefficient usage. Developers get stuck on which data is current and which is obsolete.

High Maintenance Costs All above issues dramatically contribute to overall costs of maintenance and operation. According to the theory, high costs can be referred to the late stage of legacy IS life cycle, where customization and complexity overhead causes more troubles than benefits.

5.6 Conclusion

This chapter summarizes the current state of legacy IS and its drawbacks. In first part, I analyzed studied company from three perspectives: business architecture, application architecture and technology architecture. These perspectives served as a foundation for analysis of major issues of the system. These issues were described in second part of this chapter. In next chapter, I will evaluate possibilities of a legacy IS improvement.

6 Development Possibilities

In previous chapter, I have identified several drawbacks of the legacy IS. Some of them concern technical problems, other relate to business needs that are not satisfied. In this chapter, I discuss and propose possible solutions to resolve these issues.

6.1 Discussion on Possible Development

According to the literature overview, implementing an ERP system is extremely challenging because it not only requires redesign of business processes, but also a change of perception how people approach their jobs. In general, companies start to consider an ERP system alternative when their legacy systems start to affect their financial performance. However, due to large capital investments, not every company has the will or resources to replace their legacy systems [2]. Therefore, an ideal way to approach this problem is to find a compromise that diminishes the costs as well as maximizes the benefits of such change. From broader perspective, I consider two approaches to resolve identified issues of legacy IS:

∙ Re-implement/enhance legacy ERP system with better application architecture

∙ Acquire a third party or open-source software to replace or improve current system

Regarding the extent of legacy IS problems from both application and data perspective, re-implementation will better be done by start- ing from scratch rather than trying to refactor the current state. Many discovered issues relate to bad code base, missing features and inadequate application architecture. Due to high complexity of ERP systems in general, such option will be impossible without a great amount of both financial and human resources. As stated in literature overview of this thesis, ERP system should not be developed in-house unless it is in the primary focus of a business or competitive advantage asset. For this reason, re-implementation

47 6. Development Possibilities approach will be skipped as this thesis is trying to find an alternative solution. Instead, I decided to focus on finding an alternative ERP system that could possibly substitute the legacy IS or its part in a feasible way. In following sections, I will evaluate an alternative architecture in form of acquisition of ERP system that is proofed by other companies and kept up-to-date by a vendor or community.

6.2 Open-source vs Commercial Alternative

Obviously, there is not a one-size fits all ERP system for an e-commerce company. Many variables must be considered before making a choice. A good previous understanding of the company is necessary to avoid implementing an inadequate solution and spending a lot of monetary and human resources. From ERP system acquisition perspective, I considered two possible options: ∙ Purchase a commercial solution for fixed or recurring price ∙ Integrate an open-source solution supported by community In commercial market, SAP is the most popular for large enterprises along with its main competitor Oracle. The market leaders for SMEs are Sage and Microsoft Dynamics. However, according to Soft- wareAdvice.com1, the market is very fragmented for SMEs as small vertical solutions stand for more than 60 % of the market size. Regarding these solutions, currently biggest movement is happen- ing in the open-source space. Most widely implemented solutions are Odoo (formerly OpenERP), OpenBravo, ERPNext and iDempiere (extended ADempiere). Every solution slightly differs in provided functionality. Generally, IT departments appreciate that popular open-source ERP systems have higher quality, as many independent developers have looked at the code, criticized it, and contributed [21]. Besides, open-source code tends to have clean and well maintained architecture to facilitate the contribution from developers.

1. http://www.softwareadvice.com/erp

48 6. Development Possibilities

As already stated in section 3.7, open-source is often built on other open-source projects and database engines, so it does not reinvent the wheel, which can often be seen in commercial systems. Open-source ERP systems have valuable advantages favorable for studied company. To name the most important, they are much cheaper to obtain, provide big supporting community and offer third-party extensions from independent developers to alleviate customization process (see section 3.7). According to the as-is state analysis in chapter 5, studied company has its specific characteristics and rather unique business units (contact lenses), which require system customization above the standard retail industry. In this case, open-source solutions provide much more flexibility with no additional charges by vendor and might benefit from community customization examples. All these factors support a decision for an open-source system. Not to mention, studied company seeks to minimize implementation costs as well as take advantage of in-house development team. Although, some weaknesses also exist in the open-source approach, such as risk of viability or uncertainty (see section 3.7). However, in case of studied company, benefits of open-source choice vastly prevail listed drawbacks. In next part, I will discuss selection of an open-source alternative for legacy IS.

6.3 Alternative System Selection

After making a decision to implement an open-source system, a particular product selection must be performed. For this part, I followed a survey conducted by Saleh Al-Saleem et al. [22], who examined the most popular open-source ERP systems currently in the market. He took following factors into account to do the comparison:

∙ Features and Business Applications ∙ Market Position ∙ Productivity, Ergonomy and Ease of Use ∙ Customization and Flexibility

49 6. Development Possibilities

∙ Technical Quality

∙ Total Cost of Ownership

Table 6.1 shows a result of a comparison between popular ERP systems. Top ERP systems like SAP and Microsoft Dynamics NAV were considered to demonstrate open-source capabilities compared to the commercial systems. Results, based on a feedback from around 4319 users, clearly show that Odoo stands on top compared to its competitors.

User Feedback in percentage Factor name Odoo OpenBravo NAV SAP Features 84.8% 29.8% 33.52% 78.9% Market Position 47% 38.75% 94.75% 100% Ease of Use 82.6% 41.6% 48.8% 74% Customization 85.2% 34.6% 51.8% 69.6% Technical Quality 78.6% 54.1% 56.1% 75.3% TCO 96.16% 46.83% 42.33% 62.83%

Table 6.1: Comparison between open-source systems by Saleh Al- Saleem [22]

Based on this research and its results in factors like customization, technical quality and TCO, which are of biggest importance for the company, next section will evaluate Odoo as an alternative system.

6.4 Odoo ERP Evaluation

Odoo has all the advantages offered by open-source ERP systems such as less expensive implementation, flexibility, absolute ownership, quality assurance and easily upgradable environment. According to community statements, Odoo source code is easy to maintain, clearly structured and easily extendable. Most of the customization is made through GUI without touching the source code, usually by installing a new module or configuration made via inbuilt

50 6. Development Possibilities wizards. According to statistics provided in Odoo documentation, Odoo is receiving more than 1,000 downloads a day, has over 300 certified modules with more than 3,000+ developed together withits worldwide open source community. When version 8.0 (latest is 10.0) was introduced, Odoo has been enhanced by features like Content Management System, an integrated e-commerce for a robust online transaction service and business intelligence efficient project management along with traditional ERP system features. These features, however, might not be needed. As I already stated, there is no universal solution for SME and general ERP system aspects (i.e. factors in Al-Saleem’s research) cannot be the only indicator for ERP system selection. Most importantly, I had to consider functional fit to cover all required processes in studied company. Therefore, I thoroughly compared Odoo capabilities with business requirements identified in business architecture analysis. Complete list of Odoo features for this comparison can be found in documentation2. In spite of the fact that some provided features may not be needed for studied company, after a thorough comparison, Odoo resulted to be a perfect fit as it covers all ERP functionality currently required, except the functionality beyond the ERP environment, like competitive advantage features. This fact should not be a surprise as ERP capabilities are designed to cover majority of standard retail processes. Based on this reinforcing fact, I will conclude Odoo as a replacement candidate for legacy IS in this study. Proposed implementation architecture will be covered in next part.

6.5 Proposed Architecture

Most of used third-party services described in section 5.3 or their functionality are already included in Odoo. However, it is evident that Odoo cannot be a jack of all trades and some legacy services must persist. Proposed architecture designed for studied company is shown on Figure 6.1. All functionality beyond the ERP capabilities, like competitive advantage tools and e-shop subsystem should be detached from legacy

2. https://www.odoo.com/documentation/10.0/ 51 6. Development Possibilities

Figure 6.1: Proposed Alternative Ecosystem

IS in form of self-sufficient modules (or services). In spite of the fact that Odoo provides an e-shop module too, current e-shop is highly optimized and it is a cheaper and less time consuming option for the company. These services will be connected with Odoo ERP system via API already contained in Odoo installation. Though, Odoo must be enhanced to accept information from such services. In my opinion, this ecosystem will preserve the best of breed and necessary parts of legacy IS while still providing enough flexibility and stability for new ecosystem in form of service oriented architecture. Ecosystem will have a solid foundation orchestrated by Odoo system and enhanced with all appreciated features from legacy IS.

6.6 Conclusion

In this chapter, I have discussed possible development of legacy system. Open-source alternative resulted to be the best option according to the discovered issues and literature overview suggestions. For this reason, I examined commonly used open-source ERP systems and their performance from several factors. Based on comparison

52 6. Development Possibilities

study conducted by Saleh Al-Saleem et al., Odoo (former OpenERP) resulted to be the one of the top open-source ERP systems currently available in the market. It prevailed its competitors with great margin in most aspects. After a thorough analysis of Odoo functional fit, I have selected this system as an alternative candidate for this study. In next chapter, I will estimate its economical burden in form of total cost of ownership (abbreviated as TCO).

7 Economic Evaluation

To determine financial value of proposed architecture implementation, I decided to perform an economical analysis in form of Total Cost of Ownership calculation described in the literature overview, section 3.8.

7.1 Total Cost of Ownership for Odoo

It is always preferable to have a cost analysis before launching an ERP implementation project. A proper TCO analysis puts company in a better position to make a decision, set goals and deadlines. This study performs mathematical analysis using a TCO model designed by Walterbusch [20]. Although this model is mainly focused on SaaS1 solutions, it is quite flexible, so I adapted its calculations for company environment and software architecture. As I wanted to involve all stages of ERP implementation, I decided to do the calculation for 3 years ERP life cycle period, which is also recommended by provided literature. For this period, model distributes expenses into 4 stages: Initiation, Evaluation, Transition and Operation.

7.1.1 Initiation Phase First group comprises of Strategic Decision and Selection of Services. In this study, term Services means IaaS in form of application hosting and SaaS in form of Odoo software. This group calculates with expenditure of time of the employees, costs of consulting services and costs of materials, such as scientific literature and market studies on which the decision is based (Formula 7.1).

str str str str C = Ceot + Ccons + Cin f

Figure 7.1: Cost of strategic decision, selection of services [20]

1. Software as a Service

55 7. Economic Evaluation

The first determining factor for the Cstr is the expenditure of time str str Ceot given by the Formula 7.2. peot,m represents hourly salary of the str employees, aeot,m total hours of time for m employees.

str str str Ceot = ∑ peot,m * aeot,m

Figure 7.2: Cost factor of expenditure of time [20]

In studied company, Initiation phase tasks involve CEO and IT department as main actors. CEO is in role of project manager and IT department handles technological consultancy. In emergency situations, external consultant may be hired. Hourly wages vary as well as total time required. Exact calculation is provided in table 7.1. Employ- ees’ salary includes all corresponding taxes. The average hourly rate for consultancy service was determined according to Internet research for Odoo consultants in Prague, Czech Republic.

Employee Hourly salary Total hours Cost CEO 1000 CZK 10 10 000 CZK IT staff 280 CZK 16 4 480 CZK External consultant 1200 CZK 1 1 200 CZK Total 15 680 CZK

Table 7.1: Initiation costs

Odoo is well documented with all required materials provided online for free. Vendor website also offers community forum with many participants and useful information. For that reason, I do not count with any costs related to required materials. Expenditure of time for studies is included in overall time for CEO and IT department. The number of hours spent on the project reflects the hours spent analyzing data and synthesizing outcomes in form of candidate solutions. This can be also considered as the time spent in the as-is analysis of this study.

56 7. Economic Evaluation

7.1.2 Evaluation Phase

The cost of Service provider evaluation and selection is determined by the same cost factors as Initiation phase: amount of time that and employees invest in this process and on the costs of external consultants that support this process. The only relevant factor for this phase in studied company is the cost of CEO’s time. He is the only personnel with decision power over the selection. The total cost of evaluation and selection is calculated in following table 7.2.

Employee Hourly salary Total hours Cost CEO 1000 CZK 4 4 000 CZK Total 4 000 CZK

Table 7.2: Evaluation costs

The cost of IaaS Charge is formed by monthly based hosting provider fee. This fee also includes any server related maintenance. Odoo can be installed either via packaged installers or Docker image. Both methods are applicable to Linux server. To take advantage of current hosting provider (Web4U), I decided to stay with managed virtual server. For such option, monthly fee is settled on 9400 CZK (incl. VAT) per month with 2 year contract. This fee covers all hardware related requirements including PostgreSQL database. For security and performance reasons, Odoo recommends to have two physical environments. Thus, server is configured to be twice as powerful as needed by Odoo requirements to handle both virtual machines. Detailed hardware requirements can be found in Odoo documentation. The cost of SaaS Charge is based on service price for ERP provision. Odoo is offered as SaaS solution with monthly fee or self hosted open- source application. As stated in previous chapter, this study compares self hosted option. Therefore, SaaS service cost can be omitted. The total cost of service charges is calculated in following table 7.3.

57 7. Economic Evaluation

Service Price per Period Months Cost Saas (Odoo) 0 CZK 36 0 CZK IaaS (Hosting) 9 400 CZK 36 338 400 CZK Total 338 400 CZK

Table 7.3: Service costs

7.1.3 Transition Phase

The total cost of Transition is dependent on the expenditure of time and porting costs to fulfill the transition. These tasks include implementation, configuration, integration and migration of services and data. Walterbush model considers porting process as a charge related to data transfer. Such charges are irrelevant for this study and are therefore omitted. Instead, I count with time required by IT department to migrate data between legacy IS and Odoo instance. The implementation process is performed by internal IT resources. Implementation is based on initial application setup and modules installation according to the selection from Initiation phase. Odoo implementation guide states, that customization is considered to be 60 % of the total transition costs. Also, as discovered in as-is state analysis, some modules must be developed to maintain communication between legacy components and Odoo instance. Development expenditure of time is doubled to involve missing knowledge of a new environment. Configuration is the most important part. It includes adaptation of Odoo to currently established processes in the company. All views on data should try to reflect present habits of company employees to minimize confusion. Also, all current connections to delivery, payment and other company partners must be established. External consultant is considered to follow the best practices and ensure maximum efficiency. Migration process requires IT developers to create data adapters to ensure seamless data transfer. Expenditure of time must be also increased of time spent validating the data.

58 7. Economic Evaluation

The calculation of implementation, configuration, integration and migration for the ERP system is provided in following table 7.4.

Phase Employee Hourly salary Hours Cost Implementation IT staff 280 CZK 40 11 200 Configuration IT staff 280 CZK 120 33 600 Customization IT staff 280 CZK 540 151 200 Migration IT staff 280 CZK 200 56 000 Consultant 1 200 CZK 40 48 000 Total 300 000

Table 7.4: Implementation, configuration, integration and migration costs

7.1.4 Operation Phase Operation costs are calculated as a sum of expenditures for support, training and maintenance. According to the model, Support depends on the costs of support services via telephone, e-mail, ticketing systems or chat during the whole system life cycle. In studied company, support is considered as expenditure of time to browse the Internet for solutions to encountered problems. I decided to count a fixed amount of 2 hours per week. Also, external consultancy might be needed and therefore I included fixed monthly price for first 6 months of operation. Total costs of support for 3 years are in following table.

Employee Hourly salary Total hours Cost IT staff 280 CZK 98 27 440 CZK Consultant 1 200 CZK 12 14 400 CZK Total 41 840 CZK

Table 7.5: Support costs

For ERP system implementation, Training can be further subdi- vided into two groups. First covers internal training of company mem-

59 7. Economic Evaluation bers, second accounts for external training needed to provide enough knowledge to company training coaches. There should be several both external and internal training sessions. For this study, I count with 4 hour training for every employee of the company plus 4 hours of external coach training for IT department. Calculation formula is shown below (7.3):

train train train C = ∑ Cint + ∑ Cext

Figure 7.3: Cost factor of training

External training is calculated by adding costs of external consultants to expenditure of time for all participated employees. Materials are available online and therefore considered as free of charge. Total estimates are stated in following table 7.6.

Employee Hourly salary Total hours Cost All employees 180 CZK 240 43 200 CZK External coach 1 200 CZK 4 4 800 CZK IT staff 280 CZK 12 3 360 CZK Total 51 360 CZK

Table 7.6: Training costs

Maintenance and modification depends on the expenditure of time for general maintenance and modifications made during the implementation of the service. Properly configured system should require minimum effort to maintain. Some modification might still be needed in form of e.g. new delivery company contract, new market or new products introduction. Therefore, maintenance is derived as expenditure of time for IT department throughout the system life cycle. This study considers fixed amount of 2 hours per week plus 2 hours per month of CEO revision. Following table shows the calculation (7.7).

60 7. Economic Evaluation

Employee Hourly salary Total hours Cost CEO 1000 CZK 72 72 000 CZK IT staff 280 CZK 294 82 320 CZK Total 154 320 CZK

Table 7.7: Maintenance and modification costs

7.1.5 Additional Costs

Another costs will occur in terms of conceptual system failure. The con- sequences of a system failure strongly depend on the inter-dependencies of services and business processes and their relevance to the business goals [20]. Thus, for ERP implementation, possible cost factor is mainly the loss of productive working time. Productivity loss is highly variable for every department of studied company. IT department, marketing and procurement tasks are based on mid-term goals with less urgency and thus the efficiency lack will not have as severe impact. I estimated 20% productivity loss for the first month. On the other hand, Warehouse and Customer Care departments have short process times and require maximum efficiency of ERP functions to minimize response times and delays for incoming orders. For Customer Care department I count with 25% loss caused mainly by longer order information retrieval. For Warehouse department I estimate about 40% loss of productive working time for the first month and 20% for the second. All costs are calculated in following table 7.8. Estimate is based on number of employees multiplied by number of hours per month. Productivity losses are rather high. For some departments, they should be compensated either via overtimes of employees or additional support in terms of new personnel. TCO is concluded as a sum of all phases considered in this calculations for period of 3 years. Exact numbers are provided in table 7.9. In this analysis, I include only necessary expenses regarding ERP system implementation. Many hidden and supplementary costs may arise during actual execution, like transport costs, accommodation etc.

61 7. Economic Evaluation

Department Hourly salary 1. month[h] 2. month[h] Cost Marketing, 250 CZK 320 0 80 000 CZK Procurement Warehousing 100 CZK 960 480 144 000 CZK Customer Care 180 CZK 800 0 144 000 CZK Total 368 000 CZK

Table 7.8: Productivity loss costs

Phase Total Initiation costs 15 680 CZK Evaluation costs 4 000 CZK Service costs 338 400 CZK Transition costs 300 000 CZK Support costs 41 840 CZK Training costs 51 360 CZK Maintenance costs 154 320 CZK Losses costs 368 000 CZK Total 1 273 600 CZK

Table 7.9: Sum of all costs for Odoo implementation

Also, it is important to treat provided totals as an estimate rather than final figures. Real counts may and most probably will be different. However, estimate should be sufficient for strategic decision about ERP implementation. In next part of this chapter, I will estimate TCO for legacy IS.

7.2 Total Cost of Ownership for Legacy System

Legacy IS can be similarly evaluated using the Walterbush model. However, most of the costs can be omitted as custom made system did not involve costs spent on project initiation.

62 7. Economic Evaluation

As well as for Odoo implementation, service charges include IaaS cost. For legacy IS, it is formed by total cost of hosting provider per month. As I already described in section 5.4, company uses two servers provided by Web4U. Linux server costs 9 000 CZK in average per month, Windows server costs 6 500 CZK in average per month. Exact calculation is provided in table 7.10.

Service Price per Period Months Cost IaaS (Linux) 9 000 CZK 36 324 000 CZK IaaS (Windows) 6 500 CZK 36 234 000 CZK Total 558 000 CZK

Table 7.10: Legacy IS Service costs

Transition phase can also be skipped as there is no transition for matured ERP system currently in operation. Biggest expenses should be anticipated in Operation phase. Al- though support and training expenses are not relevant, maintenance and modification are considered as major financial burden. AsIde- scribed in section 5.5, legacy IS currently requires almost one full-time developer to deal with maintenance and fixing of incoming issues. Fixed amount of 5 hours per day is counted. Besides maintenance, CEO participation is needed to observe alignment of legacy IS with business processes and analyze possible modifications and improvements. Another developer is also needed to implement such functionality. For this study, I estimate 1 hour per week of CEO work and 5 hours per week for improvements implementation. Exact calculation is provided in table 7.11.

Work Hourly salary Total hours Cost Maintenance 280 CZK 1225 343 000 CZK Management by CEO 1000 CZK 49 49 000 CZK Improvements 280 CZK 245 68 600 CZK Total 460 600 CZK

Table 7.11: Legacy IS Maintenance and Modification Costs

63 7. Economic Evaluation

Phase Total Initiation costs 0 CZK Evaluation costs 0 CZK Service costs 558 000 CZK Transition costs 0 CZK Support costs 0 CZK Training costs 0 CZK Maintenance costs 460 600 CZK Losses costs 0 CZK Total 1 018 600 CZK

Table 7.12: Sum of all costs for legacy IS operation

Last group of productivity loss expenses can be also omitted as all employees are well used to the legacy IS and its interface. Confusion of new employees might be applicable, but is hard to calculate for variant hiring rate. Total costs of legacy IS are summarized in table 7.12.

7.3 Conclusion

In this chapter, I leveraged Walterbuch’s model [20] for calculation of TCO. This model was slightly modified for better fit to ERP systems calculation. Evaluation includes all stages of ERP implementation, such as Initiation, Evaluation, Transition and Operation of system. This model was used to determine financial burden of both Odoo implementation and current legacy IS. TCO for Odoo implementation results to be more than 25 % higher than running costs of legacy system. Hovewer, it is important to keep in mind that these calculations are only estimates used for more objective decisions about ERP system implementation. Real numbers will be different, however, they cannot be distinguished before actual execution.

64 8 Evaluation and Conclusion

ERP system development is a complicated process and involves both technical and management aspects. Purpose of this study was to describe and present roles and challenges of ERP system implementation in a specific company and discover its development possibilities. In this chapter, I will provide the evaluation of discovered alternatives and their feasibility for the company in accordance with presented hypotheses (section 1.3). The last section will conclude this study and discuss related future work.

8.1 Hypothesis Evaluation

As-is analysis indicates that the most of the issues concern technological perspective of the legacy system. Majority of problems is related to technological debt in form of hard maintenance, missing features and faulty functionality. However, minor problems associated with business processes have been discovered as well. Proposed system architecture is designed to overcome such issues. In essence, flawed and insufficient ERP functionality is replaced with open-source Odoo system. Legacy monolithic architecture is broken into e-shop module and competitive advantage services, which, together with other external services, are interconnected with robust, flexible and actively maintained ERP system. Such approach brings higher flexibility and stability of the overall system. To address the feasibility of such alternative, this study provides a TCO calculation to compare both legacy IS and new architecture economical burden. According to the literature overview, I calculated costs for 3 year period to include all stages of ERP system implementation. Alternative architecture is estimated to cost approximately 1.2 mil- lion CZK, which is about 25 % more than estimated TCO for legacy IS. Thus, the H1 hypothesis that implementation of open-source ERP system should bring a cost reduction for the company is false. Although, it is essential to keep in mind that these figures are estimates based on 3 years period.

65 8. Evaluation and Conclusion

On the other hand, Odoo system provides company with appreciated features like easy management reporting, HR management, inbuilt accounting, document management and project management tools along with other useful modules. These capabilities support company flexibility and introduce missing processes to facilitate company growth. Thus, the H2 hypothesis stating that open-source ERP system would benefit company through improved flexibility and scalability is true. As a result, the general hypothesis H0 is fulfilled only partially, meaning that company should benefit from open-source ERP system implementation, but it must anticipate financial investment to reap the benefits. It is not possible to achieve short-term cost reductions with an ERP system, however, the savings should be realized over the long-term. In another words, companies should consider ERP software as a strategic investment for growth without a short-term payback.

8.2 Conclusion

If companies had unlimited resources and infinite time, all projects would be feasible [23]. However, in the real world business, there are problems of scarcity of both time and resources. Companies are constantly faced with a wide array of possible investment alternatives and forced to choose one project over the others. Also, most projects must be developed within the time constraints and under the limited budget. The primary focus of this study was to present and describe information system roles and issues in specific company, design development possibilities and evaluate their feasibility through economical analysis. In literature overview, I have briefly introduced e-commerce business model and its requirements in relation to ERP systems. Also, I have examined classification, distribution and key components of such systems. Lastly, it was important to introduce ERP system implementation life cycle together with its economical evaluation method called Total Cost of Ownership, which is used for alternatives comparison in this thesis.

66 8. Evaluation and Conclusion

Study was commenced with thorough analysis of an in-house developed information system currently established within the company. Because virtual companies are tightly aligned with their information systems, the analysis was structured according to a business architecture framework to capture all aspects of an IS within the company. Selected framework defines three perspectives of analysis: business architecture, application architecture and technology architecture. Subsequently, I summarized all issues of legacy system discovered in each perspective. Although majority of issues were related to poor application architecture and so called technology debt, afore- mentioned alignment caused that several problems were reflected to the company processes as well. Development possibilities were designed to satisfy several requirements. Company needed a financially efficient solution which pre- serves competitive advantage functionality from the legacy system. As all major issues were related to ERP functionality, I discussed alternative approach on development and decided to find a replacement in form of third-party ERP system. After a comparison of both commercial and open-source alternatives, I proposed a service oriented approach that integrates flawless parts of legacy system with flexible and well-maintained open-source ERP system Odoo. Economical perspective of this comparison was fulfilled with calculation based on Total Cost of Ownership. I followed a modification of Walterbush model for TCO calculation to include all necessary costs related to the systems implementation and maintenance. Calculation was performed for both Odoo implementation and legacy IS to asses the comparison. Economical analysis rejected a preliminary hypothesis assuming that architecture would result in cost reduction for studied company. However, other outcomes turned out to be beneficial, such as improved flexibility and maintainability through modularization of the alternative system or better security which tended to be neglected within the company. Many outcomes and approaches were already discussed with CEO of the company, who helped to set the direction for complicated decisions of development possibilities. All final figures and conclusions are yet to be presented in order to discuss and evaluate actual execution of proposed changes.

67 8. Evaluation and Conclusion

The most important learning from this study is that the company should consider ERP implementation as an long term investment rather than short-term cost reduction asset, even though the current application state is far from perfect. It is also important to complete a post-implementation analysis to learn from the outcomes and remember why the company implemented the software in the first place rather than looking solely atthe financial aspect of such change. Future work could elaborate on strategies to implement such alternative within the company. Implementation must smoothly migrate all data and processes and adapt established company approaches to new ERP system while still preserving maximum efficiency in daily workload.

68 Bibliography

[1] Esichaikul Vatcharaporn and Nuankhieo Piyanan. “Connectiv- ity of ERP with Legacy Systems”. Thailand: Asian Institute of Technology, 2004. [2] Efraim. Turban, Linda. Volonino, and Gregory R. Wood. Infor- mation technology for management. advancing sustainable, profitable business growth. 9th edition. Hoboken, NJ: Wiley, [2013]. isbn: 11-183-5704-3. [3] Amir Manzoor. E-commerce. an introduction. 1. Aufl. Saarbrücken: LAP Lambert Acad. Publ, 2010. isbn: 978-384-3370-301. [4] Fabian Aulkemeier et al. “A pluggable service platform architecture for e-commerce”. In: Information systems and e-business management 14.3 (2016), pp. 469–489. [5] Mehdi Khazaeli, Leili Javadpour, and Gerald M. Knapp. “ERP adoption in enterprises with emerging Big Data”. Louisiana State University, 2015. [6] Fabian Aulkemeier et al. “A pluggable service platform architecture for e-commerce”. In: Information Systems and e-Business Management 14.3 (2016), pp. 469–489. issn: 1617-9854. [7] Vidyaranya B. Gargeya and Cydnee Brady. “Success and failure factors of adopting SAP in ERP system implementation”. In: Business Process Management Journal 11.5 (Oct. 2005), pp. 501– 516. issn: 1463-7154. [8] Paul Oude Luttighuis and Frank Biemans. “ERP in the e-commerce era”. In: (2002). [9] David M. Kroenke. Using MIS. Seventh edition. Boston: Pearson, 2015. isbn: 978-013-3547-368. [10] August-Wilhelm Scheer and Frank Habermann. “Enterprise Re- source Planning: Making ERP a Success”. In: Commun. ACM 43.4 (Apr. 2000), pp. 57–61. issn: 0001-0782. doi: 10.1145/332051. 332073. [11] Thomas F Wallace and Michael H Kremzar. ERP. making it happen : the implementers’ guide to success with enterprise resource planning. 2nd ed. New York: Wiley, 2001. isbn: 04-713-9201-4.

69 BIBLIOGRAPHY

[12] Petri Helo, Pornthep Anussornnitisarn, and Kongkiti Phusavat. “Expectation and reality in ERP implementation: Consultant and solution provider perspective”. In: Industrial Management & Data Systems 108.8 (Sept. 2008), pp. 1045–1059. issn: 0263-5577. [13] Ajit Kumar. ADempiere 3.6 cookbook. over 100 recipes for extending and customizing ADempiere beyond its standard capabilities. Olton, Birmingham: Packt Pub. Ltd., 2011. isbn: 9781849513395. [14] S.F. Huin. “Managing deployment of ERP systems in SMEs using multi-agents”. In: International Journal of Project Management 22.6 (2004), pp. 511–517. issn: 0263-7863. doi: http://dx.doi.org/ 10.1016/j.ijproman.2003.12.005. [15] Suzanne Beaumaster. “Information Technology Implementation Issues: An Analysis”. Virginia Polytechnic Institute and State University, 1999. [16] Elisabeth J. Umble, Ronald R. Haft, and M. Michael Umble. “En- terprise resource planning: Implementation procedures and critical success factors”. In: European Journal of Operational Research 146.2 (Apr. 2003), pp. 241–257. url: https://ideas.repec.org/ a/eee/ejores/v146y2003i2p241-257.html. [17] Yves Delsart and Christelle Van Nieuwenhuysen. OpenERP Eval- uation with SAP As Reference. Belgium: Tiny SPRL, 2011. isbn: 296008764X, 9782960087642. [18] Bruce G. Ferrin and Richard E. Plank. “Total Cost of Ownership Models: An Exploratory Study”. In: Journal of Supply Chain Man- agement 38.2 (2002), pp. 18–29. issn: 1745-493X. doi: 10.1111/j. 1745-493X.2002.tb00132.x. [19] Ruth Fischer and Rick Lugg. “The real cost of ILS ownership”. In: The Bottom Line 19.3 (2006), pp. 111–123. [20] Marc Walterbusch, Benedikt Martens, and Frank Teuteberg. “Eval- uating cloud computing services from a total cost of ownership perspective”. In: Management Research Review 36.6 (2013), pp. 613–638. doi: 10.1108/01409171311325769. [21] Why large companies use open source ERP. United States, 2015. url: https://opensource.com/business/15/3/why-large- companies-use-open-source-erp. [22] Saleh M Al-Saleem. “A Comparative Analysis and Evaluation of Open Source ERP Systems”. In: International Journal of Computer Science and Network Security (IJCSNS) 13.4 (2013), p. 24.

70 BIBLIOGRAPHY

[23] Roger S. Pressman. Software engineering. a practitioner’s approach. 7th ed. New York: McGraw-Hill Higher Education, c2010. isbn: 00-733-7597-7.