A Case Study of Data Quality in

Eyewear Industry

May 1993 TDQM-93-07

Shirley Lai



Total Data Quality Management (TDQM) Research Program

Room E53-320

Sloan School of Management

Massachusetts Institute of Technlogy

Cambridge, MA 02139 USA

Tel: 617-253-2656

Fax: 617-253-3321





© 1993 Shirley Lai

Acknowledgments Work reported herein has been supported, in part, by MIT's Total Data Quality Management (TDQM) Research Program, MIT's International Financial Services Research Center (IFSRC), Fujitsu Personal Systems, Inc. and Bull-HN.

DATA QUALITY CASE STUDY - "OPTISERV LIMITED"

ABSTRACT: Quality is a critical competitive factor in today's environment, with many firms striving to improve the quality of their products. Because of the impact of quality on market share and costs, quality management has become an important factor in achieving productivity gains and increasing, or at least maintaining, profits. Among others, data quality is one of the hot topics of quality management.

Data quality is fast becoming an issue that is increasingly on the minds of managers and IS executives. It has been written up in trade magazines as an area of concern for CIOs who are ultimately responsible for a corporation's data needs. Articles have been devoted to demonstrating the horrors and costs that poor quality data can generate. Poor data quality can cost a company customers, decrease productivity, or both. Regardless of the outcome, the end result is a negative impact on a company's bottom line.

The following is a case study on a major optical chain store. The purpose of this case study is to provide a view of one company's attempt to deal with data quality issues and to draw some insights from the company's efforts. The name of the company has been disguised upon request of the company's management.

1. Introduction

This is a case study of Optiserv Limited; one of the largest retail eye wear centers in the country. The purpose of the study is to develop a case to obtain a "real world" view of data quality issues that corporations have to deal with.

The focus of this study is on the production process of spectacles. Of particular interest are issues that effect the quality and timeliness of spectacle production in order to identify deficiencies and opportunities to improve the current process. Therefore, the following sections will focus on spectacle ordering, production, and delivery. The process starts when a patient/customer enters one of Optiserv's optical stores and requests a spectacle. This study provides the spectacle process from the perspective of business flow, data flow, and system flow.

The intent of this thesis is two folds. The first is to identify problem areas that Optiserv's future initiative will address and gaps that may exist in the current process. The second purpose is to uncover data quality stories that may have been contributing to the identified problem areas, and to identify any areas of improvement.

The observations that I have documented are from interviews with managers in the system group, lab personnel, and store employees. Therefore, the stories uncovered in this thesis are from the viewpoint of these various groups.

My job was to document as accurately as possible the interviews I conducted. Where there were conflicting opinions I tried to resolve the differences. Where I could not resolve the difference of viewpoints, I noted both party's opinion. Lastly, most issue brought up in this thesis will need further research to validate that a problem or concern should be addressed at a global level. This thesis only serves to uncover the stories, in light of this, solutions and recommendation are not made by the author.

The format of this thesis is as follows. I will first provide an overview of Optiserv Limited. Then I will provide an overview of the spectacle process that will detail the process from the store to the lab. Next, I will discuss Optiserv's current and future system. At the end of each section I will provide observations I have made during my interviews and visit to the stores and lab. Finally, I will highlight the issues in the thesis followed with an alignment of the business, data, and system process and the conclusion.

2. Optiserv Limited

2.1. Optiserv Limited

The optical market is a fragmented multi-billion dollar market. Players in this market consist of chain stores and private doctors. Chains stores represent 2% of the total industry.

Optiserv Limited is one of the largest optical chains with 750 stores located throughout the country. Optiserv provides quality optical products, eye exams, and personal fitting of its products. Optiserv's strategy is to position itself as a low cost producer of quality eye wear. There is no push of brand image. In the chain store eye wear segment, Optiserv prides itself on being technologically advance and introduces new innovations before other large optical chains. There is also a focus on service, in terms of quickness of producing spectacles for patients.

In summary, strategically Optiserv distinguishes itself from competitors through competitive pricing, fashion assortment, convenience of location and hours, and a superior level of customer service. With the new initiative to move to its next generation system, Optiserv is increasing its ability to better serve the customer and to reduce cost.

Through its differentiating factors, Optiserv's mission is to "create patients for life." In a sense, the areas in which Optiserv locates it stores are near areas where the family shops for its household needs. Thus, they are exposed to Optiserv's retail store and when a need for eye care arises hopefully they will think of Optiserv. By fulfilling a customer's needs, Optiserv hopes that it will be able to retain not only the customer for life but make Optiserv the source for the patient and his/her family's eye care needs. Optiserv accomplishes this by obtaining "motivated professional and qualified employees and affiliated optometrists building their careers in an open, challenging and participate environment."

Optiserv's value chains consist of:

- The 750 retail optical stores that sell spectacles.

- The labs that produce the order sent in by the stores.

- The distribution centers/labs that send spectacles out to the stores.

2.2. The data quality initiative

Optiserv is currently undergoing changes to increase revenues and store efficiency. One of its major efforts is to implement a new information system to provide store managers and opticians with more timely and accurate data. The changes and move to a new system is the continued effort of the systems department to improve the internal system for the future.

The outcome of the new system is two folds. It will impact the flow of patient and the selling process. The focus of the system is on streamlining store operations. The first phase of the new system, which is scheduled for completion in 1994, will provide the stores with a more flexible and powerful order entry module and complete on-line pricing information. However, other home office departments, such as marketing and accounting, will benefit from better information capture .

This first phase has been accepted and approved by management. Beyond this first phase, Optiserv's system group is striving for the ultimate redesign of the store's business process. The first phase will include hardware updates as well as the enhancement to the order entry module and pricing information. The user interface is friendlier and the store employees job will be made easier. However, much of the stores business process will remain basically the same.

The ultimate version will move the stores away from is current batched data entry mode and alleviate opticians of many manual tasks. The system beyond 1994 will allow selling and data capturing to happen at the same time; the information will be captured at the point of sale. As a result, the time an optician spends on administrative duties will be greatly reduced and shifted toward selling more to patients. The optician will have more time and more immediate information. Thus the optician is better able to serve the customer and increase sales.

It is with the reprocessing of the store operations and the implementation of the new system that began Optiserv's effort to look into data quality issues. Of concern to management are data that effect the quality, and the timeliness of the spectacles delivered to patients.

3. Spectacle Process

3.1. Store Level

As shown in Exhibit 1, the business process for spectacle production is initiated when a patient walks into one of Optiserv's 750 retail stores. The setup within the optical store is similar to most stores that people are familiar with. The walls are lined with various types of frames. In the center of the room there are stations (dispensing areas) set up for discussing spectacle selection and dispensing of completed spectacles. Located at one end of the room are a cash register and a personal computer. Behind the counter are various machines to adjust and clean spectacles. In a separate room, spectacles are stored for pickup.

Exhibit 1: Existing Spectacle Business Process Flow - Store

Within a store there is an optician, data entry clerk, and manager. In smaller to medium size stores, these titles may be owned by one or two persons who perform all the functions of selling, data entry, and store management. In the stores that I visited one employee served all three functions. Therefore, I have used the word optician wherever I described store operations.

