47

Chapter 5 – System Implementation

5.1. System Specification

To execute the program, there are several peripherals needed to support the i/o

system such as:

Monitor, to show the output of the program, and preferably support touch

screen application.

Mouse, to help in navigation and support the selection process.

Keyboard, to conduct menu input to the system.

PC, to execute the system and act as storage for the system.

5.2. Implementation Strategy

5.2.1. Proposed ERP System

For the ERP system, we decided to choose Compiere ERP system for

the interface development. ERP system can provide all the functions needed to

support POS system within its business process logic. ERP system has an

integrated data from one process to another especially within the sales order

process, and through ERP, POS system can conduct enhanced inventory

system to identify the material management needs towards the sales.

There are several reasons why we choose Compiere to support this

thesis, which will be explained in detail in the next sub chapter.

48

5.2.2. Why Compiere ERP?

Compiere is the most popular open source ERP system. Besides it has

been downloaded more than 900,000 times, it also has an international partner

network, and there are several reference installations for Compiere [3].

One of the reasons why we choose Compiere as the base of the system

is that Compiere is an open source ERP system, which allows the user of the

ERP system to customize it to fit the organizational needs on the system, by

providing subversion to download the source code from their website. Besides

ERP module customization, the GUI design can also be customized.

Other reason is towards its programming language and documentation.

The preferable programming language for designing GUI interface is using

Java, which provides Swing library that could ease the GUI design phase.

There are several open source ERP systems that are compared in the discussion

by Herzog [3]. From the comparison, the existing open source ERP is designed

through various programming language such as Perl, Python, and Java. The

ERP system that used Java as its base programming language are Opentaps and

Compiere, but compared through its documentation, Compiere provides better

documentation report to assist the customization than Opentaps. Therefore,

from the conclusion of comparison is taken by using Compiere.

49

5.2.3. Compiere ERP Framework Architecture

Figure 5-1 Compiere Framework Architecture

The architecture of Compiere is a mixture of fat client 2-tier and 3-tier

architecture using Model Driven Architecture (MDA), which enables the users

to design rapid application customizations [10]. The process of adding new

column to a table and creating report that includes the new column towards the

system can be conducted without any procedural coding or crafting of SQL

commands towards the system.

The 2-tier consists of database tier and application server tier, which

the application server tier has three layers to support the application server:

business logic layer (application dictionary), data layer (transaction engine),

and presentation layer (user interface).

Application dictionary is at the meta-data layer that controls the access

to any transaction data and provides data relationship information. All business

logic that is implemented towards the system is stored within application

dictionary.

50

Data layer stores all callout functions to be presented in the

presentation layer for the users. The callout functions consist of the business

logic from application dictionary. The system accepts user input and

navigation throughout the data layer.

5.3. User Interface Design

5.3.1. Current ERP Interface Design

In Compiere, most of the interface designs are designed using form

fillin approach as the input and output appearance to the users. The reason why

Compiere uses form fillin to support their interface is caused by the needs of

the users to conduct data input towards the system, and form fillin approach is

the best approach for data input system.

51

Figure 5-2 Current Compiere GUI layout – Order Line

In restaurant system, the users will select the ordered menu towards the

system. Form fillin is most suitable to text component based, which is to edit

and view text in an application; meanwhile, the best approach for option

selection is using button forms [11].

Therefore, the UI design within Compiere ERP should be redesigned to

suit the forms. The approach of redesigning the user interface can be

developed in two ways; first, we create an independent user interface as the

52

presentation layer to ease the order input and billing system. Second, the

existing user interface will be redesigned in several parts that are required

changes to support the effectiveness of system input.

5.4. Integration Phase Problems

Compiere has its uniqueness in the coding style. The functions to record and

recall data are stored in the business logic layer, called as the Callout function. Each

function within Compiere is displayed through specific callout and database query

interpretation. At the same time, Compiere is using complex query interpretation for

callout function.

Understanding the callout function and query interpretation might be time-

consuming. Although the callout functions have been defined specifically, in order to

