NGHIÊN CỨU XÂY DỰNG HỆ THỐNG HỖ TRỢ BÁN HÀNG CHO IBS-

SUPERMRO
Ths. Trần Văn Quân
quantv02@gmail.com
Khoa Công nghệ thông tin – Trường Đại học Hà Nội

Tóm tắt

IBS Super MRO Việt Nam (gọi tắt là IBS MRO) là một công ty bán lẻ trong lĩnh vực cung cấp
phụ tùng linh kiện công nghiệp và nhiều sản phẩm tiêu hao khác. Công ty IBS MRO hiện đang
cung cấp hàng nghìn chủng loại mặt hàng khác nhau. Việc quản lý những công việc hàng ngày
như quản lý sản phẩm, đơn đặt hàng, khách hàng, hay yêu cầu mua hàng, v.v. sẽ trở lên vô cùng
khó khăn nếu không có một hệ thống hỗ trợ thống nhất và hiệu quả. Chính vì vậy, dự án này
được thực hiện nhằm mục đính nghiên cứu và phát triển một hệ thống hỗ trợ kinh doanh và bán
hàng cho IBS MRO. Dựa trên phương pháp phát triển phần mềm phù hợp, tác giả đã xây dựng
cấu trúc tổng thể của toàn hệ thống cũng như chọn ra những tính năng quan trọng nhất để phát
triển. Qua đó, cho phép nhanh chóng đưa hệ thống vào ứng dụng và có thể mở rộng trong tương
lai.

DEVELOP THE BUSINESS SUPPORT SYSTEM FOR IBS-SUPER MRO

VIETNAM

Abstract

IBS MRO is a retail company in the supplies and spare parts domain. The company currently
provides hundreds of thousand different products to customers. Without a unified business
support system, it will be extremely hard to operate and manage everyday tasks such as products,
orders, customers, customer inquiries, etc. The purpose of this thesis is to provide the company a
solid solution to their business.

1 Introduction
IBS MRO Vietnam JSC (IBS MRO) is one of the first companies in the industry of
Maintenance Repair Overhaul/Operation (MRO) in Vietnam. The company’s vision is to become
the top supplies and spare parts retailer in Vietnam, and provide professional services. IBS MRO
has been working with many suppliers, factories and manufacturers, including Grainger, to help
provide customers best services. Operating in MRO industry, the company has to manage a very
large product database of various categories. Each category of product has its own set of
attributes. At the time of writing, the total product count is more than 800,000 and will regularly
increase over time.
 Huge volume of products is not the only difficulty the company faced. The Board of
Directors want to have a system that can manage not only products but also other daily activities
including: customer orders, customer inquiries, supplier management, inventory, customer
management, and the company purchase orders. Each function of the system needs to
communicate to each other efficiently. For example, the Inquiries module records every customer
inquiries and requests. Products are then selected based on the customer requirements in
combination with in-stock information, supplier price, order time, etc. The salesman will created
quote(s) from selected products. Once agreed, an Order will be created from the accepted quote
(module Order). If in-stock quantity of some products is not enough, there will be a notification
in module Purchase Order. When the order is finished, inventory will be updated accordingly.
Moreover, the system needs to be open so that information (orders, inquiries, inventory
operation, etc.) can be extracted for further analysis; or new module (such as decision making
support) can be added easily; other requirements include: customization, content privacy, and
security.

Apparently, an ERP system is what IBS MRO would need. ERP is not new, there are already
many off-the-shelf, both commercial and open-course software. Odoo, Interprise Suite, SAP
ERP, MasterTools, and NetSuite are some of the most popular software. However, ERP is not
what the company’s Board of Directors wanted. It seems to be too complicated with unnecessary
components. Meanwhile, ecommerce software generally do not provide all needed functions and
are hard to add new function modules. The company do not want a cloud-based service because
they desire absolute control on their data. On the other hand, other solutions seem to be difficult
to use, customize or not match with the company working process. In fact, the company reviewed
some ERP solutions (OFBiz, OpenBravo) and found that it was difficult to apply it on their
process or integrate with their current system. The company currently has a system used to store
and manage their products. Therefore, they finally decided to build their own business support
system.

This project aims at building a business support system for IBS Company (called Super
MRO) to solve the problems mentioned above. Below are specific:

 Review possible solutions for the client problems and gain knowledge about the