As the customer enters the optical store s/he is greeted by an optician. If the patient needs an eye exam s/he will be handed over to the optometrist. Optometrists are either employed by Optiserv or sub-leased by Optiserv. Currently the optometrist is not integrated into the whole spectacle process in terms of information flow. There is not much sharing of information or data between the store and the optometrist. Also, the optician and optometrist are recording data separately. For example, the optometrist will fill out his/her own prescription data on a Doctor's Form. The optician will then take the data and record it on a Spectacle Rx Form before it is entered into the PC. Thus there is redundant and manual data recording before data entry onto Optiserv's system. However, it should be noted that the Doctor's Form is required by law.

The optometrist will exam the patient's eye and record the prescription on the optometrist's own form; Doctor's Form (Exhibit 2 & 3.) Once the exam is completed the patient is led back to the dispensing area. If the patient has his/her own prescription from an external doctor, the eye exam is bypassed.

Exhibit 2: Doctor's Form

Front Form used by the store's doctor for eye exams. This is not a standard form and is often supplied by the optometrist.

Exhibit 3: Doctor's Form - Back

With a new patient, the optician will sit down with the patient and fill out a Patient Profile form (Exhibit 4 & 5.) If it is an existing customer, the patient should have a file that contains the customer's name and address and "Lifestyle" information. Currently the "Lifestyle" information is only used by the optometrist in considering what type of spectacle the patient will need. For example, if the patient is very active in sports s/he may get a spectacle with polycarbonate lenses. The current system has no way of capturing the "Lifestyle" information and therefore, other departments at Optiserv, such as marketing, have no access to this information. However, according to one of Optiserv's systems employee, the capturing of "Lifestyle" information for other departments has never been a high priority item; it has never been requested by other departments.

Exhibit 4: Patient Profile Form - Front Exhibit 5: Patient Profile Form - Back

Standard Optiserv form used by the store optician to capture patient information.

Patient has not brought in his/her own frame, the optician will help the patient select a frame and a lens type that is appropriate, cosmetically and technically, for the patient. The cosmetic appearance of the frame will depend on the frame style and the thickness of the lenses. Therefore the optician will note the prescription from the exam when assisting the patient during frame selection.

When the patient is satisfied with the lenstype, frame, and accessories, the optician will complete a Spectacle Rx Form (Exhibit 6.) Information from the Patient Profile and Doctor's Form is transferred to the Spectacle Rx Form. From the frame the optician will record the frame code onto the Spectacle Rx Form. The optician will next measure the distance between the patient's pupil and record this on the Spectacle Rx Form. Lastly, using a price list, the optician will calculate the price of the spectacle. When the patient agrees to the price calculated, the patient pays a deposit which the optician ring up on the cash register. The patients then leaves the store and returns when the spectacle is completed.

Exhibit 6: Spectacle Rx Form

Once the process with the patient is completed the optician will either move on to another waiting patient or enter the Rx data into the computer. If there is a patient waiting this patient will take priority and the Rx form is set aside for later data entry; this is normally the case. The entry of the Rx form into the PC is normally batched and entered when the optician has some free time. On an especially busy day this process may be at the end of the day. Regardless of when the optician enters in the order, the Rx form is always entered after the patient has left the store.

When the optician has the time, s/he will enter the Rx form into the computer. The data will reside on the store's personal computer until it is transmitted for processing. The optician will normally do at least two transmissions. One transmission is initiated during the midday to send express orders to the labs. A final transmission is always done at the end of the day to send all orders not yet transmitted to the labs, and to transmit the whole days data to the home office. Any spectacle specifications that are to be sent to the labs for production that night must be transmitted before 6pm, eastern time, for express job and before midnight, eastern time, for regular jobs.

Once an order is transmitted and processed a Rx ticket is generated at a lab for production. The optician will receive a confirmation file from the data center the following day. The confirmation file list all orders that have been received and processed. If the previous days orders have not been confirmed, the PC will automatically re-transmit all unconfirmed orders.

If an order has been successfully transmitted, processed, and produced, the store will receive the spectacles the next day or within two weeks depending on the type of order. The optician will verify the spectacles against the original Spectacle Rx Form for problems. If the spectacle is made to the optician's satisfaction, it is place in a storage room and the customer is contacted. When the patient comes in to pickup his/her spectacle, s/he will have the final say on the quality of the spectacle. If the spectacle is made to specifications, and the patient is satisfied with the quality, the patient leaves with his/her spectacles. After twenty days the optician will follow-up on the patient's comfort with the spectacles. If there are no problems, the process is completed.

3.2. Observations: Store Level

3.2.1 Ineffective Data and Information Sharing

Data concerning a patient's profile and orders are not shared among the retail optical stores. For example, if a patient of an Optiserv store in New York City stops in an Optiserv store in Boston, the optician at the Boston outlet will not know that the customer is an existing customer unless the patient identifies himself/herself as an Optiserv customer. The Boston optician will then have to call the patient's "home" store to have the patient's files transferred from New York to Boston.

3.2.2 Need further research of idea capture process

Unlike data, good ideas that are generated at the store level are shared with other stores. Ideas are gathered by regional sales managers who can implement good ideas in stores under his/her responsibility. At a national level, the territorial directors take ideas from regional managers and can implement them at a national level.

Although there is a process for bumping ideas up from a store to a territory director this process may not be efficient in capturing all ideas and sifting out the good ones. For example, in one optical store, the optician kept patient delivery information in a manual log. The log was successfully used to contact patients on their current spectacle and presented an opportunity to sell another one to the same patient or to a member of the patient's family. The optician at this store obtained this idea when talking to an optician at another outlet.

This log system seems straightforward and appears to be easy to implement. It would seem to be a useful system that can be included in the system and made standard for all stores. However, the fact that this idea has not been captured suggest that there should be further investigation of the idea capture process to ensure there are no holes in the procedure..

After an interview with a system personnel, it was noted that a function to log patients for recall did exist on the system. Why some stores were using a manual process requires further research.

3.2.3 Timing of data entry/response and possible problems

The patient Rx order is usually entered into the system after the patient has left the store. The problem that arises in this situation is that if the Rx is rejected the customer has to be called and notified. If a problem is encountered upon data entry onto the PC, such as an unavailable frame, then the time lost is the time when the patient leaves the store and when the optician enters the order into the PC. Additional time added to the order is locating the patient and talking to the patient over the phone to resolve the problem. Also, the patient may be required to return to the store to select a new frame.

If the Rx is rejected during processing and an error ticket is generated, then a day may be lost because the ticket is generated at the lab and not the store. The lab will most likely notify the store the next day and the store will have the contact the patient. Once again additional time may be spent locating the patient over the phone and the patient may be required to come into the store to fix the problem.

There are two points of possible spectacle rejection. The first is at the store when the PC edit process will reject an order because of a prescription, stop sell, discontinued frames. The second is at the data center when the spectacle's lens measurement is calculated and the prescription can't be made to order; in this case an Error Ticket will be generated. However, the end result is the same, a delay in spectacle production, increase effort on the optician's part to locate the patient and re-adjust the order, and an inconvenience to the patient.

3.2.4 Timeliness of managerial data

