Andrew D. SwensonCity
of Indianapolis, Division of Planning 200
East Washington Street, Suite 1841 Indianapolis,
Indiana 46204 Phone:
317-327-5132 FAX: 317-327-5103 Email: aswenson@indygov.org/aswenson@iquest.net Mapping Your
Documents: Issues
Integrating GIS with Document Management Abstract: The Division of Permits of the City of
Indianapolis - Marion County, processes over 70,000 permits every year. Since 1995, this agency has made major
investments in three major types of software in conjunction with a major
business process reengineering effort.
The Division has invested in their Building Permits Client-Server
software, their City/County GIS System and in a Document management system for
storing and retrieving records.
Bringing these three systems together has required the resources of
several different agencies and the complex integration of at least four
software packages. This paper addresses
some of the key technical and management issues involved in creating a
workable, combined system. The subject of
this paper is a City of Indianapolis project that involved the integration of a
GIS system with a document imaging system for building permit documents. The timeframe of this project spans almost
the entire decade of the 1990s, from 1992 to present. There have been three stages of implementation: a planning stage
(1992-1994), an initial implementation stage (1995-1997) and a secondary
implementation stage (1998-2000). The
final stage of the project is still in progress. This project has
already involved three agencies, four different Permits Division
administrators, four project managers (one internal and three from outside
firms), two different major systems integrators, six data processing service
providers, two scanning vendors, and at least five different software
manufacturers. The financial
scope of this project is large as well.
Our contractual costs for document imaging from 1995-1997 amounted to
about 1.1 million dollars. Our annual
systems support costs since 1997 have been about $150,000 while our annual
scanning expenditures have been from $150,000 to $200,000. The proposed costs of converting the data
required for the systems integration effort has been estimated at $174,000. In summary,
this has been a significant project involving a large number of people and a
significant investment by the City of Indianapolis. Who
We Are and What We Do This project
has involved three City divisions. The
Division of Permits is a joint operation of the Department of Metropolitan
Development (DMD) and the Department of Capital Asset Management (DCAM). The
Current Planning Division is solely a division of DMD. The Division
of Permits’ work is regulating the development of land in Marion County.
Permits Division processed over 70,000 permits last year (1999). These permits include structural and craft
permits for construction, zoning review approvals, wrecking permits, permits
for connecting to sanitary sewer locations and permits to dig in the street
rights-of-way. As a function
of the permit issuance process, the Division of Permits reviews and approves
land use, landscaping, sewer and drainage plans for new subdivision
development. Since the early 1980’s, we
have processed approximately 250 new subdivisions per year in Marion County. In addition to
permit issuance and development review, the Division is responsible for two
other important development activities.
First, the Division monitors permit and land use compliance. They perform over 50,000 inspections per
year. Finally, the Permits Division
issues and monitors builder and contractor licenses. The Division maintains active licenses for between 6000 and 7000
individuals as contractors or contractor representatives. The Current
Planning Division’s work is establishing and maintaining the rules for land
development in Marion County. Current Planning staff process approximately
2,500 land use petitions each year. While some of these processes allow for
administrative actions, most involve a public hearing process. There are
separate petition processes for rezoning, variance approval, special
exceptions, subdivision platting, and right-of-way vacations. Our
Documents To support our
land development regulatory activities, we process approximate 60,000 new
documents per year containing some 225,000 pages. Many of these documents, such as permit applications, are
generated internally. The public,
however, generates our larger documents.
These documents include building and site plans. These plans average about 11 pages per
document and normally are drawn on C, D, or E - size drawings. To support the review process, we require
applicants to submit three sets of plans.
Because each set of plans may contain different sets of comments, we
sometimes maintain all three sets. Following
Indiana State records guidelines, we retain paper documents for three
years. Prior to 1995, we would
microfilm the paper documents, store the images on either 16mm or 35mm
microfilm, and then destroy the originals. Before destroying any copying and
destroying any record, we are required to obtain the approval of our County
Records Commission. Since 1995, we have
secured approval from the County Records Commission and the Indian State
Archivists office to replace our microfilm process with our document imaging
process. Why
use a map to index your documents? Before
getting into detail discussing the development of the City’s GIS and Document
Management systems and their integration, we must first address the question:
Why? Why use a map or other geographic
description to index a document? The
concept of creating a mapping index for documents came from observing Division
of Permits’ staff practice. While records were kept in either case number order
(petitions), address order (structural and craft) or project name (industrial
cases), the primary index or finder systems to these records were sets of maps. Figure
A is an example of one of these map finders. In this case, the map was used to
record the location of industrial projects in the city. The typical map finder
was based on maps developed for the City by the Sanborn Map Company in 1954 and
updated by the City's Planning drafting section through 1987. The Public Works
department for their maps used a different set of base maps. Figure B is a
photo showing a rack of these maps.
Map
indexes were not built for all records.
Building and maintaining a map index was costly. The manual mapping index systems required
frequent update. In some cases, the case or project location was recorded on as
many as 4 different map indexes. Individual staff members kept their own
records to indicate the location of the projects they handled. The
existence of a map-based index for a particular document set was related to the
need for document retrieval. Map indexes were not built for records that were
less important such as structural records or for the non‑zoning, land use
petition records. For these less
important records, an address for each case or permit was used as the primary
index. As
we explored the Division’s use of map indexes and their respective document
sets, we discovered several reasons for automating the practice. From a practical perspective, location is
often the most effective way of locating a document. Because development documents contain so much information, the
geographic location is sometimes its simplest index. And, while the location might be the simplest index, the
geographic location might be fairly difficult to describe. The more complex or difficult the geographic
location, the more appropriate a map is for describing that location. Often, permit
review depends on one or more spatially dependent regulatory documents.
Municipalities often have historic districts, well field protection areas,
zoning restrictions and other regulatory regions that control the nature of
activities in those areas. Legally approved documents describe the regulations
and recommendations for those specific geographic areas. Some departmental documents such as plats
and rezoning documents contain additional development requirements. A full
spatial indexing of the appropriate regulatory and administrative documents is
necessary to enable staff to make appropriate recommendations. Map-based
indexes are an effective way of establishing maintaining non-geographic
associations between two documents or sets of documents. As new permit documents are submitted, a
GIS system can allow staff to efficiently add non-geographic indexes, such as
subdivision project numbers, to the new document. This is a tremendous aid to finding associated documents
later. In a way, this is analogous to
creating a virtual file folder for a project.
Complete spatial indexing of both the new permit document and the
appropriate project documents gives staff a better chance of creating this
association. To summarize,
the benefits of using a map-based or GIS interface to create a geographic index
to a set of documents depend on the importance of a document set to the
permitting process and the complexity of the geographic attributes of the
permit activity and of the document set.
The decision to create and maintain a map index should, therefore, but
made based on the risks of not creating a given index; how often a
mistake might be made without the index and the potential cost of that mistake.
Early
Systems Development (Before 1992) Permits Automation The City of
Indianapolis established its first automated permits systems in the late
1970’s. This system was an IBM showcase
system and cost between 4 and 5 million dollars to develop. The County Information Services Agency
developed the application in the COBAL programming language. The system helped manage structural and
craft permits, permits inspections, and contractor licensing. By 1991, it
was apparent that the Permits system had become obsolete. The system had not
been expanded to accommodate other permits or even common permits review
functions, such as the site zoning review required for each permit. Separate systems for that process and other
permits, such as ROW excavation and sewer connection permits had sprung
up. By 1992, there were at least 5
separate automated systems generating permits. GIS While the
Permits Division was developing its automated tools, the development of another
automated tool, GIS, was taking place along a parallel path. The GIS base map
for Indianapolis/Marion County was developed as a part of the Indianapolis
Mapping and Geographic Infrastructure System (IMAGIS). This photogrametric-based, vector GIS data
set was initially delivered to the City in 1989. The City’s use
of GIS tools was prompted by a need to support better wastewater
management. Those agencies responsible
for storm water management, transportation, and long-range city planning also
became quickly involved. The permitting
and regulatory divisions were not initially involved. Over time, however,
because of the scope of the City’s GIS system and the desire for the City to
leverage its GIS expenditures, new systems initiatives began to be scrutinized
to see if they would ‘fit” with our GIS systems. When the Permits Division began looking for a new automated
system in 1992, GIS staff played a key role in the eventual selection of the
software. The DMD’s use
of GIS began with zoning. Very
gradually, the DMD GIS staff developed the ability to maintain the electronic
base map. By 1992, Current Planning
staff were relying on the GIS staff to run difficult petition legal
descriptions and input subdivision boundaries.
The pressing need to maintain the zoning base maps led to efforts in
1992 to update the 1987 zoning maps using a CAD system fed with data from the
GIS system. Because of funding issues and some experimentation, this project
would not be completed until 1995. Imaging During the mid-1980’s
Permits’ management began to realize that much of the information not stored on
that system was stored on different permit documents. Permits’ therefore began considering the use of the emerging
document imaging technology with the hope of someday managing our paper
documents in a digital environment. The Permits
Division actually had money budgeted for the development of document imaging as
early as 1991. The Permits Division put
off that investment in deference to an enterprise-wide document imaging
coordination effort. Another agency,
the County Recorder’s office was selected as the initial pilot in that effort
and the Permits Division waited. Management
Initiatives 1992-1994 Business Process Reengineering (BPR) While our new
automated permits software was selected in November of 1992, the Permits
Division did not actually begin using that software until March of 1996. During those four years, the Division
underwent a full-scale reengineering process. The primary catalyst for applying
BPR to our permitting process was a constant pressure to reduce staff that
began with a hiring freeze in 1990 and culminated with a large-scale downsizing
in 1992. Approximately 30% of staff positions in the Planning and Permitting
Section were eliminated between 1992 and 1995. This steady attrition severely
limited the ability of staff to perform many of their existing tasks. As a part of
the BPR process, the City held a three-week workshop involving all permitting
staff in January of 1993. That workshop
eventually resulted in the realignment of all permitting functions. During that workshop, both permits
management and technical staff examined the information systems and information
processes required for processing a permit. The consensus developed during that
workshop formed the basis for the introduction of document imaging technology
to the permits process, highlighted the need for systems integration, and
provided a focus for that integration – customer service. One addition
result of the BPR process eventually had a significant effect on our document
imaging process. Before the BRP
process, we were handling nearly 500,000 document pages per year. During the January 1993 workshop, Permits
staff identified numerous instances of form duplication and began a process to
redesign all permit forms. The result
was dramatic. As a result of this
process, the number of document pages dropped by 50%, to about 250,000 per
year. This drop made the costs of
moving to document imaging much more feasible. Outsourcing There was
another business trend influencing IT implementation at the City in 1994. In
that year, the City administration announced its desire to outsource the
provision of IT services. The services
to be outsourced included mainframe, midrange and desktop computer support,
network support and applications development.
The administration’s position was that IT services were not a core
function of local government. This
administrative position had a significant impact on the City’s implementation of document imaging. Building
an Imaging System, 1994-1998 Beginnings In the early
1990’s, the author was a GIS systems analyst for the DMD Long-range Planning
Division and was a DMD representative to the 1991 enterprise-wide effort. Part of my responsibilities involved
looking at zoning and other land use petition layers and potential applications
for those layers. During 1994, an
examination of potential zoning related applications revealed that much of the
information require to make effective rezoning decisions was stored either on
paper or on microfilm. Combining document imaging with GIS seemed to be a
logical way of increasing user access to that information. First, though,
we had to build an imaging system. What Kind of Imaging System? A full
examination of the appropriate steps required to design a document imaging
system is beyond the scope of this paper.
One of the most basic decisions that must be made, however, concerns
whether one intends to use “live” or “retired” documents. A system that
supports the development review activity by moving an active (or “live”)
document in a workflow requires a much more robust system than a system that
houses an archive of historical (“retired”) documents to be used for research. One must be aware,
however, that while the system demands of an archival and research system are
less than that of a “live” document system, a research application may require
far more records to be converted before becoming truly effective. This
requirement has the effect of increasing both implementation time and
cost. Because we already had serious
systems support issues in the spring of 1994, we opted for a “retired” document
or historical application. Potential Benefits The most
precious commodity in the development community is time. Our retrieval time for historical documents
on microfilm is anywhere from 30 minutes to 4 hours. If the document is checked out, the retrieval time may approach a
week. For cost-benefit purposes, we
used an average of 3 hours. We also
estimated that we do about 7000 document searches per year. We predicted
savings of approximate 1 hour per search.
This would amount to about 3.5 FTE of our organization’s time or about
$105,000 per year (assuming an FTE worth $30,000). In a traditional cost-benefit analysis, that might be considered
to be the total benefit. However, we
felt that the customer’s time was more valuable than staff time and a
legitimate benefit variable for a city agency.
We calculated an expected benefit of $35.00 for every hour of customer
time saved. At 1 hours of savings for
7000 searches, savings to our customers would amount to an additional
$245,000. In addition to
time-based savings, we used two additional benefits to justify our document
imaging efforts. The first concerned flexibility of document retrieval. We wished to be as flexible as possible for
the delivery of public services but were constrained by our need to access our
physical records collection. In
addition, we estimated that eliminating the space required by physical document
storage of our records would give us approximately 1000 square feet for
servicing customer needs. Finally, we
were concerned about the preservation of some of our records. There was a perception that our records collections
were in poor condition. Permission was
granted in the fall of 1994 to evaluate the condition of the land use petition
files with the aim of converting those documents to an accessible digital
format. The collection was in fairly
good condition. Some items were in
disrepair, but the record set was fairly complete. The collection of finders, or map indexes was functional as
well. There were, however, numerous
zoning map indexes that were in various stages of disrepair. The decision was made in late 1994 to
proceed with an RFP for a system to convert these documents to an appropriate
digital format. Request for Proposals An RFP was
developed in the spring of 1995 and was somewhat unique in its approach. The RFP did not contain hardware and software
recommendations. Our internal MIS
agency had no expertise in document imaging and the attitude of the
administration tended to discourage the creation of an entire new functional
group of city employees. Instead, the
RFP contained a request for a set of professional services that would
constitute what would today be considered an Application Service Provider or
ASP. The RFP contained a request for
document scanning and indexing services and for the storage and provision of
electronic access to those scanned documents.
We received
three responses to our RFP. The winning
RFP was a three-year proposal with the local systems integration group of a
regional accounting firm. Under the
original contract, which ran through December 1997, this firm was paid a
monthly service fee together with a unit fee for scanning and indexing the
documents. For the service fee, the
firm purchased, set up, and administered the hardware and software necessary to
provide document access to the City.
The firm also hired that scanning firm and managed the scanning of City
documents offsite. Project Implementation Our first
crisis came shortly after the contract with our vendor was signed. The document imaging software did not have
a way of creating a multi-key index.
One of our primary indexes was property address, a significant multi-key
index. Our vendor was able to create an
Oracle-based, client server solution to this problem in less than thirty
days. Once this new
system had been created, our vendor was ready to implement on site, but had to
wait about twelve weeks for appropriate personal computers and monitors to be
purchased, for new network lines to be established and for supporting index
data to be assembled. In addition, the
City had completed outsourcing their data processing operations on January 1,
1996 and was planning for the major permit system implementation on March 6,
1996. The imaging system had to wait. Once the
document management system went live on March 6th, 1996, conversion
began. We converted about 3 years worth of building permit records in 1
year. In the late summer of 1996 we
began converting zoning and other current planning documents, beginning with
paper records from 1992 and microfilm records from 1985-1991. We did these back-file conversions of old
documents at the same time as we processed new documents. As of March of 1997, there were
approximately 3 million images representing approximately 200,000 documents. We had our
first major project glitch as a result of the scanning of the microfilm. The vendor scanned far more microfilm than
we had asked them to. This resulted in
both a budgetary problem and a processing problem. We eventually agreed to accept the scanned microfilm, but the
slowness of the delivery and the difficulty of carrying out quality control on
the processed documents delayed the acceptance of the scanned records until
March of 1997. This delay in acceptance
led, in turn, to a major payment problem that was not resolved until early
1998. On Our Own At the end of
1997, when the original contract ended, the City took possession of all
software and hardware. This meant that
the City also had to take responsibility for the administration of those
systems. Our original vendor had found
an excellent local vendor to replace the original scanning vendor and we
continued our relationship with them through a direct contract. It was not until the spring of 1998,
however, that we were able to establish contracts for software maintenance and
for document imaging systems administration.
We had
intended to continue working with our original vendor for the ongoing systems
administration and systems integration work on the system. Unfortunately, that vendor fell out of favor
with the City administration, and we were not allowed to contract with
them. We found some local assistance
through our scanning vendor and continued to look for new solutions. We were ready for systems integration. GIS
and Document Imaging, 1998-2000 In the summer
of 1998, the Permits Division received another push from the administration to
reduce the number of paper documents used in permit review. Eventually this led to the involvement of
our GIS vendor. Interestingly, our GIS vendor had been the consulting agency
for our enterprise document management project in 1991. The City made
a major new investment in the document systems, both in terms of software and
hardware, but also in terms of conversion.
We upgraded all of our software and completed important systems
administration agreements with our MIS firm.
During the fall of 1998, we also converted all zoning and land use
petition documents generated from 1993-1997.
Once again, we
had a problem absorbing all of the converted data. The problem lay in our ability to provide an expedient quality
acceptance program. This led to long
delays in our acceptance of the scanned documents. This time, however, we avoided the financial problems that we had
encountered in 1997. Beginning in
1999, our GIS vendor began a project to fully integrate our GIS, Permits and
Document management systems. Called the
City of Indianapolis Integrated Information System or CIIPS, this new effort is
based on four pieces of software; our permits software, our document management
software our GIS software, and a new software package that the author
discovered at a conference in the summer of 1998. That software package provided the link between our GIS package
and our document management software. CIIPS is
essentially complete as of this writing, although we are currently (May 2000)
having difficulties with our document-imaging server. We believe that these problems will be solved by the middle of
this summer and that the Permits and Current Planning divisions with have full
access to the document-imaging portion of the software. A number of enhancements to the application
are planned for either this fall or for the first quarter of 2001. Summary Our systems
tests have indicated that we will achieve our initial expectations. In fact, with the additional GIS integration
to the Building Permit systems that our GIS vendor has implemented, some of our
searches are taking between three and six minutes. The system has an addition
potential to save more money as it tightens up the variance in document
retrieval time by removing search extremes due to lost or checked out
documents. If we began saving an
average of two hours per search, the system would have a full payback for our
customers in a little more than four years ($1.96 million in benefits in four
years versus approximately $2.0 million for total systems development and
operations so far). We have begun
the process of making our system “live”: creating a workflow of active
documents. As a part of that effort, we
have begun exploring the submission and management of digital development
plans. We are examining the continually changing nature of documents. We already process 60% of our right-of-way
permits using a web-interface to our permits system. Many of our existing tools will support this effort and we are
cautiously optimistic about our ability to implement the concept. We are also
actively working at putting our documents in the field. That too, is an ambitious enterprise and
will need to wait for us to improve our ability to provide just the right
documents at just the right time for the right inspector. One way of describing this system might be
“Just-in-Time Docs”. For now, we
are busy finishing our integration efforts.
Our data cleanup should be finished by late fall of 2000. Once we have
cleaned up our data, we will be able to fully evaluate the impact of our
combined systems on our customers. Because our current imaging file server will
be obsolete at the end of 2000, we will have to purchase a new server. Purchasing a new service may trigger a new
data conversion effort. The final
lesson of this project should be that there is no end. Even as project steps are completed,
technology and business changes move rapidly.
To deal successfully with rapid change requires the patient dedication
of staff and management to customer service and the careful selection of good
partners. To date, we have been
fortunate enough to have all of these elements of success. Acknowledgements I would like
to acknowledge the cooperation of Division of Permits staff, especially Rosalie
Hinton and Rhonda Fields during the compilation of this paper. I’d also like to thank current project
manager Kathleen Cain of the Convergent Group for her timely information. |
|
||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