domain as well as study the client business processes.
 Find a suitable development model to apply for building the Super-MRO business
support system
 Design an overall architecture for the system.
 Develop the base system functions and top 5 important functional modules.
 Evaluate the results to improve the quality in other modules.
2 Background Knowledge
2.1 What is an ERP system
ERP stands for Enterprise Resources Planning. ERP is sometimes used interchangeably
with Enterprise Wide System (EWS), Enterprise Information System or Enterprise System.
ERP system derived from the material requirements planning (MRP) which were developed
in the 1970s to help manufacturers increase productivity in complicated and conventional
tasks such as production planning (Hopp & Spearman 2008). There are different ways to
define an ERP system. According to Markus et al. (Markus & Tanis 2000) Enterprise
resources planning systems are “commercial software packages that enable integration of
transaction-oriented data and business process throughout an organization”. In other words,
ERP system is a tool which consists of several different functional modules such as
purchasing order, sales, human resources management or accounting. These modules are able
to communicate with each other through common database. Therefore, the enterprise-wide
integration of data and task is allowed.
2.2 ERP system integration difficulty
There is no doubt that ERP plays an important role in any organization. As the evidence,
over 60% in the list of Fortune 1,000 companies had implemented core ERP applications
(José, Esteves de Sousa 2004); 40% and 43% are the number of mid-size and large companies
implemented ERP (Computer Economics 2014). A research conducted by S. Jacobson et al.
showed that the total revenue of ERP market in 2006 was $28.8 billion, an equivalent of 14%
growth from 2005 (Jacobson et al. 2007). However, the implementation failure rate is
incredibly high. Researches show that three quarters of the ERP projects are considered failed
by the clients (Griffith et al. 1999). Lately, according to Panorama Consulting report, the
failure rate seems to fall drastically to 16% in 2014 but raise again in 2015 (21%) (Panorama
Consulting Solutions 2015).
There are many reasons which cause the high failure rate of implementing ERP. The top
reason is misfit between the ERP and the organization. Customer organizations normally
want a unique business solution that suits them best. Meanwhile, ERP providers prefer a
generic solution which can be used for as many clients as possible (Swan et al. 1999). This
type of misfit can be further clustered to three categories: data misfits, process misfits, and
output misfits (Soh et al. 2000). Data misfits is the situation when the organization
requirements (regarding data format and/or entities relationship) conflict with the underlying
data model of the ERP package. Process or functional misfits, on the other hand is the conflict
between the organizations processing procedures and the ERP packages. Another critical
factor is the cultural misfit. This situation is worse in Asia, including Vietnam, because most
of ERP system is developed for Europe, USA and Western countries. The “best industry
practices” implemented in the ERP system occasionally match with Asian business practices
(Soh et al. 2000), especially Vietnam.
These incompatibilities can be overcome by packages customizations, work around, or
plug-in add-ons. The ERP packages usually come with very highly customizable options
which allow to adapt for different organizations. Changing the ERP source code is the last
option and should be avoided because modifying the source code would require a lot of
effort, human resource as well as financial cost. Moreover, source code changed would likely
block future updates of the core packages.
2.3 Current status of ERP in Vietnam
 In Vietnam, most of active businesses are small and medium enterprises (SMEs) and keep