Each week a regional manager visits a store to monitor and manage activities that effect the sales of that store. The information the manager obtains is information from the store during the visit. The information may not be timely enough. For example, one regional manager noted that it would be beneficial to obtain revenue and cost data before the store visit. The manager would have more time to analyze the data and generate questions and ideas. The time during the store visit would be spent, not on gathering data, but answering questions or implementing programs and ideas to improve the store's performance.

It was noted by a system employee that at each store, the regional manager can obtain, from the PC, data in summary form for each store under his/her region.

3.2.5 Too many manual references & manual tasks

Opticians have to refer to many manual references to fill out an order. The manuals and forms they refer to when filling out an Rx form include a price list, sellout list, Patient Profile Form, Doctor's Form, and frame list. The result of this is an increased likelihood of human errors during information transfer from a paper source to a form to the system. One optician commented that she spent most of her time learning codes and where to obtain data when she first started at the optical store.

There are a number of areas where data transfer error can occur. The points where data error transfer can occur are:

- When data is passed from the Doctor's Form to the Spectacle Rx Form.

- When data is passed from any paper list (price list, sellout list) to the

Spectacle Rx Form.

- When the Spectacle Rx Form is entered into the data entry module

- When monetary data is transferred from the cash register to the PC.

3.2.6 Store access to spectacle production status information

Optiserv's main lab houses a customer service group that serves the 750 retail stores. The service representatives have access to a screen that gives a history of a spectacle's production process. From this screen a service representative will be able to identify what stage the spectacle is in and estimate the time needed to complete the spectacle.

For example, if a spectacle is in benching, the system will show that the order has been received and is in production. This also indicates that given the time to complete a spectacle in the bench process, about 14 minutes, the spectacle should be completed and shipped the next day if there are no problems during benching.

This type of information is not available to the optician, but would be helpful at the store level. It would add to the optician's ability to better service the patient and allow the optician to keep track of orders that need to be completed on time.

It was note after another interview that the spectacle history was a function that stores use to have, but is no longer available to the stores today.

3.2.7 Ineffective use of special instructions to clarify ambiguity in process.

On the order entry screen, there is a section to enter special instructions for the labs. The data entered in the special instruction area of the PC will generate a comment on the special instruction portion of a Spectacle Rx Ticket that is printed at a lab.

An optician will often use the special instruction section to notify the lab of parameters that the system will not account for. For example, the thickness of a polycarbonate lens can be made thinner than what is calculated by the system. If a patient has an especially high prescription the optician may note in the special instruction that the center thickness should be 1.75mm. The system will generate 2-3mm center thickness. The calculations and special instructions will be printed on a Rx ticket at the lab. The lab's employees should note the special instruction and make the lens according to the special instruction.

However, what may happen is that the lab will make the lens thickness according to the calculations generated by the system. The spectacle will be sent to the store. Upon receiving the spectacle, the optician or patient will reject the spectacle and a remake is sent through with similar instructions concerning the thickness.

The quality and timeliness of the spectacle are compromised. The problem occurs initially because of differences in the system calculation and the optician's calculation. From there a second problem arises when the lab overlooks the special instructions and makes the spectacles according to the system calculation.

The question here is who has the right calculations? If the patient agrees to a lens with a 1.75mm center thickness, should this be the "correct" measurement? Does the system always generate the proper calculations?

According to the American National Standards Institute, the center thickness has to be within a certain regulatory standard. There are legal implications if a patient has problems with a spectacle not made according to ANSI standards.

3.2.8 Internal system doesn't keep track of eye exam - only patients

Currently, the system keeps track of patients who order spectacles, lenses, or frames. However, patients who come into Optiserv for just an eye exam are not captured into the system. Therefore, the optician has no way of keeping track of these patients if a manual log is not kept. One store optician did keep a manual log and used it to call up patient to have their eyes re-examined.

Since Optiserv doesn't capture these customers, they may lose potential sales of spectacles in the future.

After interview a system personnel, it was noted that an exam-only function did exist on the system. This function does track exam-only patient for re-examination.

3.2.9 Problems with code updates

An optician will enter an order and the PC will generate a message indicating that a code for a frame doesn't exist. However, the frame is listed in the frame manual. The optician will call the help desk and notify the help desk representative of the problem. The help desk representative will put the code into the system and ask the optician to issue a "start of day" command. The "start of day" process receives updates from the mainframe and applies these updates to the PC files.

After this procedure the optician will be able to enter the order without an error message regarding the frame. However, two weeks later the optician will enter in an order using the same frame code and the same error message is generated.

It appears that the fix was temporary and the file was not updated.

According to a system employee, this should not be happening and requires further research.

3.2.10 Creative accounting

Stores seem to have developed creative ways to play with the data in the computer. For example, say there is a promotion to push warranty sales which cost $25. The optician sells an accessory for $25. In the accessory sales screen the optician will enter in the sale as a warranty sale instead of an accessory sale. The money is not affected and the optician has a report showing an increase in warranty sales.

This is just one method of manipulating the system. The accessories screen seems to be a popular area for juggling revenue to give an appearance of high performance or to reconcile reports.

3.2.11 Inconsistent function availability

Related to the above observation, the warranty line item on the accessory screen has been disabled. However, some stores still have the ability to bring up and use this line item.

3.2.12 Unfriendly Interface

Visual presentation and the terminology can be confusing to some employees. Help screens and pull down list are not available to help the optician when entering in data. As a result, if an optician is not sure where to enter a code, s/he will usually enter the code in different fields until the system echo's back the code description that matches the actual item the optician wanted to enter. (Exhibit 7)

Exhibit 7: One screen of the Order module

An unfriendly interface coupled with the separation of monetary data between the cash register and PC produced the following problem. An optician must make sure money is rung up at the cash register and entered into the personal computer. A discrepancy can occur if the wrong amount is entered onto the PC. For example, an optician will ring up a sale of an accessory that cost $12.99. With tax of $0.65, the total dollar amount of $13.64. The optician then takes the data from the receipt and enters the monetary information into the PC. The accessory screen will ask for cash rung and tax. Some optician will enter incorrectly, $12.99 and $0.65. Other opticians will enter correctly $13.64 and $0.65. (Exhibit 8)

Exhibit 8: Accessory Log Entry Screen

3.2.13 Lack of training program or enforcement of exiting programs and outdated material

There doesn't appear to be any formal program to train new employees in dealing with patients and using the internal system. One optician mentioned that a part time employee, who fills in for her during her days off, has had to learn everything on his own time. Initially, the optician came in on her days off to train the part time employee as much as she could. However, she feels that the part-time employee has still not been adequately trained. This problem exist in this particular store because of the small size of the store. The optician herself used to work at a larger store and was trained by other opticians in that store.

In terms of system training, a manual and a set of disk is sent to every store. It is up to the store employees to learn the system. However, according to one optician, the manual and disks are outdated; some functions that the manual describes are no longer functional.

According to headquarters, the training information is up-to-date, accurate, and would be helpful if used. Although, some function or codes may have changed, the employee can get a good grasp of the system from the training manual and disk.

3.3. Data Center - System processing

As shown in Exhibit 9 , the system process begins when an order is transmitted to the data center. The IBM and HP computers resides at the data center. When data is transmitted from the 750 outlets, it sent via a third party telecommunications carrier. The transmitted orders are stored on disk at the data center. Each hour the mainframe will read the disk for new order for processing. The Rx record will then be processed into a Spectacle Rx Ticket for one of Optiserv's four labs.

