CASE STUDY: CUSTOMER SUPPORT SYSTEM

Many corporations today consider it a competitive advantage to wirelessenable their enterprise applications, giving employees access to time-sensitive information. However, as there are many kinds of enterprise applications, we must understand which scenarios fit for J2ME and which do not.

Below are the characteristics of J2ME applications with respect to some managerial views:

1. J2ME works well on cell phone devices and support cross-devices. This is the reason why J2ME is supported on many cell phone devices. This portability allows the application to have a longer life span. The application can be reused to follow the advancement in cell phone devices, which in turn increases its ROI.

2. J2ME requires a small footprint, so it can run on many relatively cheap cell phone devices. This sheds the notion that a wireless enterprise application is expensive and only serves high-end users. The low deployment cost allows various applications for less-sophisticated users.

3. J2ME applications on cell phones typically use the network operator for communication, e.g., GSM (GSM Association, 2001b), GPRS (GSM Association, 2001c), or iDEN network (Motorola iDEN Subscriber Group , 2002). Therefore, a company need not invest in a proprietary network. This also results in cheaper deployment cost.

4. With the familiarity of cell phones, companies will require minimal training time in migrating to wireless applications.

5. J2ME application size is limited. As J2ME runs in a constrained memory space, the application written for J2ME must not be too complex.

6. Due to the limited graphic and input interface of cell phone devices, this model may not be suitable for applications that require intensive input and graphic capabilities.

Therefore, examples of business people that will benefit from such applications are field workers, salespeople, ambulatory medical workers, customer service people, and inventory staff (Morton & Bukhres, 1997).

We will discuss one scenario in detail, the customer support system.

Customer Support System Requirements

We based our study on the Singapore Engineering Software (SES) Support Group. The SES Support Group, formed in December 1999, has the main function of monitoring defects reported or incidents happening on the client site (Tjahyadi, 2000). The products that SES offers include important servers and databases that serve critical services such as the Singapore Police Department.

In a typical customer support scenario, a client reports defects or makes complaints via fax or phone to the support group. The support group will respond by going to the user site to solve the problem. Currently, the help desk in the group will be the first-line approach to receive the complaints and give walkaround solutions to the problems. If the problem persists, the system support will send its engineers and developers to handle the maintenance and repair of the SES products at the client site.

Due to the urgent nature of some of the problems, the help desk must be able to contact the system support engineers immediately when a case arrives. The engineer may need to go down to the client site immediately with all the necessary documents, such as the historical info and the technical manuals of the product.

If the support engineer cannot solve the problem, he or she may need to ask the guidance of other people, such as the developer of the system. The support engineers need to update the level of severity of the problem, record the steps that have been taken, and forward this report to the appropriate person. The managers , back at the head office, may need to monitor the overall performance of the group, such as the average time of service, the engineer with the fastest response, etc.

How Wireless Applications Can Help

We have developed a wireless application on a Motorola i85s cell phone so that support engineers can carry it with them wherever they go. The cell phones are connected by the nationwide iDEN network, which allows the support engineers to go anywhere within the country without the risk of loss of communication.

The wireless application allows the help desk group to schedule new appointments for the support engineer immediately when a case arrives no matter where the support engineer is. In future implementations we can use cell phones that are equipped with GPS (global positioning system), which will allow the help desk to dispatch the task to the nearest available engineer.

Figure 12: Customer support scenario describing the scenario of client, help desk, and support engineer

The wireless application also allows the support engineer to organize his or her tasks . The help desk not only forwards the time and location of the appointment but also the client's report and description to the support engineer. The support engineer will be able to understand the situation better and therefore minimize any miscommunication with the help desk. With each task, the support engineer can view the detailed description of the request, the case history , and other information. Therefore, upon arrival to the client's site, the support engineer will already know what to do.

The spport engineer can also query the database in the client site using the mini library in the cell phone. If the barcode ID of the related product is available, the support engineer can key in this barcode ID and query its product history and specifications, etc. The Motorola i85s cell phone allows communication via an RS232 port; therefore, a barcode reader can be attached at the bottom of the phone to allow the support engineer to scan in the barcode ID instead (Motorola Global Telecom Solution Sector, 2001). The support engineers can also query vast information libraries that reside in the company database of the supplier, such as a troubleshooting guide or manuals .