raising from 2008 to 2013. According to the National General Statistics Office, there is about
more than 97% of the labor force working in these SMEs. Even though the cost to implement
ERP system in Vietnam might be lower, it is still of a very large resource to a small/medium
enterprise.
It is quite easy to find ERP providers in Vietnam, however it is not that easy to select a
suitable package for the company. By the time of starting this project, IBS MRO has called
for proposal of an ERP package solution. After the preliminary selection, VSSIC has been
selected to present their solution. Their solution is based on the open source solution: OFBiz
and OpenBravo. The presented solution is mostly a localized version of the original software
package with manual instruction. In order to make the software packages fit with the
company requirements, the only solution is to utilize the software customization and work
around. It is very hard even impossible to modify or develop custom plugins to meet the
company requirements.
Hence, after considering available options, the directors decided to hire a team to develop
a Business support system.
2.4 User Interface Design Principle
It is important to any information system to have a well-and-carefully-designed interface,
especially with web application. A good user interface not only impresses visitors by its look
and feeling but also allows user to use easily without learning new things. It must help
maintain the usability of the application. This project consists of two individual parts:
“Frontend” and “Backend”. “Frontend” is a web application to display the company products
and services to all visitors. It also allows user to search and order products to cart system. On
the other hand, “Backend” is a web application system that will be used by IBS MRO
employees. This is the heart of the Business Support System. The two individual parts use the
same common database, thus they are able to communicate to each other. In both parts of the
system, it is critical to have a carefully designed user interface. In order to make sure that the
system interface satisfies users, the eight golden rules of Shneiderman (Shneiderman 2004)
are applied: Strive for consistency; Cater to universal usability; Offer informative feedback;
Design dialogs to yield closure; Prevent errors; Permit easy reversal of actions Support
internal locus of control; Reduce short-term memory load. Besides, there are many principle
in designing interface. However, “Principles are not meant to be follow blindly, rather they
are meant as guiding lights for sensible interface design” (Mandel 1997). The author will
select and apply the principle adaptively to the system.
Moreover, Ajax technology will be used in both Frontend and Backend application to
reduce response time and improve users’ experience when using this system. Ajax is
technology that helps the web browser update data from server without reloading the page.
3 Development Methodology
3.1. Project’s Constraints
In order to find a best suited development approach, it is important to look at each
approach’s advantages and disadvantages. It is more important to review the project’s
constrains because there is no single development method can be applied in all kind of
projects. There are three possible models that can be used in this project. They are: waterfall,
Spiral and SCRUM. The development approach was chosen base on the following criteria’s:
o Time scale
o Stakeholder’s priority
o Requirement stability
o Human resource (development team)
3.2. Approach Selection
After studying the project’s constrains and the characteristics of possible development
approaches, the author matches them together to score each development model. The model
with the highest score will be selected to apply in the project.
Although Super-MRO system is a long-term project, the Waterfall model is not as good as
Spiral model or SCRUM in term of time scale. According to Avison D. & Fitzgerald G.,
Waterfall model is quite suitable for projects that have long duration or are not limited in time
(Avison & Fitzgerald 2006). However, this project is actually separated into multiple small
projects which have small amount of time budget. Therefore, it is better to use Spiral or
SCRUM approach in this project.
The second factor the author evaluated was stakeholder’s priority. It is obvious from the
project’s constraints that the stakeholder needs to have a part of system up and running early.
While this requirement can be met easily by Spiral or SCRUM model, the Waterfall model is
likely unable to do the same. By the nature of this development approach, waterfall model
requires clients to wait until the end of project to see the working product. Hence, in term of
stakeholder’s priority, Spiral and SCRUM gets one point while waterfall model has a minus.
The next factor to evaluate is requirement stability. There is no doubt that waterfall model
has no advantage over Spiral and SCRUM in this comparison. The waterfall model needs the
system’s requirements to be fully and clearly defined at the beginning of the project. This is
totally impossible for Super-MRO system. Currently, the Super-MRO system’s requirements
are not clear and fully listed. Requirements are only available through meetings and
interviews during each development phase. Although both Spiral and SCRUM models are
good at handling unstable requirements, SCRUM is more suitable for this project. Because
the requirements are unclear at first, according to Mohamed Sami, SCRUM is very excellent
to be used in projects that have unclear requirements (Anon n.d.). That is the reason SCRUM
model gets two points for this factor.
The last factor is also an important factor. No matter how good a development approach
is, it cannot be utilized if it does not suit the project’s team. Luckily, all development team’s
members have experience in different roles, which is ideally to form a cross-functional
development team. Moreover, there is a person who studied SCRUM carefully in the
company where the author works. He is very suitable to be a SCRUM master for the project.
Because the spiral development model relies on having a risk-assessment expertise while the
development team does not have one, the Spiral model has a minus on this factor.
All factors considered, Spiral and CRUM models are both standout as suitable
development approach for this project. However, because SCRUM suits the project better in
 term of requirement stability and human resources, the final decision is to use SCRUM to
develop Super-MRO system.
3.3. Project Plan
By limiting the scope of this project to a number of core modules, the author wants to
assure that the project will be completed on time and deliver a working product as soon as
possible.
Following SCRUM development approach, the system functions are built within Sprints.
Each sprint is two-week long. Because there are quite many Sprints in this project, the author
decides to describe the project by functional modules. It will be easier for reader to follow.
The table below represents the timeline of project. Modules are ordered by the importance
and dependency.

No. Module Description