Exhibit 9: Existing Spectacle Business Process Flow - Head Quarters

The IBM mainly serves as a traffic cop and routes messages and data to the appropriate place. Once the Rx transaction is accepted the IBM routes the prescription information to the HP computer.

For example, an order will be entered into a store's PC. Through the communication process described above the orders are sent to the Optiserv's data center for processing. The IBM will check these orders for redundancy and then separates the records into four different files corresponding to an order type. These orders are then sorted and sent to a Hewlett Packard computer for lens measurement calculations. For more detail information on the system process, see the "Optiserv's internal system" section of this paper.

Once in the HP system the orders are processed by OPCAL. OPCAL is a software package provided by an external vendor. Its basic function is to calculation lens measurement for lab production. On the HP sit certain files such as a frame and lens files. With these files and the data provided by the Rx record, OPCAL will verify a prescription and calculate the lens blanks and tool sizes needed at the lab level. If a prescription doesn't verify, it can't be made according to specifications, an Error Ticket instead of a Spectacle Rx Ticket , is generated at one of Optiserv's labs. A prescription is kicked out for various reasons; see the exception handling section of this thesis for more information on Error Ticket .

Once OPCAL finishes its calculations, the transaction is sent back to the IBM to be routed to the appropriate lab for production. The lab where the order is sent to is determine by the type of spectacle that is to be produced and the speed in which the spectacle must be produced. For example, express orders and regular spectacles are produced at the main lab, prescriptions with anti-reflective coatings are produced at a specialty lab. See the "Lab Level" section for more information concerning lab processing.

3.4. Observations: Data Center - System processing level

3.4.1. Discrepancy between files.

It was noted that there are similar files that reside on the IBM and the HP computer. The files in question are the Item Master file and the Frame Characteristic file. The Item Master file resides on the IBM and contains basic cost, frame availability, and price data. The Frame Characteristic file sits on the HP and contains detail specification on the frame, such as size, that is used to calculate lens measurements.

The files are maintained by two separate people who report to the same manager. It is this managers responsibility to ensure that the files are in sync. The IBM file can be easily updated by Optiserv, while the HP file is harder to update. Breakdown occurs when a frame is added to the Item Master and not the Frame Characteristic file. In a perfect world both files would have exactly the same number of frame entries.

3.4.2. Data flow is one way.

Communication is down stream; data flow is one way from retail store to data center then to the labs. There doesn't appear to be much information communicated back to stores through the internal system. A retail store will become aware of a problem with a spectacle production when:

- a customer service representative calls with an error ticket

- the spectacle does not arrive at the store on time

- the spectacle arrives but is not made to specifications.

For example, if an optician enters an order that generates an Error Ticket the ticket is printed at the lab. A customer service representative will call the store to notify the optician of the problem. The optician and customer service representative will work together to resolve the problem or cancel the order.

3.5. Laboratory Level

As shown in Exhibit 10, the lab's production is kicked off when it receives an Spectacle Rx Ticket (Order ticket). Tickets are printed on a printer at the labs. At the start of production, these tickets are pulled and sent in to manufacturing for production.

Exhibit 10: Existing Spectacle Business Process Flow - Lab

Optiserv owns four spectacle laboratories that are located throughout the country. Each lab is specialized in a certain area of spectacle production.

Lab one: The main lab is set up mainly for express jobs. Therefore, it will usually deal with spectacles that use finished lenses. Finished lenses, as oppose to semi-finished lenses, require less production time because these lenses bypass the surfacing process, which is described in more detail later in the section. Most of the spectacle production volume is coming out of the main lab. Although, the bulk of its production is in express orders, the main lab also handles regular orders.

Lab two: Is a specialty lab. This lab will handle spectacles with glass lenses, high prescription spectacles, and other odd ball jobs.

Labs 3 & 4: These last two labs produce some second day express orders, spectacles with plastics or polycarbonate lenses, and spectacles that require Semi-finished lenses.

For the purpose of this study I will concentrate on the main laboratory that handles the majority of the company's spectacle production. This lab is located in a city that serves as the hub of a major express courier. The lab's production resides in a warehouse that stores the inventory and manufacturing groups. The four labs handle between 24,000 to 30,000 pair of spectacles a week. The main lab handles 10,000 to 15,000 of these total orders.

Typically, the lab runs production of regular and backlogged orders during the day. After 6pm eastern time, the lab's express order production begins. For rush orders the stores will have to transmit before 6pm eastern time. Also during the day, employees spend their time making preparations for the nights work, such as inventory stocking and checks. Also, customer service and data entry functions are handled during the day.

A day at the lab starts off with the Rx ticket or Error tickets that are generated by a printer in the printer room (Exhibit 11 & 12.) The main production work process in the lab is broken down into Production Picking, Manufacturing, and Shipping. Employees will pull the tickets from the printer and place the tickets in color coded bins for production picking (Exhibit 13.)

Exhibit 11: Blank Rx Ticket

Blank order form used to print spectacle order or error records.

Exhibit 12: Filled Rx Ticket

A filled order form containing spectacle specifications and special instructions for manufacturing.

Exhibit 13: Tray colors for spectacle production

Production picking consists of picking the material from the inventory listed on the Spectacle Rx Ticket . A production picker will move along the inventory stock to select the frame, frame patterns, and lenses for the spectacles. Once the materials have been picked and placed in a bin, bins are then stacked up and sent into manufacturing.

Once in manufacturing, the spectacles will go through one of two lines. If it is a spectacle that requires finished lenses it will go through Benching and QA. If it is a spectacle that requires semi-finished lenses, it will go through an additional first step of Surfacing before it goes to Benching.

Defective spectacles are brought to a supervisor/manager who notes the defect on a Breakage/Repick Form and determines which group, manufacturing or production picking, is at fault (Exhibit 14.) Until recently, when a breakage occurs during production, someone would go out to the warehouse to pull new materials and send the spectacle bin back into production. The breakage/repick information that was captured was basically used to cost the job out to the appropriate group.

Exhibit 13: Breakage/Repick Ticket

The Breakage/Repick ticket is filled out by a supervisor whenever a spectacle bin is pulled form production. The supervisor will determine the reason for the breakage and decide if it was a result of improper handling by manufacturing or mispicking by production picking. This information is mainly used to cost the job out to the proper group. In the future this data will also be used to determine how to improve the production process.

A recent program has been implemented in the past two months, where production personnel will mark where and when the breakage occurred and the reason for breakage. This information will be used to analyze what types of things are breaking or what areas in the line are having problems. Thus the lab can now take some preventative measures in the future.

The total time required to produce a pair of spectacle is approximately 20 minutes; 50 minutes for lenses that require dark tints. All changes made to a spectacle, such as substitution of lens and frames, should be noted on the Spectacle Rx Ticket.

If a spectacle has no defects a Humphrey Ticket is printed out. A Humphrey Ticket is basically a ticket that is generated at the last QA station. The spectacle is place on a machine that measures the lens prescription and produces a ticket with these measurements. The ticket is thrown into the spectacle bin. Then all spectacles completing the QA stage is sent to shipping.

