Closing the work order loop with GIS
Walter J. Bird
Niagara Mohawk Power Corporation
300 Erie Boulevard West
Syracuse, NY 13202
Overview
At Niagara Mohawk, as at any public utility, the construction order process is very important to
the economic viability of the organization. Since rates are based upon installed capital plant, the
sooner the material can be capitalized, the sooner the company can recoup the expense. When we
first began investigating Geographic Information Systems (GIS), we envisioned a system that
would simplify and speed up the entire construction order process. While we are not completely
where we would like to be, we have made significant improvements by utilizing our GIS, and we
have concrete plans and goals which will further improve the process. We have encountered
obstacles along the way, both technical and procedural. We have worked through these obstacles
and are well on our way to having an integrated, fully functional work order process.
There are five components to our work order process; order initiation, construction design and
estimating, construction, order tracking, and order completion. Gis is involved with all but the
construction phase. There are a number of computer systems, both mainframe and client-server
based, supporting the various phases of the process. To meet our work order integration goal, we
had to interact with these systems in both real-time and batch modes.
Order Initiation
The first step in the order process is identi~ing the need for construction. This need is identified
either internally or externally. External orders are those requested by customers or government
entities. Internal orders are requested by someone in the company either to support load growth
or to replace equipment nearing the end of its useful life. Before GIS was implemented, all new
construction orders, whether internal or external, were initiated in our Work Order Tracking and
Scheduling System (WOTSS). External orders were entered in WOTSS by a customer service
representative as the customer described the work they would like done. Internal orders were
entered in WOTSS by the individual planner or by the planning supervisor in each planning
department.
WOTSS is a mainframe based system, and when beginning an internal order, the planner was
first required to log into the mainframe system to initiate the order in WOTSS, and then log into
GIS in order to begin the design process. This caused a problem since both systems use the same
data. For these internal orders, the goal was to perform the entire initiation process within GIS
and eliminate the need for the planner to use both systems. This goal turned out to be more
involved than first anticipated, since there are several steps in the work order process where
information is entered in WOTSS, and also because WOTS S interacts with several other
mainframe and client-server systems. Performing the initiation function within GIS required that
GIS had to duplicate the interactions with these systems.
Our first solution to the connectivity problem was to use an Alien Co-Processor (ACP) written in
Smallworld Magik code. This ACP enabled us to use a C++ executable to attach to the
mainframe using a Sybase gateway. Once attached to the mainframe, we were able to execute
SQL calls against a SYBASE database that in turn accessed the DB2 databases. We also use an
ACP to invoke stored procedures to access the order number information created by the client-server
based Corporate Project Accounting System (CPAS).