1 System functions
2 Product management
3 Order management
4 Frontend website
5 Inventory management
6 Inquiry management
Implement the system’s basic functions such as
user management, access control
Develop product management function,
import/export tool
Implement order management module
Develop a website to display products and allow
customer to place orders
Develop module to manage inventory
input/output. Connect to order management
Develop inquiry module, connect to order
module.

4. First Iteration
4.1. Requirement
The functions required for the base system are user management, access control, internal
messaging and some other small features. User management is quite simple. The system
stores only basic information of a user such as Name, Email address, Phone number,
Department and allows user to login into system by username and password. There is no user
registration form because the system is for back office. New user will be created manually by
system administrator whenever there is new employee in the company.
The access control requirements are straight forward:
• User is only allowed to access certain functions of the system based on their
responsibility in the company. For example, supporting staff are able to access orders
management functions but are not allowed to see inventory functions.
• A user might play more than one role in the company.
• In a single (application) page, different user might have different access depending on
their role. For example, supporting staff, inventory keeper, purchaser, accountant, and
 shipper are all allowed to view the list of orders. However, only supporting staff are
allowed to edit the order or change the status of order from “pending” to “processing”.
On the other hand, only inventory keeper is able to dispatch products, thus change the
order status to “dispatched”. The supporting staff are unable to do the same.
In order to communicate and cooperate efficiently, the product owner wants to have an
internal messaging and notifications system. An example scenario is that the supporting staff
receive order from customer and it is required that the order must be delivered within 3 days.
It is important that all involved personnel must know about this and prepare for the order so
that it can be handled as quickly as possible. In this case, the supporting staff will create a
note on the order, and tag the people involved. By doing that, other users will receive a
notification and know about this order. Moreover, the system must be able to automatically
notify users when any specific event happens. For example if the status of an order is
changed, concerned people will be notified automatically.
It is also a requirement that the frontend website supports two languages: Vietnamese and
English. The English content might not available for everything at first but will be fulfilled
over time.
4.2 Design
4.2.1. Database Design
Database normalization is the process where columns and tables are re-organized to
remove redundant data. This process improves data integrity, storage efficiency and
scalability (Hillyer 2003). There are multiple levels of normalization, most commonly
known are: first, second, third, fourth and fifth normal form. Besides, there are few
normalization forms which are less popular named: Elementary key normal form, Boyce-
Codd normal form, and Sixth normal form. The benefits of database normalization come
at a price. The more columns and tables are normalized the more complexity the database
is. Increase in complexity of database potentially causes performance loss in the
application.
In this system, database is only normalized to the third normal form because further
normalization might unnecessarily complicate the system and lose performance. In some
cases, few specific tables which are de-normalized will create redundant data. To design
the database, the author will not create table in un-normalized form and sequentially
transform the table to 1st, 2nd and 3rd normal form. Instead, based on the author
experience, tables are designed to be as close to the 3rd normal form as possible. Then,
tables are reviewed to make sure that they are in the desired normalization form. By doing
this, the database design process is a lot faster.
4.2.2. User Interface Design
User interface is very important. A good design user interface can maximize the user
experience and improve the productivity (for back-end application). There are two ways
to have a user interface design: 1) Hire a graphic designer to design the UI then transfer
the design into .HTML files (which can be used in application). 2) Buy some UI design
that is already made available on the market. The first option can have complete control
 on the look & feel of the UI or allow whatever changes made to the interface design, but
is very time consuming and costly. On the other hand, buying someone’s UI design might
have some limitations such as: can be only used on single application, impossible or
difficult to change the design but it is quick and economy. For the application or website
that needs to be unique, beautiful and totally in control like the frontend website,
designing the interface from scratch is a good option. For application that focuses on
functionality and usability, buying implementation-ready UI template is a better option.
Therefore, the author and development team decided to buy a template to use in the
backend system. The template is called “Beoro Admin”. It has many already-built
components such as: charts, calendar, mailbox, etc. The template is a responsive design
which means it also works nicely on mobile devices. The author evaluates this template is
a very good admin template design which contains almost everything needed for the
backend application. Following are some screenshots of the template.