At shipping a final check is made. The shipping clerk will compare the Humphrey Ticket against the Spectacle Rx Ticket to ensure the prescriptions are the same. If all is in order, the spectacle is wrapped. All materials, such as the color bins and frame patterns, are placed back into inventory for reuse.

The shipping clerk then takes the spectacles and walks down an aisle stacked with different courier boxes. The courier boxes are marked with a store location number. The clerk will place the each spectacle in the appropriate courier box. At midnight all the spectacles that have been completed should be in one of the courier boxes. The courier will then pick up the boxes and deliver them to the appropriate optical store.

In total, QA is done at three stages of the manufacturing process to prevent any defective spectacles from being processed any further. Quality assurance checks are done before the benching process, after the benching process, and before shipping spectacles back to stores. If at any stage of the spectacle production a problem is found, that was not a result of breakage, the spectacle bin is taken out of the process and given to customer service to handle. Customer service representatives will call the store to either cancel the order or resolve the problem and place the bin back into production. See the exception handling section for more information.

At the end of the production day an inventory of spectacle bins is taken to update the computer database. On the side of each bin is a plastic pocket that holds a barcode strip identifying that particular spectacle. Incomplete bins are left stacked at each station; Benching, Surfacing, Production Picking, etc. (Exhibit 15.) At the end of the day, a supervisor, using a hand scanner, will go to each station and scan in the barcode of each bin. The data is then downloaded to a PC for data formatting and uploaded to the mainframe to update a database of open orders.

Exhibit 15: Station Descriptions

For completed/shipped spectacles, the acknowledgment portion of the Spectacle Rx Ticket is detached by the shipping clerks and delivered to data entry. The acknowledgment portion of the ticket also contains a barcode. Data entry then scans in the barcode directly into the mainframe and all information is updated real time.

3.6. Observations: Laboratory

3.6.1. Manual inventory system

Currently, Optiserv has a manual inventory system. A series of books is used and cycle counts are done to keep track of inventory. Each quarter an inventory count is performed by a group of production picking employees who have been assigned to inventory duty. All material such as lens blanks and patterns are handled under this manual system.

The one exception is spectacle frames. There is a VM Inventory system that keeps track of frame inventory. This system is written in Focus and perpetually updates inventory. From the data scanned from the acknowledgment slip (Exhibit 16) for shipped spectacles, the focus program makes a file of frames used and updates the frame inventory file.

Exhibit 16: Acknowledgment Slip

Currently, inventory stocking is done by a team who stocks everything in the morning for production. This team also takes care of reordering out of stock parts. However, often enough for production pickers to take notice, when a production picker goes to pick materials for an order the part will not be in stock. The bin is then placed in an out of stock location and the missing part is ordered.

Problems can arise and throw off the manual system. For example if an order calls for a 70mm lens blank, but it is out of stock, the production picker may substitute this with a 76mm lens blank that is in stock. The problem here is two folds, the substitution may not get reflected in inventory and if not noted the difference in cost is not captured for the different blank size used.

Even with the frame perpetual inventory system, problem in accounting for frame inventory can occur. For example, if changes are made to an order to substitute a blue frame with a like frame that is brown, inventory for the brown frame should be reduce by one and the blue frame inventory unaffected by the order. However, if a data entry clerk doesn't note the change and just scans in the barcode on the Acknowledgement Slip, or the change is not noted in production, the blue frame will be taken out of inventory.

A proposal has been made to develop and implement a PC based program to keep track of all inventory. However, because of limited resources, the inventory system has been placed on a lower priority list.

3.6.2. Mistrust of special instructions by lab - No guidelines for usage.

Some lab technicians do not pay attention to the special instructions on the special instruction area of the Rx ticket. Special instructions are on 2-3% of the orders that come through. The lab technicians feel that special instructions should be used for out of parameter jobs; frames or lenses that have no code. However, the stores are using the special instructions as a default for codes they can't find, as a means to expedite orders, etc.

Because the main lab is an express lab, these technicians feel that a store will fudge with the Rx data to get special orders into the express production line thus speeding up production of the store's spectacles. An optician may also try to use the special instruction to slip an order through the system. The optician will play with the parameters to feed it through the system so an error ticket won't get produced and a good ticket is printed in the main lab. The Rx ticket will have the lens measurement generated from the bogus data. On the special instructions, the real prescription is noted for the manufacturing area.

For example a prescription with a sphere of +5.00 is fed through system. Any prescription with a sphere greater than +5.00 will be sent to a specialty lab. On the special instruction the optician will note that the actual sphere should be +5.50. As a result the following problems can occur:

- Spectacle is made correctly at main lab by technician who follows special instruction. However, this job should have been made at a specialty lab. The result is real main lab jobs may be delayed.

- Spectacle is made at main lab but technician follows specification from system and not special instructions. When the optician receives the spectacle s/he will most likely re-enter the order back into the system as a remake.

- Spectacle is not made at the main lab and sent to a specialty lab. However, there is a delay of spectacle production because of rerouting of job.

With special instructions there are no enforced guidelines for what this section should be used for. Possibly because of "unfriendly" format of the data entry module, an optician who is new to the system, will use the special instructions to record frame and lens information that s/he could not find on the system. The code may exist but because of inexperience with the system the special instruction is used as a default.

3.6.3. Information access/problem recording and reporting

According to lab managers they don't know the priorities and dimensions of problems. Their perception of the major problems may not be the problems that are high volume problems, but problems where the optician yells the loudest.

For example, the customer service area may get 10 calls in a week on a remake of spectacles made with a particular lens. Within the same week the customer service area may get one call on a particular frame, but the optician that calls is terribly upset and makes a great deal out of the complaint. The customer service representative may end up remembering that one call because of the high stress level associated with it, and not the other ten call that dealt with the problematic lens type that generated the most remakes.

The reason for this type of problem assessment is that the lab has no database of problems. The lab is not aware of any reports on breakage, remakes and why a remake is needed, wrong shipments, etc. If there are reports the lab managers do not have access to this type of data. Customer service has recently started logging problems manually.

3.6.4. Disagreement on system calculations

As shown in Exhibit 17, there is some disagreement between the lab and headquarters as to the proper lens measurement and tool calculations. According to one technician in the lab the system is improperly rounding tool calculations needed for manufacturing a spectacle. Rounding problem accounts for 10-15% of all spectacle orders that go through the main lab. This same technician suggests that a file that calculates base curves should be adjusted. Once this file is adjusted, no more rounding problems would occur.

Exhibit 17: Pulled ticket #1

According to a lab technician, the "Tool Pick" calculations generated by the system was "inaccurate" and manually recalculated by on of the lab employees during production.

After further investigation, according to headquarters, all calculations that come out of the system are accurate. Disagreement arises because a lens can be cut a "perfect way" or and ANSI standard "acceptable" way. It is this range that leaves some room for argument and/or discussion. The "perfect way" takes longer than the "acceptable" way. As a result, he lab technician may opt to do it the easier "acceptable" way.

The lab controls and dictates how they actually want jobs made. However, headquarters set up rules and guidelines for manufacturing at each lab site. However, each person at the lab has his/her own specific way of doing job or agreeing on how to do job.

