GISdevelopment.net ---> GITA 1999 ---> Business Applications

Stop your GIS project now!

William J. Meehan
P.E.,Boston Edison Company
800 Boylston Street Boston, MA 02199


Introduction
Boston Edison completed its "classic" GIS on time and on budget on December31, 1996. Big deal! It won the GITA International award in April of 1998. So what? Boston Edison has streamlined its facility mapping operations by an order of magnitude, Yawn. Has it improved the records? Sure. Have applications such as trouble mapping, one call digging applications improved operations. Certainly. Has the GIS investment radically changed the business? No. The reason: GIS is not a business process in the electric utility business. Nor does it directly touch customers. A customer touchpoint is a transaction that involves a direct contact between a customer and the company. A business process ol?en starts with a customer touchpoint and is completed when there is customer satisfaction. Instead, a "classic" GIS project creates a thing, an entity that was not there before. It then has to be managed and fed. Stop the GIS project now, before the thing gets hungrier.

The vision of electric utility GIS projects and the AM/FM projects that preceded them was to add a spatial and graphical representation to facility information. The idea was that this would help better manage facility assets, locate troubles, design new systems and analyze the electric distribution system. A GIS can help visualize information, but to do it effectively, the data must be combined with other information from other systems. So, to meet the vision of a GIS, it must be integrated with other systems. Since a GIS does not serve business process, per se, integration is awkward, since it is often not clear what functions are included in the GIS and what functions are included in other business process applications. This has lead to duplication of data and of functions. If data resides in more than one place, managing changes is tough..

Evolution of Boston edison's GIS project
I wrote the original prototype functional specification for the GIS project (called CAD-Image) in 1986. The first significant activity, the pilot project began in 1989 and was completed late in 1990. Analysis, justifications and lobbying for full implementation occurred during 1991. Full project implementation was authorized in 1992. December of 1999 was to be the original in-service date for the complete system. Thus the total time from original concept to completion would be (if completed according to plan) a whopping 14 years! We accelerated the plan to the end of 1996. The project took 10 years: three presidents, several completed wars, a total upheaval of the electric power industry, at least 5 generations of PC's, the fall and rise of the US auto industry and the deregulation of the telephone industry. The bad news is that after all of that, we still haven't really leveraged the fhll power of spatial information. The good news is that the groundwork has been done. That groundwork is very valuable and of great strategic value. The groundwork looks like this:

Landbase: -600 square miles, dense urban and suburban including the City of Boston and 39 surrounding cities and towns were converted to digital form at an accuracy of plus or minus 2?4 foot. Captured features include street legal right of way, paved ways, building outlines, waterways, railroads, bridges and survey control. It was developed from aerial photography, steriodigitization and city and town assessor maps.

Structures: - poles, manholes, padmounts, duct banks, conduit, vaults, boxes were converted from paper form to digital form and registered to the landbase.

Electrical facilities: - primary, secondary electrical, services and streetlights were converted from old maps, registered to the landbase and structures.

Customers:- meter locations were registered to the electrical conductors

Data Base Structure:- the database structure that defined the relationship of the landbase, street centerlines, electrical structures, electrical equipment were established. The relationship of underground conduit to conductors and equipment was modeled.

Data Maintenance Applications:- applications were created to keep the data and relationships up to date.

Production Applications:- mapping, viewing, plotting, "Dig Safe (underground facility marking for digging contractors) Management", pole inspection, work order posting, underground cable 39 routing and viewing trouble calls were created. These applications live within the confines of our current GIS.

Host Based Structure:- the current GIS consists of host based GIS software running on a mid range UNIX server. The facility attributes are managed by a commercial data base management system running on the same server. The user interface is X-Window based. The user's PC is essentially running a terminal session to the server.

The GIS struggles for acceptance
Despite all the training efforts and data cleanup, the GIS still struggles for acceptance. Here are some possible reasons:
  • The GIS is not a business solution - it is a business foundation.
  • The system is complex.
  • Since the GIS is a host based standalone system, the data is not widely accessible to the casual user.
  • Even though the data is very accurate, it is not perfect. People accept imperfect data from old manual maps, but are much more demanding from digital systems
  • People still love paper. In fairness, paper still is the easiest thing for humans to read. People continue to want maps. While the GIS does a good job at creating maps, it is less flexible than free hand mark-ups of maps.
  • The complexity and volume of the data easily slow down the fastest of processors. In our current host based configuration, the more users, the slower the system. Thus as soon as the system gains popularity, the poorer the performance gets. This follows the old Yogi Berra adage. "No-one ever goes there anymore, it's always too crowded."
  • There isn't a fast way for the data to be corrected from the field.
  • The business process of posting recent field changes is not simple and fast
  • After the "classic" GIS project was completed there were still thousands of un-posted paper work orders.