acquire specific data, the callout function should call specific SQL query.

The query interpretation to acquire specific data cannot be done in short time

development, since the database table within Compiere has more than 600 tables to be

defined. Although specific database table can be defined, the query interpretation

requires INNER JOIN query from one table to another to be able to acquire

demanded data, which should be conducted further analysis towards its database

system.

Due to time constraints, the first approach is not the best solution for the

implementation.

5.5. Encounter Solution

As the solution for the problem above, the system will follow Compiere base

logic, with several changes in the GUI form and navigation system.

53

For the main form, Compiere has the ERP function menu within the selection,

but it provides user favorites function as the shortcut to access the function that is

accessed frequently by the users. All of the functions required can be stored into the

favorites bar on the right side, so that the users would not need to search for the

function within Compiere system.

Figure 5-3 Compiere main form

For the order input system, as being displayed in Figure 5.3 – 1, major forms to

modify data manipulating is using form fillin, which is contrary to the best approach

54

proposed in Chapter 4 (4.3). To encounter the problem, for the product selection will

be transformed into button action.

Figure 5-4 Product Selection in Button Form

The new design for the product selection is based on the prototype design to

perform order input system. The menu selection is designed using button form to ease

the selection instead of searching the product in table form. The toggle button displays

the selected item in the order line.

55

For the number input system, Compiere has already implemented a calculator

base form to provide touch screen form towards the system, but the target size does

not comply to the proposed approach, since Compiere is not designed to support touch

screen interface. The number input system can be inserted through keyboard typing in

the input field.

Figure 5-5 Calculator form inside Compiere function

5.6. Testing Plan

The testing plan for the system will be conducted in two phases; first phase is

conducted through prototype design shown in Chapter 4, and the second phase is

conducted through new design of Compiere interface. Both interfaces will be tested

using heuristic evaluation to achieve the measurement based on the eight golden rules

in designing a good user interface.

The criteria of the testing will be based on the time needed by the users to learn

the system, speed of task performance, and subjective user satisfaction. For the result

of time and speed analysis, it will be taken by the tester during the testing using clock

timer.

56

5.6.1. Prototype Testing

On both testing phase, there will be two observers; one acts as the

navigator, and the other acts as the time keeper. The prototype interface was

shown in Visio, assisted by the navigator through the system navigation. The

time keeper will check the time and speed performance made by the users

during the testing.

At the end of the testing, a survey will be given to the users to acquire

feedback towards the system design and usability.

5.6.2. Integration Testing

For the integration testing, the interface was shown using the

observer’s computer, showing the new Compiere system interface. The

shortcut function had been set to ease the navigation, and the navigator will

assist while the users asked questions about the navigation. Similar to the

prototype testing, at the end of the testing, a survey will be given to acquire

feedback towards the system design and usability.

For the time and speed performance will be conducted by the tester. It

will compare the result of early UI against the new UI set on the system to

achieve the same goal.

57

Chapter 6 – Evaluation Through the testing made during the implementation, there are several

feedback acquired from the testers. Within this chapter, we will discuss the result of

the survey, and the evaluation from the result and several discussions towards the

users’ feedback. The questions of survey can be referred to Appendix A.

6.1. Testing Result

From the testing phase above, we acquired feedback towards the system

designed. This following sub chapter will discuss the result from the feedback.

The testing involved five people from the restaurant that we interviewed, and

five non-restaurant people who will act as the users of the system, with the average

age of 24. The users will be given some information about restaurant business process

to ease the utilization of the system.

6.1.1. Prototype Testing Result

The result of the prototype testing from the acquired survey result will

be described in the following point:

Time and speed performance

The result during testing regarding time and speed performance of

the users proved that the users could utilize the system well with the

information given. For both users, the time needed by the users to learn the

system was short. Within less than five minutes, the users could navigate

the system properly.

58

The speed of finishing the task given was fast, especially from the

restaurant users. For non-restaurant users, the speed of finishing the task is

below the restaurant users at the first use, but then the speed increased