The result is that the quality of the spectacle may be impacted, but the acceptance of the spectacle depends on the sensitivity of the patient. For example, a patient that is not that sensitive may accept the spectacle not noticing the decrease in quality. However, another patient will not accept the spectacle because they are especially sensitive and the difference in quality.

According to headquarters, the issue of lens calculations is a difficult process. However, differences in opinions have been resolved, and the calculations from the system are accurate. To ensure continued accuracy, a meeting is held, each month to discuss lens calculation issues.

There are three entities involved in determining how the system should calculate lens measurements. The meeting is attended by Optiserv managers, the director of manufacturing, and a representative of the company that supplies Optiserv with the calculation software. As a result of these meetings the system should now be in sync and everyone in agreement on the calculations generated by the system. It was noted that, ultimately, the director of manufacturing decides on how calculations are to be made within the system.

Therefore, when someone at the lab makes changes to a measurement on the Spectacle Rx Ticket it is because they are doing it their way and not the "correct" way specified by headquarters. Also, lab employees should not be changing information on tickets, but should pull tickets, note the problem with the calculation, and route tickets to an assigned Optiserv point person within the lab organization for review.

However, there appears to be some breakdown in communication because what is clear to managers at headquarters is not clear to lab employees. See observations below on "Breakdown in communication of guidelines and procedure."

3.6.5. Disagreement on routing of tickets

As shown in Exhibit 18, another problem that occurs is that the system is sending tickets with tool pick calculations that the main lab can't handle. For example, a ticket was generated with a cylinder measurement of +5.00. According to the lab technician, this ticket should have been sent to a specialty lab because the main lab doesn't have the tools to make such a job. The system should have routed the job to the appropriate lab.

Exhibit 18: Pulled ticket #2

This ticket was routed to the main lab. It was taken out of production because of the cylinder parameters. According to the lab, any job with a cylinder measurement greater than +4.50 should be sent to a specialty lab. However, according to the home office, this ticket was routed correctly to the main lab.

However, on further investigation, according to headquarters, the main lab should be able to handle any jobs with a cylinder measurement of +5.00. Once the cylinder is greater than +5.00, then it is sent to a specialty lab.

Once again, there is disagreement between the lab and headquarters on what jobs a certain lab is responsible for. See observation below on "Breakdown in communication of guidelines and procedure."

3.6.6. Breakdown in communication of guidelines and procedure

For the two previous observations it seems that there is a breakdown in communication of guidelines and procedures. After an interview with managers at headquarters they assert that these guidelines and procedures are clear and the lab should be producing jobs that they are rejecting. If these criteria are clear, why is there still disagreement such as those mentioned above?

3.6.7. Discrepancy between what is sold and what can be made.

As shown in Exhibit 19, there is some discrepancy between what can be sold at a store and what laboratories can and will manufacture. For example, PGX plastic Transient lenses are a special lens that Optiserv no longer offers for sale. However, PGX plastic transient lenses are still manufactured at Optiserv's specialty lab.

Exhibit 19: Pulled ticket #3

This ticket was pulled out of production because of the special instructions calling for the usage of "PGX PLASTIC TRA" lenses. "PGX PLASTIC TRA" lenses are not available for sale and the store and should not be specified. However, some specialty labs have the ability to make these lenses and will do so if specified by the store.

If a patient requests this lens and the optician is aware that the lens can be made at the specialty lab, the optician will put the order through. However, because the lens is not available for sale, the code for a PGX lens has been eliminated from the system. Therefore, the optician will code the lens type "single vision" and note the PGX plastic transient lens in the special instructions or in the "tint/color" section of the order.

What happens is that because of the "single vision" code the ticket is generated at the lab that handles "single vision lenses; the main lab. The ticket should have been sent to the specialty lab, who would take note of the special instruction, and make the spectacle with a PGX transient lens.

The ticket will go through regular manufacturing process, if not caught, and a spectacle will be made with single vision lenses. It is caught after the fact; after processing has started on the spectacle or when the optician receives a spectacle no make to order. The result is a remake or a delay in sending the order to the appropriate lab.

Optiserv should either offer the PGX lens at store and manufacture it and there update the system to include a code for PGX plastic transient lenses or don't offer the lens at the store and don't manufacture the lens at the lab.

3.6.8. System generates wrong lens type for spectacles.

One lab technician noted that the computer often list picking of semi-finish lenses even when there are finished lenses, in stock, that would fit the prescription. The difference is cost in sending the semi-finished lenses through the Surface process.

According to the systems area, the mainframe will always pick a finished lens over a semi-finished lens. The system doesn't have access to the actual stock at a lab. However, resident on the IBM is a file of lenses that should be stocked at the labs. There is a way to flag for out of stock lenses in this file, but it is rarely done. If the lab notices that the system is picking semi-finished lenses over finished lenses, this should be brought to management's attention.

3.6.9. No procedure to handle re input of money into the system to re-activate orders

For this specific observation I was unable to contact the store that originated this order. The story that follows is based on one opticians speculation of why an order with "do not make," as shown in Exhibit 20, was generated in the first place.

Exhibit 20: Pulled ticket #4

An order was sent through the system and produced a ticket at the main lab. However, noted in the special instructions are the order to "DO NOT MAKE!!!" the spectacles. Lab personnels do no understand why a ticket was generated if the store doesn't want the lab to make the spectacles. If ticket was not pulled a spectacle would have been produced and sent to the store.

If a patient decides to not purchase a spectacle the optician will go into the PC and cancel the order. When an order is canceled the order is marked as canceled and all monetary sums related to that order is erased from the system.

However, if the patient notified the store too late, and the spectacle has been produced at the lab, the spectacle is be shipped to the store. The optician will contact the patient and negotiate on the price to make the spectacle more attractive to the patient. If the patient decides to accept the spectacle at the new price, the optician will have to reflect the sale by entering the monetary data back into the system. There is a process in place to cancel orders, but no function exist to re-activate an order to put monetary data back into the system. If the money is not placed back into the system, a Pricing Accuracy Report is generated.

However, store personnel have figured out some ways to get around this problem. One store generated a remake ticket for the spectacle and placed a "do not make" comment in the special instructions. This order will place back any monetary sums into the system and the order will not show up in a Pricing Accuracy Report.

The problem is that from the lab level this ticket looks confusing. A lab technician will get a ticket for an order that has special instruction, instructing the lab to "do not make" the spectacles. If the ticket is not caught the lab will produce the spectacle and the store will have a duplicate spectacle that the optician will have to try to sell or scrap.

Another problem related to data quality is that poor data is entered into the system. For example, the remake is not really a remake, but will be shown as one on reports. The lab technicians are further "distrustful" of stores and the special instruction area. This is only one method that a particular store used. There most likely other means of putting monetary data back into the system that also compromises the integrity of the system.

3.6.10. Lost Acknowledgment Slips

Everyday the labs receive a report of open orders indicating orders that are still open, but have been dispensed at the store. The lab uses this report to close out these order from the system.

Based on this report lab managers suspect that the Acknowledgment Slips may be discarded at some point in the spectacle production process. Therefore, data entry never gets the Acknowledgment Slips to update the history of a shipped order.

4. Exception Handling

4.1. Error Tickets