The finale to this section is that the GIS alone, does an incomplete job of solving business needs and satisfying customers.

The Seven Impeachable GIS Offenses
So, you persist in forging ahead with a "classic" GIS project. Well hereto help are my seven impeachable GIS offenses to avoid:
  • Keep the project going for a long time.
    In my 1997 AM/FM International paper, I outlined the long project liabilities. GIS projects last a long time, and often do not produce significant benefits until long after the project is complete. This will never fly in this period of rapid change and electric restructuring.
  • Keep the system complex.
    People need quick and ready access to the information. One-size fits all applications that are geared for advance GIS users discourage casual users. The idea would be for casual users to be unaware that they are using a GIS or GIS functionality at all. Menus should not contain GIS jargon, such as polygon, arcs, point text, or annotation.
  • Talk up the potential of the system
    The GIS is often sold on potential, instead of actual performance. So statements such as the GIS could do market segmentation analysis or could do reliability analysis lead people to believe that the GIS can do these things right now. Repeating: the GIS is not a business process, it is business foundation. This means that in order to do the analysis, one needs spatial or geocoded data served to a particular application. The GIS alone probably cannot do the application without other information from other sources.
  • Keep the system isolated
    I know of one GIS that has completely converted data, has a suite of applications and is in full operation. Yet a small group of "specialists" run and maintain the system and data. In fact, the old manual mapping system continues to be maintained. The data is not shared by any other system.
  • Let the users figure the system out
    This is a corollary to keeping the system complex. During the initial rollout of the GIS at Boston Edison, we assumed that the users would love and embrace the new system. The software was still new and untested. The users not only hated the system, but they corrupted some of the data as well. Once we figured out that training was so critical to user acceptance, the overall operations improved dramatically.
  • Dump as much data in the GIS as possible
    This-is a carryover from the old AM/FM world. Recall that once upon a time there were two kinds of digital mapping systems that originated from two very different industries. GIS has its roots in environmental and urban planning. ANUFM was rooted in the electric, gas and water industries. The focus of the original GIS'S was on analysis of land, whereas the AM/FM focus was on facilities. The AM/FM system was a natural place to store and manage facility attributes. The outcome was that too much attribute information is managed by the AM/FM system (now called the GIS). The result is that the GIS becomes the de-facto place to store everything and anything about facilities. If the GIS is a closed system, that access to the facility attribute information is difficult. If access is difficult, users will duplicate data elsewhere.
Stop your GIS project now
Stopping the GIS project does not mean abandoning the groundwork..

Stopping the GIS project means this:
  • Stop thinking about a GIS as a thing - a system. - it's hard because GIS stands for Geographic Information System. Our current GIS is a host based stand alone system. While we can import and export information, the system is not architected to serve data and functions to other non-GIS applications.
  • Stop thinking about interfacing a GIS with other systems, like SCADA or work management. The current method of integration is to extract data from one system and import the data into another system. This is in contrast to having an application live independently from any "system" but be able to access data and functionality from the network.
  • Begin to think of serving information to business process applications or customer touchpoint applications from a spatially oriented service.
  • Unbundle classic GIS fi.mctions from the spatial data. Today, in order to use GIS functionality, the user must be in the "GIS environment", instead of in the users own business environment.
  • Continue to convert paper maps and records into digital form. - a "classic" GIS is not a bad place to start storing the information. The groundwork must be maintained.
  • Identify business needs outside of the "classic" GIS that could be enhanced by spatially oriented information.
  • Simplify the data model. The current data model was designed to be managed by a "classic" GIS. So it is structured around "classic" GIS data structures.
Services vs Silos
Historically, information technology solutions have addressed automation of manual functions. Billing, engineering analysis, calculation of energy consumption and work scheduling are examples of utility fhnctions that have been automated for many years. The implementation of these functional applications is generally long, sometimes measured in years. As an example, the first SCADA system at Boston Edison was specified in 1978 and came on-line in 1984. Further, the system requirements needed to be specified in very minute detail. Once the systems were implemented, changes in functionality were expensive, disruptive to the production system and took a long time to make. If the systems were vendor supplied (as was the case with the original SCADA system), changes to the system might even be impossible to make. In the case of SCADA, the vendor went out of business.

Today, the business needs cannot be specified in detail for implementation 1 to 2 years in the future. Often, the business need may change very quickly. Consider that the rules for Electric Industry Restructuring (deregulation) were still being debated on the Massachusetts House Floor in November of 1997, yet the implementation was scheduled for January of 1998 (later moved to March of 1998). Modification to the billing and customer system was difficult because of the its highly integrated and the lack of lead-time on the specific rules.

