Closing the work order loop with GIS
All projects at Niagara Mohawk are tracked using a six-digit work order number. This order
number is assigned in CPAS. We needed to access this order number in a real-time mode, and
the ACP made this possible. However, it can be slow, and because of the large number of
transfers and bridges used, it is not recommended for large amounts of data or large numbers of
transactions. We are in the process of investigating the use of ODBC connectivity for our real-time
connections. ODBC reduces the number of data transfers between platforms and should
simplifi the real-time transfer of data.
WOTSS is our order tracking and scheduling system, so whether an order is external or internal,
the order information must end up residing in WOTSS. This requirement meant that for the
internal orders being initiated in GIS, we had to pass some of the order information back to
WOTSS. This is again done with an ACP. Once the orders are contained in WOTSS, there is no
difference in how they are tracked.
Design and Estimating
Afler the order information has been entered, the actual design phase begins. At Niagara
Mohawk, we recognized early on the power and flexibility we could gain by using a graphical
interface for designing construction orders. Prior to GIS, the design and estimating function was
performed using an old, but very efficient mainframe system, the Construction Management
System (CMS). CMS enabled the planner to specify all of the material and labor required for
each construction order, but did not allow the planer to actually “see” the order he had just
designed. Using our Smallworld GIS, the planners see a visual representation of the work that is
being done. By using a variety of colors and shapes, the planner and construction crew can easily
determine the facilities and type of work required at each location.
After the design phase is completed, the next step is to develop a cost estimate for completing the
construction project. Since the facilities already exist in the GIS database, the challenge is to
derive the materials and labor from those objects. In order to do this, we developed an
Automated Construction Estimating System (ACES). ACES is based on a concept in use at
Niagara Mohawk for 15 years called “design points”. A design point is a physical location where
one or more “units of property” have been installed or removed. A unit of property is any facility
that must be tracked individually within our property records database. Examples of units of
property are poles, wires, and transformers. If there is more than one unit of property object at a
specific location, for example a transformer mounted on a pole, there will still be just one design
point at that location.
At each design point there maybe more than one task. A task is assigned to every unit of work to
be performed. For example, in our above case of a transformer being mounted on a pole, there
will be a task for installing the pole and another task for installing the transformer. If there is
conductor being installed on that pole, there would also be a task for installing the pole hardware
required for the installation of that conductor.
Now, to complicate things further, each task may contain either a compatible unit or an assembly
unit. A compatible unit is a self-contained module describing all of the materials and labor
required to perform a task. For example, a pole compatible unit contains just the pole for
materials, and an estimated time for the operation being performed with that pole, whether it is
installing or removing. A compatible unit for a crossarm would contain the crossarm itself, and
all the miscellaneous hardware used to install that crossarm to the pole, as well as the labor
required to install or remove it.
An assembly unit is made up of two or more compatible units. They are useful when the planner
knows that a commonly used group of compatible units is required at a design point. Instead of
entering the compatible units individually, the planer can specify one assembly unit that contains
all of the desired compatible units. An example would be a riser assembly unit which contains
compatible units for the riser assembly, and the connections required to attach the underground
cable to the overhead conductor.
Compatible units have been in use at Niagara Mohawk for over 15 years. Because our current set
of compatible units is still being used by the mainframe estimating system, CMS, we did not
want to make any changes to the compatible units we already had. In order to select a compatible
unit for each facility in GIS, we developed a matrix of fields on the GIS objects with related
information for each compatible unit. A good example is how we select pole compatible units.
We determined that the selection criteria for poles were height, material, and class. When we
look for a pole compatible unit, we just look for one that has the same height, material, and class
as the object on the GIS map. If we installed a forty-foot, class 5 wood pole, the selection criteria
narrowed down the choices to our PW405 compatible unit. The operation for that unit is
determined by the status of the pole. In this case, “Install” would relate to an “IN’ operation for
the compatible unit. In the case where the selection criteria could not pick just one compatible
unit, we made one of the units the default, and gave the planner the ability to choose a different
one if needed.