When an order is sent to the HP OPCAL software for lens measurement calculations, the HP sends back one of two records. If the prescription is okay and the calculations made, a Rx record is generated. If the prescription can't be produced as ordered, an error record is generated. At the lab the error record is turned into an Error Ticket. The lab's customer service representative will call the store to notify the optician of the Error Ticket. Exhibit 21 is an Error Ticket that the main lab received for a lens size that was too large.

What follows is the Error Ticket processing procedure:

* Evaluate the alternative and make the appropriate order decision.

* Contact the patient for authorization to change the frame size, lens material and notify patient of delay.

* Make the following changes on the written Spectacle Rx Form of the original order:

- Change the first digit of the Rx number to an "8" (i.e., Rx 512345 becomes Rx 812345)

- Write the original Rx number (Rx 512345) in the "Cancel-Rekey" field of the Spectacle Rx Form. (Do not mark as remake, warranty, or not charge replacement.)

- Write the changes necessary to correct the Error Ticket.

* On the PC:

- Cancel the original order (Rx 512345) using a cancel code of "05" which indicates the order was cancel because of an error ticket. In the comment section note the reason for the Error Ticket.

- Enter the "corrected" order (Rx 812345) as if it were a new Rx using the original date and all the original monetary data. (Do not mark as remake, warranty, or not charge replacement.)

Exhibit 21 - Error Ticket

4.2. Remakes

When a spectacle is rejected by an optician, or a patient, another order is placed in the system as a remake on the original spectacle. The optician will determine the problem with the original spectacle. The optician will fill out another Spectacle Rx Form with the adjustments and indicate on the form, in the "Order Info" section, that the order is for a remake. The order is then entered into the system and marked as a remake so that monetary data are not entered into the system for this spectacle.

There are various reasons for a remake of a spectacle. An error could have occurred at a lab during production; a lens may have been scratched during production or the wrong frame was used. An error could have occurred at the store level; dispensing error. For a complete list of remake reason see Exhibit 22.

Exhibit 22: Remake Reason Codes

5. Optiserv's internal system

5.1. System - Pre '85

Front-End

Prior to 1985 Optiserv's spectacle order data collection was a manual process. A Spectacle Rx Form was filled in manually by an optician. Once a day a clerk at a centralized data facility would call the retail stores at an unannounced time. Data was then collected and verified verbally over the phone. The clerk at the data center would enter the Rx information into a mainframe through a 3270 terminal. Once in the system the spectacle orders, based on the type of spectacle, would be processed for one of Optiserv's four labs.

Back-End

I was not able to obtain information on the back-end processing previous to 1985.

5.2. Current System

Front-End

Exhibit 23 gives a flow of the current process. In 1984 Optiserv implemented a new system that automated its manual data collection procedure. Personal computers were installed in all its retail optical store.

Exhibit 23: System Flow

Although, the optician stilled filled out a paper Spectacle Rx Form, the change in the system allowed data entry at the store site. The store would initiate a beginning and end of day transmission. Also, the store could elect to transmit data to the mainframe at any point during the day. The new system eliminated the verbal process of sending data; in essence the clerk's function was replaced by the store optician and an extra step was removed bringing the mainframe closer to the source of data.

Back-End

The IBM mainframe serves as the traffic cop and routes data to the appropriate place or files. As mentioned, the process is begun at the point when records are transmitted to the data center. Starting at 11am, every hour on the hour, until 10pm, the IBM reads orders from a disk and routes them for processing.

The cut off time for express jobs is 6pm eastern time. If a store doesn't transmit by 6pm, those orders will not be scheduled for that night's production. Priorities of orders are sorted by express orders, remakes, and then regular jobs. Then next sort is by material in the following order, plastic express, plastic remakes, plastic non-express, polycarbonate express, polycarbonate remakes, polycarbonate regular. The OPCAL system can process 500 orders every hour. If there more than 500 orders, express jobs are processed first.

The optician manually initiates a transmission and is ultimately responsible for getting orders to the lab on time. In the future, the PC will automatically initiate a transmission thus freeing the optician from this administrative activity.

Each record that comes into the system is checked against an open order file to eliminate duplicates. Duplicates can occur if a batch is processed twice or the PC transmits an order file twice. There are checks in the system that check for duplicate Rx numbers; an Rx number can't be used again within a three year time period. The HP will catch any duplicates and kick them out as fatal errors. However, on occasion a lab will end up with a duplicate ticket but this is usually because of a problem with the printer. As a result of the in-process checks, duplicate tickets are very rare.

The orders are then split into one of four files. For example, spectacle records are written to a spectacle file, frame only orders into a frame-only file, etc. The main database is updated with data such as frame adds and deletes. These file updates are also transmitted to stores. There is no problems associated with the mainframe file updates. However, sometimes a store will not received an update transmission from the mainframe. (See "Observations: System Level" for more detailed information.)

Once the files and database have been updated, the orders are ready to be sent to one of two Hewlett Packard computers to calculate spectacle lens measurement. Within the system the two HP computers are identified as HP1 and HP2. The two HPs are exactly the same in terms of software and hardware. One machine is used as a disaster recovery machine. Jobs are split between the HPs by the IBM based on established criteria. For example, during peak hours all express jobs will be process on both machines.

If the HPs are not busy, the spectacle records are converted into an OPCAL format for processing. If the HPs are busy, the records are placed into a recycle file to await processing. The recycle file is checked periodically. Records that are waiting for processing are taken out of the recycle file when the HP is freed up for more records.

Once a record has reached OPCAL processing, data is read from the record to calculated lens measurements. OPCAL sends back to the IBM after processing two files. One file will contain records that processed properly and thus will generate a Spectacle Rx Ticket. The second file contains problem records that will generate an Error Ticket. (See exception handling section.)

The files are merged with earlier processed records and sorted. The IBM then adds additional information for good orders, such as materials to pick and its bin location. The orders are then sorted by printer, rush flag, bin number, and store number. This file is then routed to the appropriate printer for printing of tickets that will be manufactured that night.

5.3. Next Generation

The next generation system at Optiserv will include both hardware and software changes that will further eliminate data entry steps and bring the system even closer to its source of data. The new system was driven by the following issues. First, all information was still written onto a Spectacle Rx Form before being entered into the computer. Secondly, pricing of spectacles are often inaccurate. The price quoted to the patient can be either higher or lower than the actual price generated by the system. Thirdly, the price list on the computer is incomplete. Lastly, entry of the data is done after the patient has left the store. If there are any changes that the patient needs to approve, it must be communicated to the patient over the phone. If the patient can't be reached, the spectacle process will be delayed.

In its first phase, as mentioned earlier, Optiserv is implementing a friendly system. Ultimately, Optiserv would like to roll out new technology that will allow mobile computing within an optical store. All the stores will eventually be equipped 486 based PS/2 computers. The PS/2 computers will serve a serve for hand held devices that the optician will use when dealing with a patient. A RF network will be established to link the mobile devices to its server.

With the new technologies, Optiserv's system division will be redesigning its order entry and pricing system to take advantage of these technologies. The price and data entry module were designed simultaneously. Currently the design of the pricing and backoffice order entry module have been approved and parts are being written. The data entry module and RF network are waiting for approval.

5.4. Observations: System Level

5.4.1. File, software, and confirmation update problem