Figure 13: Customer support scenario describing the scenario of support engineer, manager, and back-end enterprise database

The support engineers can submit a report after each visit using the cell phone, therefore eliminating the need to go back to the office to do the paperwork. The managers will benefit by receiving the information faster and will be able to monitor the situation better.

From the functional point of view, the module is composed of:

1. Scheduling module : to schedule/organize a task between the support engineer and help desk.

2. Reporting module : to send a report after finishing a task.

3. Database browser : to query specific information about the case and save to the local database for offline browsing.

4. Mini library/search engine : to query broader information, e.g., manuals, troubleshooting guides, or specifications. It should support offline browsing.

The data transfers that occur in the application can be seen in Figure 14.

Figure 14: Data transfer in a customer support scenario

Overall System Design

There are three main modules in the system that makes the complete customer support system. The modules are:

1. J2ME module : The module that will run on the cell phone and provide wireless access to the customer support system for support engineers. This module provides functions for support engineers to manage their tasks, submit reports, query information, and store data locally.

2. Back-end module (application server and database server) : This module is the back-end of the customer support system and it consists of a database server that stores the data. The module also includes an application server that provides the business logic part of the application to leverage some processing from the J2ME module to the server.

3. Web site module : This module provides the interface for the help desk group and managers to interact with the system. The Web site allows the help desk group to receive client requests and monitor the support engineer's task. The Web site also allows the managers to view the reports submitted by the support engineers and helps them to monitor the best performing engineers. The system administrator can use this Web site to create new users, monitor database activity, and update the databases.

The modules above are the building blocks of many other enterprise scenarios. The difference usually lies in the data that are transmitted. Examples of other scenarios that this enterprise solution can apply are:

• Hospital and ambulatory service : Similar to the customer service scenario, each emergency medical technician (EMT) is equipped with a cell phone that can receive the case report containing the nature of the accident , patient data, etc. from an emergency call to the EMT. The EMT can query information about the patient's history of illness , allergies, insurance cover, etc. from the patient's database in the hospital as well as medical procedures from the medical library using their cell phone. When the ambulance is on the way to the hospital, the EMT can update the medical record of the patient, such as the description of the patient, chief complaints and symptoms, vital signs, respiratory rate, general appearance, treatment rendered, etc., so that the emergency room staff can prepare for the arrival of the patient.

• Courier and delivery service : This service can benefit from the wireless application by allowing better management of the courier workers and dispatching stations . The dispatcher can send new tasks to the courier workers while they are still in the journey. The courier workers can also send back reports about the status of the work and the travel fees using the phone. The back-end system can receive these reports and calculate the workers' payment directly.

Extension to M-Commerce

In our customer support scenario, the support engineers may, on the completion of the task, give the bill to the customer and perform the entire financial transaction over the cell phone. This will eliminate the risk of bad debts and prevent any dispute over the total cost if the customer is invoiced at a later date.

To achieve this, the application on the support engineer's cell phone will allow the customer to contact the customer's bank, issue an instruction to transfer funds to the bank account of the support engineer's company, and then print an electronic receipt for recording purposes.

The suggested security model is as follows :

1. Client authentication: The support engineer's cell phone establishes a connection with the customer's bank server. The support engineer will pass the cell phone to the customer for him to enter his bank account ID and PIN number. Client authentication will take place.

2. Once the connection has been established, two public key algorithms are utilized, RSA (RSA Security, 2002) and the Diffie-Hellman Key Exchange Protocol (Diffie-Hellman Algorithm, 2002). RSA is required to protect the DH Key parameters. In turn, the DH Key algorithm will produce a secret key that will be used for transaction encryption/decryption.

3. The client and server will then proceed to generate the secret key by utilizing the exchanged information. This key will be used in the Twofish (2002) encryption/decryption of subsequent transacted information.

4. A sequence number and time stamp are appended to the beginning of the transaction information. This is required for transaction integrity and the prevention of the replaying of data. A transaction ID is also used to allow the application to determine the requested type of transaction. The transaction ID is unique for a particular transaction service. A client that requests a particular transaction would expect the server to reply with the same transaction ID.