after they experienced the system.

Learning

For the learning issue, the testers found that the prototype design

had provided a good learning system. It was not complicated and easy to

be understood, even by people who did not have the knowledge about the

system before hand.

Figure 6-1 Prototype Survey result – Learning 1

59

Figure 6-2 Prototype Survey result – Learning 2

Figure 6-3 Prototype Survey Result – Learning 3

From the survey result, 8 out of 10 said that the system provide a good

overall learning to the testers.

60

Screen design

Figure 6-4 Prototype Screen Design – Layout Design

Figure 6-5 Prototype Screen Design – Sequence of screens

Based on the feedback, the GUI for prototype design is well-

designed for the positioning. The tester majorly agreed that the layout

design for the system is positioned in the proper position to show the flow

of the system. From the layout design, the users could easily identify the

next step of the process.

61

Figure 6-6 Prototype Screen Design – Text Size

Figure 6-7 Prototype Screen Design – Button Size

62

Figure 6-8 Prototype Screen Design – Overall Design

For the size of the components, most of the users agreed that the

size set for the system had already fit with the interface. The button size is

fit for the system if it will be implemented to touch screen interfaces, and

the arrangement of the buttons suit the users’ preference. The text shown

in the prototype is clear to show the information needed by the users.

63

System usability

Figure 6-9 Prototype System usability 1

Figure 6-10 Prototype System usability 2

For the prototype design, the users felt the system was easy to use

and navigate. The users also had the feels in controlling the system. The

navigation control from the main form provided easy navigation to access

each form of the system. The information text within each pages also

provided clear information about the system process.

64

Figure 6-11 Prototype System usability – Error Information

The error and warning messages provides clear information to the

users about the next step they had to follow. The closure information

helped the users to revalidate the input before submitting to the database.

Overall

Figure 6-12 Prototype Overall Result - Convenience

For the overall result, most of the testers felt convenient during

testing. They did not feel anxious in performing mistakes during the

65

testing, and they could utilize the system back and forth from one form to

another.

Figure 6-13 Prototype Overall result – Usability

Figure 6-14 Prototype Overall result - Flexibility

For the usability and flexibility, since it was only the prototype

design, the result of the survey was performed in average result. Major

testers felt that the flexibility of the system would be better if the prototype

could perform as it supposed to be.

66

6.1.2. Integration Testing Result

The integration testing result based on the survey given will be

described in the following point.

Learning

Figure 6-15 Integration survey result - Learning 1

Figure 6-16 Integration survey result – Learning 2

67

Figure 6-17 Integration survey result – overall learning

Some of the testers found difficulties in using the Compiere system on

the first utilization, but with the help of the shortcuts given in the main form,

the users did not have to waste time to find the modules that they needed. After

several times repeating the process, 7 out of 10 found that Compiere ERP was

easy to be adapted.

68

Screen Design

Figure 6-18 Integration Screen Design – Layout Design

Figure 6-19 Integration Screen Design – Text Size

69

Figure 6-20 Integration Screen Design – Button Size

Figure 6-21 Integration Screen Design – Overall design

For the screen design, the layout design for the existing system had

already provided a good interface to the users. Major of the testers felt that the

size of text and button within the interface was above average in convenience

to the users, yet the convenience during the utilization was decreased

compared to the prototype design. The inconvenience of the utilization of the

system was because of too many steps in the process to fulfill one task.

70

System Usability

Figure 6-22 Integration System Usability 1

Figure 6-23 Integration System Usability 2

71

Figure 6-24 Integration System Usability - Overall

Regarding the usability of the system, major of the testers felt that

the system was easy to use and the screen navigation within the system

was easy to be understood. The navigation control was assisted by the

shortcuts on the main form, and the interface shown to the users gave

enough information on the tasks that the users required to fulfill.

Perceived Usefulness

Figure 6-25 Integration Perceived Usefulness 1

72

Figure 6-26 Integration Perceived Usefulness 2

Figure 6-27 Integration Perceived Usefulness 3

