Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 1998


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997 
Sessions

Application

Data Distribution

Data Evolution

Field Applications

Integration of the Enterprise

Invited Presentation

People Issues

Scada and Real-Time systems

System Development

User Presentations

User Solution


GITA 1998


User Presentations


Trouble-call Management: An application solution


The old way
One of the main drawbacks to the old system was the way the information was handled. In most cases, a call was received in the Distribution Center and recorded on a paper document called an “X-Order.” (Why it is called an X-Order has been lost to time, but apparently this term came into being way back in City Water history.) The X-Order was given to the dispatcher, who called a crew and assigned the job. If the call was received somewhere other than the Distribution Center, call details were written on a notepad and the information relayed to the dispatcher by telephone, where an X-Order was written and a crew assigned. In either case, the X-Order was then placed in the supervisor’s in-box and handed to the crew at the end of the day. Carbon copies were kept of all X-Orders at the dispatcher’s desk as a method of tracking unfinished jobs.

Once the crew completed its work, workers would make some notes about what they did on a scrap of paper. These notes were then transferred to the X-Order. The supervisor would review what the crew had written and assign another crew to do follow-up work if necessary. If another crew was required, the X-Order was routed to the next crew for completion, and so on, until the job was completed. The completed X-Order was given to the dispatcher, who paired it with the carbon copy and filed it for future reference. One of the many problems with the old paper system was that an X-Order maybe stuck in the paper shuffle for several days following completion of the work before a supervisor or dispatcher would become aware that follow-up tasks were necessary.

Strategies to meet the work requirements
A water quality complaint, if handled improperly, had the potential to create a public health hazard. It became clear that the old system was deficient and City Water needed a better way to respond to and track water quality complaints. A timely response to a taste and odor complaint could prevent a major system incident. City Water decided to require a response to all water quality complaints within the same business day. One of the main tasks of the new system would be to ensure this goal was met.

One of the main requirements of a new system was to keep track of important jobs without having to shuffle paper or check piles of X-Order copies to find something. Another requirement was to have the ability to cut down the number of times information was written and copied from one source to another. This was accomplished by having a central data entry point for all calls and by connecting the dispatcher to this data store.

In the past, procedural standards and policies were committed to memory. Depending upon the situation or who was involved, the same type of call could be handled in several different ways. To bring a measure of consistency to the utility’s responses, a new system was required to contain guidelines and procedures for handling various types of routine calls and water quality conditions.

Finally, data were needed to analyze the trends of unsuitable water quality in the system and to allow engineers and operators to make system adjustments in response. This made the case for using a database to store the call data, enabling decision-support querying and analysis.

Page 2 of 6
| Previous | Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book