Logo GISdevelopment.net

GISdevelopment > Proceedings > GITA > 1997


GITA 2002 | GITA 2001 | GITA 2000 | GITA 1999 | GITA 1998 | GITA 1997
Sessions

Advanced Technical Topics

Building & Supporting Applications

Business Evolution & Platform Migration

Expanding the User Base -- Non-Traditional Applications

From the office to the Field

Fundamental & Economic Issues of AM/FM/GIS

Lessons Learned

Major Technology Trends and their Impacts

Project Planning, Implementation and Management

Re-Engineering and Integration Issues

Scada and Real-Time Systems

User Project Presentations

Best of the Rest

Invited Presentation


GITA 1997


Building & Supporting Applications
Printer Friendly Format

Page 1 of 3
| Next |


Want to build A GIS? The proof is in the prototype

Russell D. Chandler
President, GeoData Solutions, Inc. 8620 Wolff Court, Suite 250 Westminster, CO 80030
email: rchandler@geodata-gis.com
http://www.geodata-gis.com


Abstract
As AM/FM/GIS platforms have matured into their “next generation”, it is now much easier to create a working prototype AM/FM/GIS system and realize significant benefits in just a few months. Nothing generates more ideas and eventual corporate buy-in than real, working, demonstrable applications. This presentation will describe the process of identi~ing, defining, and developing fast return applications of an AM/FM/GIS system. A few case studies within the electric, gas, and telecommunications industries will be discussed.

Introduction
Essential to building a top notch AM/FM system is obtaining sufilcient tiding as early as possible. In this age of competition, justifying large expenditures strictly on the basis of cost benefit analyses, which are often very drawn out, is becoming increasingly more difficult. Cost benefit analyses are not inexpensive. In the end, what you windup with is lots of paper, nice slide show presentations, but very little benefit to actually demonstrate. As AM/FM/GIS platforms have matured into a “next generation”, it has become increasingly easier to utilize limited “investigation” budgets to actually create a working prototype AM/FM system that can realize a significant return on investment in just a few months.

Where Should I Start?
Where one starts is to a large degree dependent upon where the main user sponsors reside in the organization. On the one hand, efforts to build comprehensive, integrated GIS, driven mainly by the information technology group, often fail. On the other hand, when individual user departments have moved toward automation on their own, the goals have usually been too narrow and the tools too specialized to allow for future integration and efficiency. It is by now obvious that the more integrated and automated the technology processes within an organization are, the more efficient, cost effective, and competitive the organization can be. Visionaries among us realized this quickly and in many cases were given the opportunity to embark on this venture. Unfortunately, the venture was premature. The tools were too primitive and the organizations unready to meet the challenges. One thing that we learn very quickly in large organizations is that it is very difficult to get everyone to agree on things. In the past, it was necessary to bring several departments together and perform a long, detailed analysis before attempting to develop any software. Struggles over symbology, dictionary definitions, and departmental roles in the GIS would often paralyze the development, and result in splintering. 86.~ilecomprehensive approaches have ftiledor haveusually noteven beenseriously attempted (smart), theneed fortechology wittinthe userdeptiments hasintensified. Thetendency has been toward most of these departments spawning their own CADljob design systems, map production systems, home grown analysis programs, and entirely independent outage management systems (reality). This has resulted in increased automation for the individual departments, but has not introduced any real organizational efficiencies. Redundant database maintenance activities continue to persist, just as they always have. The lesson here is that in order to achieve true success in automation, the drive toward GIS in the company needs to come more from the users of the system - not the information technology group, and not even the mapping department, but the engineering planners, designers, and operations personnel. Without one of these departments driving the process, it will be prone to failure. Fundamental to the early success of a GIS project is how responsive it is to its initial charter. There is no point in trying to build an all encompassing system if the needs of the primary users are not met. Likewise, when building a GIS from the ground up, the overall vision for the organization should not be neglected.

Just do Ittm
From this point forward, I will proceed on the basic assumption that GIS technology is a keystone for the organization. Most organizations do not have the time nor the money to spend these days to try to justi~ it to the masses. Instead of spending the limited time and budget available on an enormous and politically risky effort to justi~ large expenditures, it is better instead to take advantage of the opportunity to prove something first. Limited cost-benefit analyses are useful, but for the same costs, a working system can be developed and implemented using the newer technology available today.

Here are the basic steps to building a usefid, working prototype in a short time:

Step 1. Briefly Identify Users and Applications and Pick One to Start
Step 2. Gather Basic Requirements
Step 3. Data Model with Awareness
Step 4. Prototyping: Designing on the Fly
Step 5. Implement the Imperfect Solution
Step 6. Take the Show on the Road

Step 1. Briefly Identifi Users and Atmlications and Pick One to Start It is not worth spending too much time and money identifying/justi@ing applications to the organization. The general “big ticket” application areas of GIS are well known: planning, design, and distribution automation. The primary applications within these main groups are network analysis, job design and estimation, work management, outage analysis and dispatch, and business geographic analysis. Notice that automated mapping was not listed. Mapping and database maintenance, however, is still a good entree application and therefore a good candidate for prototyping. The requirements fortheoverdl system, however, should not bedriven offtieneeds of mapping. Instead, the mapping function should be redefined as the corporate GIS database maintenance function.

Page 1 of 3
| Next |

Applications | Technology | Policy | History | News | Tenders | Events | Interviews | Career | Companies | Country Pages | Books | Publications | Education | Glossary | Tutorials | Downloads | Site Map | Subscribe | GIS@development Magazine | Updates | Guest Book