The testers perceived that by implementing the system would

averagely improve the job performance, and it would also averagely ease

the tasks. The navigation of the modified interface system was quite

complicated to the users, and it would require more time during the

implementation.

Time and speed performance

73

The time and speed performance in finishing the tasks was not

improved, compared to the usual process. The time required to finish one

task was longer than the prototype process. The speed of performance was

also decreased due to the complication of process within Compiere.

6.1.3. Cost Effective Comparison

As the aim of this thesis, the result of the system implementation will

be compared to the required cost. This will be compared to the actual price that

is listed for Solis Resto [17]. This sub chapter will provide the evidence that

the solution proposed in this thesis could provide cost effective solution

towards small medium restaurant business.

As the alternative solution, Solis Resto provides many modules that

could assist the process of a restaurant, yet the required cost to implement such

system. The implementation fee of Solis Resto, which has already included the

installation, configuration, maintenance, training, and upgrade, would cost

around IDR 2 million and may vary based on location. For the POS system

itself adds the cost of IDR 3 million, which supports with 1 terminal system for

30 tables, and would be charged on the additional features such as more POS

terminals and more tables. The system itself excludes the Data Center, which

for the installation will add the cost of IDR 5 million, and another additional

cost for the store license and specific data center e.g. inventory, sales,

purchasing and production.

The total cost of implementing standard POS system based on Solis

Resto pricing can be concluded as following:

74

POS terminal for 30 tables Rp 3.000.000,00 Implementation Fee Rp 2.000.000,00 Data Center Rp 5.000.000,00 1 Store License Rp 3.000.000,00 Total Rp 13.000.000,00

Table 6-1 Standard POS system cost

Compared to the required cost of solution proposed, since the system is

utilizing open source for both system and database, there will be no charged

cost regarding system issue. The possible required cost will include the

implementation fee, which already included the maintenance and upgrade. We

assume the implementation fee is similar to the actual price; then, the required

cost of proposed solution will cost only IDR 2 million.

6.2. Evaluation

From the result of the testing implementation, we evaluated the prototype and

integration result compared to the fundamentals discussed in chapter 2. The result of

the evaluation will be discussed in the following points.

The prototype design had fulfilled the requirement to design a good and proper

user interface of a system towards the users. Following the eight golden rules

discussed in Chapter 2 (2.2.1) and the result of survey, the prototype interface

provided a convenient design to the users. Major users felt convenient while

utilizing the prototype design during the testing.

The modification of Compiere interface system did not ease the process of

utilizing Compiere ERP. This was proven from the feedback regarding user’s

75

convenience while utilizing Compiere. The level of convenience was better in

the prototype design than the modification design.

Current interface design did not prove to help to shorten the process time, but in

the testers’ perceives, if the prototype design could be implemented on

Compiere, it might be able to improve the process. They felt that the navigation

of the prototype design was much easier than utilizing through Compiere

interface.

The time and speed performance did not improve while the process was

conducted through Compiere ERP. Compiere has complicated process

requirement to conduct one process, which may halt the process in completing

the tasks.

The proposed solution could provide a solution towards the cost issue. It was

proven in the result in the previous sub-chapter (6.1.3). The proposed solution

could provide cheaper cost compared to the existing system. Therefore, cost

effective issue was solved from the comparison result in 6.1.3.

6.3. Future Work

Through the evaluation of the result, it could be concluded that current system

interface has not yet been the best solution. Referring to the survey result, the testers

perceived that the system could assist them to improve the process, but yet, the

current interface did not support the result. However, some of the testers gave

positive feedback regarding the prototype design.

76

For the future work, the prototype design can be implemented to Compiere

through several developments. The business logic functions required for the prototype

design can be designed using Compiere business logics implemented. These functions

can be retrieved from org.compiere.model package within Compiere system. The

business process logics had been defined into separate classes, but the system calls

the function through the classes with names of Callout [14], [16]. The business logic

would be able to be implemented through a proper function call, following the logic

within Compiere system.