Closing the work order loop with GIS
Once the compatible units and assembly units are determined, compatible unit details are added
to the mix. The details contain the specific information related to the compatible units. There is
one compatible unit detail object for each compatible unit. The detail object contains the total
cost of the materials, the total labor hours required to perform the requested operation on that
compatible unit, all related indirect labor, and the accounting information used to allocate costs
to corporate accounts.
Associated with each compatible unit detail is a record containing the material information for
that compatible unit. These are compatible unit material records, and there is one material record
for each unique material contained in a compatible unit. Each record contains the quantity of that
item required, a unique symbol number, which is the key used in the material data base for that
item, a description of the item, and the cost for each item.
After all of the facilities, design points, tasks, compatible or assembly units, compatible unit
details, and material objects have been created, the estimate for the order is derived. As
mentioned, each compatible unit contains a list of materials and labor for completing a task. At
estimate time, all of these materials and labor are added together to end up with an estimate for
the order. Standard labor and material overhead percentages are then added to the initial estimate
to arrive at a total dollar and time estimate for the order. The planner can then modify the design
if necessary until the desired results are obtained, and then the materials and labor figures are
passed onto the systems which track those components
Most of the information used for developing the estimate, such as the compatible and assembly
units, is self-contained within the GIS. However, there are two pieces of information which
change on a regular basis. These are the material costs, and the labor rates. The labor rates
change according to the bargaining unit contract, and the material costs are updated monthly.
These costs are stored on the mainframe in hierarchical IMS databases. We are currently using a
manual process to update this information in the GIS. We determined that given the amount of
data we needed to retrieve, our ACP process would be too time-consuming. Our goal is to use
ODBC to access this data in a real-time mode.
Order Tracking
Now that the estimate for the order is complete, the emphasis switches to tracking the order.
There are several systems that are used to track the order. Our scheduling system, WOTSS,
tracks the stage of completion of the order. The Material Information Management System
(MIMS) tracks the materials actually used on the order. And the Work Management System
(WMS) tracks the time spent working on the order.
Since WOTSS tracks the stage of completion of the order, there are several checkpoints in the
process within GIS when information must be sent to WOTSS. For internal orders initiated in
GIS, we notify WOTSS when the order has been started. For all orders we must notify WOTSS
when the planner has completed the design of the order. We must also notify WOTSS when the
order has been turned over to the construction department to begin work, and then again when
the construction has been completed. It is not imperative that these notifications be done in a
real-time mode, so we simply write transactions to our GIS server and then use File Transfer
Protocol (FTP) to retrieve them into a mainframe file where they can be used to update the
WOTSS DB2 databases. Since we first developed our procedures using FTP, a new IBM product
called MQ-Series has become available. MQ-Series allows systems to transfer data between
platforms and can also be used to initiate jobs at those platforms. We may switch to MQ-Series
for these transfers after we evaluate the product.