4.3. Implementation
The first step in implementing the modules is to transfer the designed database into tables
on SQL Server. To do this, the author uses SQL Server management studio which is
developed by Microsoft to manage SQL Server. It is very easy to use this tool to create tables
from the designed database. There are three approach to use Entity framework to cooperate
with database. Each approach has its own characteristics; developers select one approach
mostly based on personal preferences. Because the development team has been familiar with
the Database First approach, using this model will speed up the development process. Using
Visual studio, generating database model from existing database is a very easy and fun task.
For each functional module, a new Visual studio project is created within the same
Solution. Visual studio organizes codes as solutions and projects. A project in visual studio
contains all source code files, images, icons, and other resources that are needed to compile to
executable program, website, application or library. Multiple projects can be grouped to form
a Solution. Because the MRO Business Support System is a large system, contains many
different functional modules, the author separates functional modules into different visual
studio projects for easy management and development. The system core functions are
developed in the main project called Portal. Functions for product management module are
developed in a different project called Product.
The product management module functions are developed one by one according to their
priority. All use-cases go through the same development process, therefore, the author only
describes in detail the development process of the one use-case: Edit category.
The first step is to create a new ASP.NET Web form, which is named
EditProductCategory. There are three files generated for this web form:
EditProductCategory.aspx contains Html markup for the page, EditProductCategory.aspx.cs
contains server side code and EditProductCategory.aspx.designer.cs contains the auto-
generated code from the .aspx file. After the web form is created, necessary components
 including labels, textboxes, and buttons are added. The components are placed and formatted
in a way that makes them look good and convenient for users.
When users enter data into input fields and click a submit button, data in input fields is
sent to server through Postback and a corresponding Server code method is invoked. The
invoked server method receives data from the input fields and applies the business logics on it
to update the database accordingly. If everything is good, users will be redirected to another
page to see the result. Otherwise, they will receive an error message.
A problem occurring while implementing the product management module is the product
name generation. The product name is generally created by combining different attributes in a
certain order. While the function works perfectly with a small number of products, there is a
huge loss in performance when the number of product increases. The solution for this
problem is caching. Because the attributes of a product do not change frequently, it is safe to
store product cached name in a table. And this table will be updated whenever a product is
updated. The system also provides a function forcing to update the cache table in case some
products’ cache is not up-to-date as expected.
4.4. Test
Because of the limited human resources, the development team do not have a professional
tester. Therefore, the system was mainly tested by the developers, product owner and the
client users. The functions were first tested by the developer within the sprint while
developing. After the sprint was completed, the system was deployed on the client
development server so that the product owner and client’s users can access to the functions
and start testing. Bugs and changes were recorded on the project management tool (Redmine)
as a new backlog item.
In software development, there are tools to automate the testing phase. Unit test is one
example. While these techniques are efficient on a class for method, it is difficult to apply on
web application domain. On web application domain, the final result is an html page and
contains JavaScript code which makes testing automation is hard. Again, as there is no
professional tester, manual testing is the primary approach.
5. Second Iteration: Order management
5.1. Requirement
Order management is the main module of the system. Other functional module is built to
support this module. Almost every staff in the company must use this module at different
level. The requirement for this module is described below.
An Order must store following information:
• Customer & billing, and shipping information. Normally, for one customer, the billing
and shipping information is the same and unlikely to change from order to order.
However, there is possibility that one customer can have different billing & shipping
information for different orders.
• Order items, including: product id, quantity, unit of quantity, price & tax. The product
price might different for different customer or purchased quantity and other factors.
• Payment method. The value is one of the three: COD, Prepaid and Debt
• The current status. The status of an order can be: Pending, Confirmed, Paid, Debt,
COD, Dispatched, Delivering, Delivered, and Closed. The order status can only be
changed from predefined statuses and by the authorized user only. Some statuses are
automatically changed when certain criteria is met. The figure 10 below represents the
flow of order statuses.
• Notes. This is where extra information is stored. Staff can communicate via this
channel.
• Expected delivery date
• Creator & Person in charge. This piece of information will let everyone know who to
contact with when something happens to the order. Moreover, only the person in
charge is able to change the order information such as order items, customer
information, etc. This mechanism prevents supporting staff from editing each other’s
orders. The person in charge can be changed by the sale manager.

.
5.1.1. Use-cases
 There are four memberships involved in order handling process. They are: Supporting
staff, Accountant, Stock keeper and Shipper. The main use-cases are represented in the
figure below.