Each day a files containing updates and order confirmations are transmitted to the store. Early in the morning, the stores PC will wake up and run a "start of day" command to receive updates and confirmations. Once the updates are received, a batch program is activated to apply updates to the store's files. Once these updates have been applied, the store should see all the confirmed orders and any frame adds and deletes.

Sometimes a store's file is not properly updated and the optician will have to request a re-transmission of the updates. However, even after the second transmission, the data center is not 100% sure that the store has received all the necessary updates. This same problem occurs with software module updates to the store's PC.

There are many areas where the transmission of updates can fail. It was noted at one optical store that the optician did not always initiate the "start of day" process.

Currently, there is no tight confirmation process today for masterfile updates. A process must be developed so that the data center is notified of completed and applied updates and problematic updates.

6. Gaps Addressed By "Ultimate" System

This case study has produced a picture of the spectacle business process. The observations that were made have been consolidated below. With the "ultimate" system, Optiserv will address some of the areas of concern raised in this thesis. What follows is a chart listing all the areas of concern and the areas that the ultimate system proposal will address has been indicated with an "x" under the "Addressed" column.

Gaps in System Addressed

1 Ineffective Data and Information Sharing x

2 Need further research of idea capture process

3 Timing of data entry/response and possible problems

4 Timeliness of managerial data

5 Too many manual references & manual tasks x

6 Store access to spectacle production status information x

7 Ineffective use of special instructions to clarify ambiguity in process.

8 Internal system doesn't keep track of eye exam - only patients

9 Problems with code updates

10 Creative accounting

11 Inconsistent function availability

12 Unfriendly Interface x

13 Lack of training program or enforcement of exiting programs

and outdated material

14 Discrepancy between files

15 Data flow is one way x

16 Manual inventory system

17 Mistrust of special instructions by lab

- No guidelines for usage

18 Information access/problem recording and reporting

19 Disagreement on system calculations

20 Disagreement on routing of tickets

21 Breakdown in communication of guidelines and procedures

22 Discrepancy between what is sold and what can be made.

23 System generates wrong lens type for spectacles.

24 No procedure to handle re input of money into the system to re-activate orders

25 Lost Acknowledgment Slips

26 File, software, and confirmation update problem

The "ultimate" system is good in addressing the areas that deal with system issues, such as user-friendliness, data sharing, etc. However, it is important to note that some of the areas marked as addressed will only be full addressed if the "ultimate" system is implemented.

The major areas the future system will not address is where groups disagree about the quality of the information generated from the system. These areas require a fix that goes beyond a system improvement and will need to address the policy, procedure and standards communicated throughout Optiserv. The one thing that was consistent during my interviews was disagreement on what data is available and what data is consider quality data. One group may view data generated by the system to be adequate while another group would not trust the same data. The lens measurement calculation is a good example of this. Another consistent point was the "preception" of the lack of data reliable and available from the system.

It must be noted that these areas of concern have been identified after interviewing a limited number of Optiserv employees. Lastly, this case study served to document possible gaps in Optiserv's spectacle business process. Although, many of the concerns raised in this thesis will not be addressed by the future system, further research should be done to determine if these areas need to be "fixed," and if there are any technically and economically feasible solutions.

7. Business-Data-System Process Alignment

In a step to further analyze the quality of the data within Optiserv I aligned the business, data and system. In this paper I have made the assumption that alignment of the business, data, and system processes ensures quality within the company; if any pieces are mis-aligned, then quality will suffer. The purpose of aligning the three processes is to provide an overview of all the processes and an easier way to identify gaps that will lead to poor data quality and overall quality given the structure and interaction of the company's operations.

Exhibit 24 is the Business-Data-System process alignment for Optiserv. In the alignment the business process is supported by the data generated. The quality of the product is only as good as the data that is fed into the process. The better the quality of the data the better the product produced from the business process. Data is generated by the system process. If the system is not able to generated the type of data or sends the data to the wrong people or department, then data quality will suffer.

Exhibit 24: Process Alignment

Exhibit 24(Cont'd): Process Alignment

Exhibit 24(Cont'd): Process Alignment

Exhibit 24(Cont'd): Process Alignment

In Optiserv's alignment, each process unit is broken down into the three levels of business, data, and system. As shown on the Exhibit, business is the first level, that is supported by the second level, data, which in turn is supported by the last level, system. Each process unit is represented by the columns in the alignment. The flow of the process units is set up to flow as the normal operations of Optiserv. The first step is usually, the Eye Exam, followed by Spectacle Ordering and ending with Dispensing. Support functions, such as System Update and Customer Service, are listed after the normal operating steps.

In looking at the Business-Data-System process alignment diagram, its usefulness lies in seeing how a business process is supported by its data and system process. Also, it provides a picture of how each step interacts with other process units. For example, the Eye Exam step is a very self contained step. There is no system support and the data that is generated is manual. However, this manually generated data is critical in generating all the data and product further down the process. Also, note that there is no product flow in or out in this process, thus placing more importance on the data that flows into the next process. The only process that the Eye Exam process affects is the Spectacle Ordering process. This is important to note especially for someone who will be making changes to the Eye Exam process.

This alignment provides a look at a company's operations and the quality within the operations. Note that someone looking at the alignment must have some knowledge of the operations to get some value from looking at the Business-Data-System process alignment.

8. Conclusion

This thesis has uncovered many data quality issues that Optiserv faces. With its "ultimate" system it will address some issues that were raised during interviews with employees at the store, headquarters, and lab level. Although, some issues have been resolved, other issues have not.

The most obvious issues are those that concern behavioral issues. Such as the mistrust of lab personnel of the data entered by stores and the ability of store personal to play with the system in creative ways. This may not be a straight forward data quality problem to the above participants at Optiserv. However, these organizational problems stem in part from problems of data and the employees' mistrust in the quality of the data and its processes. This data quality problem may have led to mistrust expressed by some Optiserv employees.

Once again, the number of interviews conducted were at small optical stores. To get a better picture of a store's operations, future research should include interviews with employees at larger optical stores. T is case study does not end with this thesis and is currently a working paper in the TDQM program. Anyone interested in updated information should visit the TDQM office and request a copy of the working paper.

9. References

Documents

1. Optiserv's 1989 Business flow diagram

2. Optiserv's Future Patient Process Flow diagram - Store level

3. Optiserv's Corporation Department Operations Study

4. Optiserv's Mission Statement - 1990

5. HP System - Batch Narrative

6. Optiserv's Systems Department - System documentation

7. Optiserv's Organization Chart - 4/1/93

8. Optiserv's Error Ticket

- Type and messages

- Count and total for 4/15/93

9. Optiserv's Error ticket processing

10. Optiserv's Codes

- Remake

- Warranty

- Refund

11. Optiserv's reports:

- "Cost of SLOP"

- Reconciliation of Manufactured units"

12. System Strategic Plan

13. Preliminary System/Department impact Analysis Action Plan

Interviews

1. Headquarters - General Manger, Systems group

2. Headquarters - Director, Applications Services

3. Headquarters - Account manager, Systems group

4. Headquarters - Director - Operational Engineering

5. Lab - System Manager

6. Lab - Customer Service Reps.

7. Lab - Production employees

8. Store - Opticians

9. Store - Regional Manger