Work Management/GIS Integration: The Next Generation
The following is some of the functionality WIN includes:
- The ability to collect information for customer requests for service, including electric service,
service investigations, and streetlights. This module is extensible, and will easily
accommodate future expansion into other business areas.
- Job and Work Plan setup; for NEES, the Job provides a means for satisfying service
Requests. Work Plans are representative of the engineering design work necessary to
complete some aspect of the Job. After assigning Requests to a Job, the engineer creates and
edits a Work Plan, including both work management ‘setup’ and GIS engineering design.
Once design is complete, a WIN process divides the work by type (poles, wires, etc.) into
what NEES calls Work Orders, for eventual scheduling and completion.
- Crew Scheduling and Time Posting are used to assign crews to specific work, and later to
post time to the Job. Scheduling is based in part on the work location, utility District, and
type of work. Timesheet information is extracted via an activity-based accounting process,
and uploaded to a Time Entry/Payroll System.
- A Project Estimation module enables cost estimates to be generated on a per-Job or per-Work
Plan basis. Estimates are calculated using a complex estimation engine that can
accommodate numerous accounting variables.
- The catalog of work management compatible units (CU; company or industry-standardized
units of materials and tasks) is maintained via a special maintenance module. NEES terms
their CU list the “Picklist”. The Picklist module is used to create and maintain Picklist
materials, tasks, and services. It is also used to maintain how the Picklist menus appear to the
user in the application, as well as how the menus and submenus behave when acted upon.
In addition to these core functional modules, WIN is fully integrated into NEES’ legacy
environment. This includes interfaces to Personnel, Accounting, Purchasing and Materials
Planning, Warehouse Management, Payroll, Vehicle Usage, Productivity, and Streetlight Billing
systems.
Prior to the decision to implement a GIS with integrated Work Management, NEES utilized WIN
within a process that included primarily hand-drawn paper sketches. CAD systems were used at
the NEES companies for producing primary distribution feeder maps, detailed conduit prints and
for substation detailed design drawings.
Challenges and Goals
The project’s magnitude and scope presented new challenges and obstacles to overcome. The
overriding challenge was to integrate a new, state-of-the-art GIS system with a work
management system that capitalizes on the advantages offered by a GIS: namely, geospatial, or
location-specific feature attributes, and the possibility of real-time, up-to-the-minute information
about those features. The work management embodied in WIN goes far deeper than the map; the
goal of extending the GIS advantage to WIN required that the Picklist compatible units be driven
by feature during the engineering design process. The GIS had to incorporate and supercede
many processes currently part of WIN and other applications. Yet prior to the GIS, WIN was
already a fulcrum for many other legacy systems. For the integration to work, WIN had to be
developed to “plug into” the GIS and still provide the connections to existing external interfaces.
A major business goal for this project was the very important functionality of generalized
Requests. This involved assessing how Requests for various service types are handled today, and
looking for ways to streamline the process. Generalizing Requests included putting the focus of
work management on the customer, and meant that WIN needed the ability to utilize both the
landbase and facilities management functionality of the GIS to tie the work process to the
customer’s location. Included were issues of facilities ownership and the need to connect the
Request-taking process to the mapped NEES service territories. By taking advantage of GIS
service point location information the Request-taking process can also be decentralized; any NEES employee may take the Request
regardless of physical office location or NEES district affiliation.
A major addition to WIN3 was the integration of Streetlight Requests. This integration effort
required the coordination of WIN3, the GI S application, and external interfaces to the Customer
Information System (CIS) as well as an existing Streetlight Billing application. The existing
legacy streetlight request and inventory systems, which were mainframe-based with Year 2000
compliance issues, needed to be replaced with a combined WIN/GIS system. This proved to be
one of the most challenging aspects of the integration.
Getting Started: The NEES Business Obiect Model
Prior to the requirements kickoff for GIS with WIN integration, NEES invested several person-months
in developing an object model of their core business requirements. The business object
modeling exercise proved vital for determining a development path for the next generation of
WIN. It aided in identifying and refining key business needs and core fi.mctionality.
Subsequently, the business object model has driven many project aspects.
Many times, a necessary outcome of the process of introducing a major new system such as GM
invokes Business Process Reengineering. Whether the business intends or desires to reengineer
or not, some process changes will be required. Business object modeling, such as that done by
NEES, is an invaluable tool for facilitating and preparing for these inevitable changes. Ideally,
the basic modeling process should occur before planning the GIS implementation. Because WIN
had been in use for some time, many of NEES’ business processes had already been explored,
defined, and implemented.
The object model approach also facilitates extensibility. NEES explored various scenarios for
their Request-taking process to insure that future additions to the types of service they might
provide could be incorporated. A solid object model design means that new service types can be
added without having to redesign the application’s Request-taking process.