5.2. Design
5.2.1. Database design
Applying the same technique described in the previous iteration, the author creates a
database design for the order module. Among 9 tables created for this module, there are
two special tables: ec_SimpleOrderLogs and ec_SimpleOrderItemLogs table. These two
table design is almost the same with table ec_SimpleOrders and ec_SimpleOrderItems
respectively. That is because these two tables are used to record the changes made to
orders. Every bit of information of each order will be copied to these tables before
updated so that the administrator can view the complete history of an order as well as the
person changing that order. In term of database design, the tables for order module are not
efficient for storage and are not properly normalized. However, this design make it easy
to develop the application. Most importantly, it increases the application performance.
As noted in the requirements, the status of an order cannot be change freely, they must
flow in a strict order. This business rule can be hard-coded into the application code.
Nonetheless, the author decided to make it more flexible. By designing an ec_Status table
with the Prerequisite column, the system allows users to change the order status flow
without re-conducting the coding job.
5.2.2. Functional design
 The most important requirement for this page is that it must provide as much
information as possible. The problem is limited space of a computer screen. A normal
screen width is about 1366 pixels. The system cannot simply display all the data of an
order to the screen. Moreover, placing too much text on the screen might distract and
make users confused. The author’s solution was to select only important and informative
attributes of the order to display on the screen. The selected columns are: Order code,
Customer, Customer email, Order date, Expected delivery date, Total cost, Person in
charge, Payment method, Status, and notes. Because the order notes are normally long,
they are hidden to save space and will be shown up in a modal dialog when users click on
“Xem ghi chú”. Furthermore, to provide richer information to users, ordering and color is
used. For example, the prioritized orders are placed on top of the list (the normal ordering
is created by time) and have the light blue as background color. In contrast, the order
which is overdue but is not completed is colored with red.
Another function in this screen is searching. On top of each column in the order list
table, an input field is placed to allow users to search for order by this field. Types of the
input field depend on the data type of the column. Moreover, the screen also provides an
advanced search option to allow users to restrict the search results. The advanced search
filed is collapsed by default to In order to help users focus on ongoing orders, the closed
& canceled orders are hidden by default. They can be shown by inclusively selecting
closed and/or canceled status in the status filter.
To allow users to edit the items in an order, the author used a tool called handsontable
(https://handsontable.com). This is a JavaScript library that allows website to display data
list in an excel-like table. It allows users to edit data in row, column and cell like they do
in excel. It even allows to copy and paste. This technology improves the productivity very
much in comparison with the traditional method of editing data in web applications. In a
traditional web application, the order item would be displayed in table with an edit
hyperlink. Users must click on this link to go to the edit page. After completing editing,
they are redirected back to the original page. This requires a lot of clicks and loading
time.
This screen provides users with two methods of selecting products. If the users
remember exactly the product system code, they can enter it directly in the Product code
column. The product information will be loaded. If the users do not know the product
code, they can open the product model, and search for the product.

5.3. Implementation
The implementation of this module is similar to product management module. The first
step is to create a new visual studio project. Then, the next step is to update the database
models. Because all module in the system share the same database, the database models and
handling classes is separated into a different project called the Library. Lastly, Asp.net web
form is created for each functional screen. The development process is the same the described
in section 5.3.
5.4. Test
 After complete the development steps, the module is deployed to the development server
for testing. Firstly, the module is tested by the developers. Then the product owner and the
client employee test the module with sample data. While the module passes most of the
developers’ test, it turns out that there are many issues occurring when the product owner
tries the module. It is because of the different point of views, that is the developers mostly test
to see if a function works whereas the product owner focuses on the business rules.
6. Critical Evaluation
6.1. Development Approach
Although the development of the Super-MRO Business support system keeps going after
this paper is submitted, it is safe to say that the development approach works well in this
project. Throughout the development of the base system and 5 main functional modules, all
the modules were delivered on time. The model handled requirement changes very well. In all
developed modules, there were countless times when the product owner updated the
requirements (he found much more desired features). The SCRUM model accepted all those
changes while still protecting the developers from interferences.
The fact that there are only three members in the development team prevented the team
from taking the most advantages of the SCRUM model. The author must be responsible for
main tasks in most of development phases. It created much pressure and workload.
Furthermore, lacking a member with professional testing skills made the testing result not
achieve expected quality. It would be better if the development team had one or two more
developers. It would not only reduce the workload for key developer but also improve the
overall quality of the product.
6.2. Project Development
One of the author’s biggest concerns about the project is the test procedure. The author
does not have so much experience on testing. Thus, the test procedure was executed manually
by the content team and developers. They worked with the sample data generated by Data
Seeder, recorded the error and sent back to the developer via the test form. Testing in that
way takes a lot of time and may miss some bugs because the test case sometimes cannot
cover all scenarios of the system. Thus, to deal with this issue, the author is planning to
employ a professional tester who could lead the test team and handle this important phase for
him.
Although the project was divided into small iterations with mini waterfall model, the
author realized that the way to carry out each iteration could be different depending on tasks
selected to execute in that iteration. Despite of consisting four phases like other iterations, the
first one having steps in design and implementation are totally different from three last
iterations’ because it focuses on UI development, not function development. On developing a
backend module as in the second iteration, the author paid much attention at the domain class
and the service class while the key point in developing a frontend module as in the third
iteration is the user experience and the code behind ASP.NET pages. In the last iteration, both
frontend and backend module were developed. That requires more time and effort of the
developer than two previous one. In brief, it should be flexible to apply the model during the
project instead of rigidly following a specific development model.
6.3. System Features
Even though the system is currently running well, adapts the client needs and works
smoothly as expected, there are still some features that need to be improved. Firstly, the
database models are not efficient. Currently, all database models are placed in a same model
file. It works totally well when the number of tables is small. However, when more functional
modules were added, they created much more number of tables. As a result, there were too
many tables in the same model file to manage at the same time. Whenever one domain class
need to be updated, it took minutes to find where it is and more time for the Asp.Net
framework to regenerate the classes. Moreover, putting too many tables in a model would
result in a loss in the performance. The author is planning to separate those tables into
different data bounded contexts for easier development and performance improvement as
well. It is not simple as just putting domain classes into different files because a domain class
in one data context can have relation and interaction with classes in a different context.
Secondly, the security of the system has not been paid adequate attention. The system
lacks protecting mechanism from attacks such as DDoS. Although the DDoS attack is
unavoidable, there are strategies to detect as well as to reduce damage from such attacks
(Mirkovic & Reiher 2004). Besides, the communication between the user client and server is
unprotected. Only the backend website connection is encrypted using SSL technology. It is
expected to have a serious review about the system security in the near future. The
ecommerce website should be served through HTTPS soon.
Lastly, the performance of some functions has not been good as expected yet. The loading
time is too long. For instance, the export orders to excel files is quite time consuming.
Depending on the number of orders to export, the time it takes to complete the request
ranging from few seconds to minutes. If there are too many orders in the list, the function can
even timeout. The time-consuming functions are generally reporting or exporting tasks which
require to read a big amount of data. They also have low frequency of usage thus are
acceptable. However, they are must-be-fixed issues. In order to reduce the responding time of
such those functions, the author is thinking of applying some caching mechanism or possibly
create a separated application for heavy data-consuming tasks.
6.4. Users’ Feedback
The users’ feedback is important to every software system. For the backend system, most
of end user’s feedback is collected by the product owner. While using the system, if they find
anything unreasonable or any desired features that need to increase the productivity, they can
inform the product owner. The product owner collects all feedbacks and discusses with the
author to decide the changes for the system. Sometimes the users’ requests are rejected
because they conflict with the business rules or other constrains but most of the time, users’
feedback is very constructive and can truly increase the system’s effectiveness.
The frontend ecommerce website, on the other hand is not yet received feedback from end
users since the client company mainly focuses on the functionality of backend system at this
stage. The need for an effective management system is more urgent than the frontend website
because the ecommerce website is currently not the main sales channel of the company. The
 author still suggests some ways of gathering end user feedback for the frontend website to
improve the application.
7. Conclusion and Future of Work
The aims of this project is to build parts of a business supporting system for IBS MRO. The
target has been achieved with the overall architecture if the supporting system is sketched out.
This architecture is the foundation to create all other modules in the system. Five functional
modules have been implemented including: Product management which allows users to
dynamically manage product category and product attributes for each category; The Order
management module with unique workflow; an ecommerce website that allows customers to find
product easily and place order quickly; The Inventory and Inquiry modules provide functions for
managing inventory operations and customer inquiries respectively. They also link to module
Order management to provide more information while processing orders. All modules are
delivered on time and are now working smoothly.
Within the scope of this paper, only five modules were developed. The author and his
development team still have much work to complete the Super-MRO Business Support System
after this paper was submitted. There are four more modules to be implemented: The CRM
module to manage customers and customer related information; The Purchasing & Supplier
module to manage suppliers and purchases the company made; The purchasing module to link
inventory module as an input; and Reporting module which is very important but has not been
implemented. Furthermore, a security review will be conducted to find and fix possible security
holes.

References
Adya, A. et al., 2007. Anatomy of the ado. net entity framework. In Proceedings of the 2007 ACM
SIGMOD international conference on Management of data. pp. 877–888.

Al-mashari, M., 2000. Constructs of process change management in ERP context : A focus on SAP R/3.
Americas Conference on Information Systems, 113, pp.976–980.

Anon, Choosing the right Software development life cycle model | Mohamed Sami on WordPress.com.
Available at: https://melsatar.wordpress.com/2012/03/21/choosing-the-right-software-
development-life-cycle-model/ [Accessed March 21, 2016].

Avison, D. & Fitzgerald, G., 2006. Information Systems Development: methodologies, techniques and
tools 4th ed., New York: McGraw-Hill College.

Boehm, B.W., 1988. A spiral model of software development and enhancement. Computer, 21(5), pp.61–
72.

Computer Economics, 2014. ERP Adoption Trends and Customer Experience,

Esteves de Sousa, J.M., 2004. Definition And Analysis Of Critical Success Factors For ERP Implementation
Projects.
Freeman, R.E., 2010. Strategic management: A stakeholder approach, Cambridge University Press.

General Statistics Office of Vietnam., 2014. Statistical Yearbook, 2014, Statistical Publishing House.

Griffith, T., Zammuto, R. & Aiman-Smith, L., 1999. Why New Technologies Fail. Industrial Management,
(41), pp.29–34.

Hillyer, M., 2003. An introduction to database normalization. MySQL AB.

Hopp, W.J. & Spearman, M.L., 2008. Factory Physics: foundation of manufacturing management,
Available at: http://www.mendeley.com/c/4462991193/p/9637071/hopp-2000-factory-physics-
foundation-of-manufacturing-management/.

Jacobson, S. et al., 2007. The ERP market sizing report, 2006--2011. AMR Research, 29.

Mahalakshmi, M. & Sundararajan, M., 2013. Traditional SDLC Vs Scrum Methodology--A Comparative
Study. International Journal of Emerging Technology and Advanced Engineering, 3(6), pp.192–196.

Mandel, T., 1997. The elements of user interface design, Available at: http://books.google.com/books?
id=H-ZQAAAAMAAJ&pgis=1.

Markus, M.L. & Tanis, C., 2000. The Enterprise System Experience — From Adoption to Success. In
Framing the Domains of IT Management: Projecting the Future Through the Past. pp. 173–207.

Mirkovic, J. & Reiher, P., 2004. A taxonomy of DDoS attack and DDoS defense mechanisms. ACM
SIGCOMM Computer Communication Review, 34(2), pp.39–53.

Panorama Consulting Solutions, 2015. 2015 ERP Report, Colorado.

Royce, W.W., 1970. Managing the development of large software systems. In proceedings of IEEE
WESCON. pp. 1–9.

Sarkis, J. & Sundarraj, R.P., 2000. Factors for strategic evaluation of enterprise information technologies.
International Journal of Physical Distribution & Logistics Management, 30, pp.196–220.

Shams-Ul-Arif, M.R., KHAN, M.R.Q. & Gahyyur, S.A.K., 2009. Requirements engineering processes,
tools/technologies, & methodologies. International Journal of Reviews in Computing.

Shneiderman, B., 2004. The Eight Golden Rules of Interface Design. Available at:
https://www.cs.umd.edu/users/ben/goldenrules.html [Accessed January 28, 2016].

Soh, C., Kien, S.S. & Tay-Yap, J., 2000. Enterprise resource planning: cultural fits and misfits: is ERP a
universal solution? Communications of the ACM, 43(4), pp.47–51.

Standish Group, 2009. Chaos summary,

Swan, J., Newell, S. & Robertson, M., 1999. The illusion of “best practice” in information systems for
operations management. European Journal of Information Systems, 8(4), pp.284–293. Available at:
http://search.proquest.com/docview/218756683?accountid=10297.
Young, R.R., 2002. Recommended requirements gathering practices. CrossTalk, 15(4), pp.9–12.