Historically IT systems have modeled functions. It is not surprising that when a company moves from a functional organization to a process model, the existing IT applications do not fit well. The one dominant feature of the process model is that the company is organized around a business result, not a business function. The business result is often the consequence of a customer request (touchpoint). The other feature is that the business or process unit does not have to own all or any of the services that are required to meet the business result. For example, the process, such as New Customer Connect is supported by services, such as Construction Services, Engineering Services, Accounting Services, etc. Some of those services are owned by the company, some can be purchased externally. Other processes are supported by many of the same services. In all cases, the services have no business need in of themselves. They only exist to support the business processes. In a functional organization, units tend to be autonomous, holding, creating and controlling all data, creating projects, and then handing off intermediate results. Data and information is often duplicated from one functional group to another.

Similarly IT systems that are modeled after functional groups tend to be autonomous, hold, create and control all the data needed for the applications and often contain redundant and sometimes inconsistent data.

A characteristic of a functionally organized IT architecture is that data handling and applications tend to exist together.

In contrast, an IT architectural framework to support a process model would look like this:
  • IT applications drive toward the business result. For example, a business process might be the development of an estimate of outage time.
  • There may be supporting services that are provided by other applications and data. Those services might be database, scheduling, timing, real time services, or weather services. None of the services need to be owned by the business process applications.
  • The services are provided to the network and are available to other non-related business processes.
  • Data creation and maintenance does not have to be owned by the business process application. Data about trouble calls may be part of a process called "Collect trouble call information." Data about geography can be created from geographic services. One would not want to manage geographic data within a trouble call information process, nor should trouble call information be managed from within a geographic service.
  • Regardless of where the data is created, the data shall be available to all business process applications. The concept of systems "talking to each other" is analogous to hand-offs in a functional organization. Hand-offs are where most errors are made, where communication fails, where efficiencies are lost and where customers get lost. Single results focused business applications that dip into the network for data and services don't require hand-offs.
The plan
So here's our plan:

Create a Transition Architecture for GIS
The current GIS actually consists of two production servers. One server is called Titan and is located adjacent to the mapping/drafting technicians. Its function is to record as built changes from field notes and work orders. So the duty is heavy into data editing. It also is used to create the paper maps that are distributed to the field forces. Every week, the data is reconfigured and copied to a second server, called Europa. This server is used essentially as an application server. The data has been optimized for viewing. Field applications use this server for viewing and using the data. No data editing is done on this data.

The transition looks like this:
  • Convert the viewing/application machine to open client/server architecture. All data elements are then stored in an open format, managed by a standard data base management system in a much simpler data structure. This new machine is renamed the "Spatial Server." No GIS application is run on the server.
  • Adopt the notion that GIS functionality can be unbundled into special single purpose mapping objects. These objects can be integrated into applications with standard linking mechanisms.
  • Mapping objects will be integrated either into new applications or existing business applications. Or if geo-locational data is needed it can be served directly from the database.
  • Current GIS user applications (exclusive of the editing functions) will either be created, eliminated or integrated into other non-GIS systems.
  • Later, the editing server will be converted to client/server architecture. The editing functions will be unbundled from the data. Editing functionality will be added to business applications as appropriate and new unbundled editing applications created.
Street Lights Pave the Way
The first business application that utilizes this model is called StreetLite. It went on line at the end of 1998. One of the process units is called Community Lighting. They identified specific customer touchpoints. One particular touchpoint was a customer's report of a street light out. The business redesign identified a need to locate the customer geographically and have the customer identi~ which street light is out. The customer representative could then show street lights in relation to the customer. In effect, the customer representative could be viewing the same information as the customer. For example, since the rep is viewing a map showing the customer's house, the street and street lights, the rep could ask if the street light, they are referring to is the one across the street and to the left of their house. Since not all street lights are owed by Boston Edison, the rep could immediately noti~ the customer that the street light would be relamped or could help the customer contact the owner of the street light. A customer touchpoint application was created that:
  • Identified the customer
  • Captured the customer's request
  • Made and recorded the commitment to the customer
  • Created a work order (if required)
  • Reserved any material
  • Scheduled the job
This was not a GIS application. It did however directly access geographic data services and utilized geographic functionality. It also accessed other information from other sources. It generated messages to other databases. It was structured around solving a particular customer request without burdening the users with information or functionality that they didn't need.

Summary
Stopping your GIS project does not mean stopping any of the activities associated with a "classic" GIS project. It doesn't mean pulling the plug on all funding. It certainly doesn't mean that if your GIS project is already done, you've wasted your time and money. What is means is that a project needs to be developed in the context of meeting business needs and customer touchpoints. It cannot be an end in of itself. Ideally, corporate business architecture should be developed that matches the business needs and customer touchpoints. This will better identify the IT needs. As those needs get flushed out, those business processes that depend on spatial and geographical data and representation can be served not by a GIS, but by network. A new entity, yet to be named, then will serve geographic data and services to the network for all to use.
© GISdevelopment.net. All rights reserved.