GISdevelopment.net ---> GITA 2000 ---> User Perspectives

Document management systems in utilities

William F. Muench1 & Milton Y. Omoto2
1Hawaiian Electric Company
820 Ward Avenue, P.O. Box 2750, Honolulu, HI 96840

2Convergent Group
6399 South Fiddler's Green Circle, Suite 600,
Englewood, CO 80111
Hawaiian Electric Company serves the island of Oahu, including the city of Honolulu, and has an interest in about 75,000 poles in its system, of which over 50,000 are jointly owned with the local telephone company, the City and County of Honolulu, and/or the State of Hawaii. HECo first started on the DMS trail in 1995 when it made a decision to replace the existing 25- year-old mainframe joint pole records database and paper filing system with a more user-friendly and companywide accessible database. This led to the selection of a DMS to realize the vision of a totally electronic database and reporting system for the 100,000 pole records in the system. An internal task force team made up of end users was formed to guide the company’s joint pole automation effort. This resulted in a fully operational DMS system in 1999, which is now being viewed as a pilot that can be expanded to provide document management capabilities to the entire corporation. This joint pole archival records system is different from other archived records systems in which less than 10 percent of the records are normally accessed. In this system, older records are more likely to be accessed because of pole deterioration. All of these records will be accessed sooner or later.

The way we were
In the preautomation paper product world, HECo’s Joint Pole (JP) system included a combination of three types of records:
  • Some basic pole information data that were being maintained on a 25-year-old mainframe flat file that could only be used to produce keypunch cards
  • Type-written, multicopy transaction forms and drawings that were kept in folders for each pole transaction going back to 1972
  • Microfilm and microfiche records of pole installations that extend back for the 60 years prior to 1972
Paper records included manually typed notices of construction to other pole occupants, acceptances, completion notices, billings and other miscellaneous correspondence, along with the sketch or drawing of the work order. A JP Coordinator is responsible for all correspondence with other pole occupants, including everything from monitoring job status to final billing when the job is closed and filed.

Every pole is individually identified with a number and corresponding street name. Each time a pole or anchor requires either maintenance or replacement, a new work order is assigned, referred to as a Joint Pole Application Number. An engineer would first obtain the pole identification number from a map and then find the keypunch card file which referenced the latest JP application number. From there the search was reduced to finding the appropriate file draw and folder. The engineer would then create a new application, work order and drawing using the existing data as a guide.

The main shortcomings of the old system were:
  • The data was coded and could not be directly read from mainframe printouts.
  • The database was not capable of performing queries.
  • Keypunch cards contained limited information.
  • Other pole information was keyed in but could only be extracted through the use of special report generation programs from the non-relational database.
  • Searching previous records for the pole location required that the clerk first find each record to determine the previous application number
  • In some cases this would mean digging up five or more records in succession (including a time-consuming microfilm search) to get the complete history of a pole location.
  • Records and correspondence were manually typed on multicopy forms and physically delivered by daily courier to external joint pole owners.
  • Items like pole restoration and CATV came after the old mainframe program was developed and was not included in the database; this information had to be hand-written onto each keypunch card.
  • Records and drawings were physically deteriorating and were being lost and misfiled by users.
  • Engineers, maintenance crews and other users located throughout the company's service area who needed access to these records were required to come into the main engineering office where over 35 filing cabinets held the microfiche, records and drawings.
Project start up
After forming a task force and acquiring the services of a consultant to assist in the planning and implementation phases, work began on developing a DMS strategic implementation plan. The objective of the Joint Pole Automation Project team was to:
  • Replace the old mainframe system.
  • Bring records into Y2k compliance.
  • Improve accessibility and file retrieval time.
  • Decrease manual filing effort.
  • Eliminate lost files and documents.
  • Develop a system that could be expanded to include other DMS applications throughout the company.
Our project was divided into four phases:
  1. Preliminary study and strategic plan
  2. Database design and conversion
  3. DMS selection and implementation
  4. Back file data conversion scanning
Preliminary study and strategic plan

Cost Benefit Study
The first step in the project was to determine whether a new electronic system was going to be beneficial. While benefits were intuitively obvious to those who worked every day with the existing system, conducting a cost-benefit analysis was a necessary step to “sell” the project to senior management to ensure adequate and continued support and funding. Work Flow Analysis

Along with a work flow analysis on JP procedures, we also looked at how to use the new technology to possibly improve the way we had been doing business and to incorporate these ideas into our plans.

Database design and conversion

Database Design
The basic database design and report forms were then laid out along with a general idea of how the new computer screens would look and work. This would serve as the basis for the applications programmer in his design of the system. We finally decided to allow our own IS personnel to do the programming for this phase rather than to outsource the effort
  • Because the IS department had previously selected MS Sequel Server as the standard database of choice, the team did not need to evaluate new databases.

    The IS department preselected Powersoft Corporation’s PowerBuilder for report and forms generation. Old existing data on the mainframe was migrated to an NT server into the new relational database .This was followed by several months of testing and tweaking both the data and the PowerBuilder programs.

    Document management system selection and implementation

    Document Management System
    The work flow analysis portion of the project revealed that considerable time was spent by engineers and others in searching for JP pole drawings and sketches. The biggest surprise we found in our cost-benefit analysis was that while the cost of scanning approximately 50,000 drawings was high, the benefits of on-line availability of drawings also offered the biggest “bang for the buck.” Our approach was to scan only drawings initially, with the remainder of documents (approximately 10 to 15 different document types per file) to be scanned at a future date. So, concurrent with developing and testing the JP application database, the team prepared specifications for a document management system.

    Web-Based Technology
    One of the more recent enhancements to DMS technology that helped reduced costs was the ability to access files through a Web-enabled application using one of the many commercially available browsers that now come with PCs. This workstation access through the Web is referred to as a “thin” client, and does not require a licensed software installation at each workstation. The full software installation workstations are referred to as “fat” clients and are usually only for the system administrator and, in our case, the Joint Pole Coordinator and Clerk. The project team determined that the DMS system would require:
    • The look and feel of a Windows-based application
    • Compatibility with our Windows NT environment along with the MS Sequal Server database
    • A Web server interface through which documents and drawings could be viewed
    • The ability to view .dgn files
    • Elimination of the folder icons in a search mode (A browse feature for 100,000 records would have been unbearably cumbersome.)
    • Scalability to develop into an enterprise configuration
    • Meeting AIIM DMA industry standards
    • Printing, plotting or faxing directly from the Web interface
    • Adding future enhancements such as work flow
    • Licensing on a concurrent user basis for the thin clients rather than per seat
    With specifications in hand, the team evaluated six vendors of DMS systems. After a formal vendor evaluation process, the team selected Filenet’s Panagon product. With the recent trend of many DMS software vendors to use value-added resellers (VARs) as a means of deploying their products, the team ultimately found themselves dealing with a VAR that represented the selected software product. The VAR was then responsible for obtaining software licenses, configuring, installing, testing and maintaining the product for at least one year.

    Back file data conversion scanning
    The next phase of the project was to develop conversion specifications and to select a scanning conversion vendor for the 50,000 plus JP drawings, convert the drawings, and bulk load them into the DMS system. An evaluation of local and mainland conversion vendors identified a West Coast scanning vendor with the best price and performance. The scanned drawings were converted to .tif format by the vendor, which can then be read by several different viewer plugins. Drawings that had been created in Intergraph’s Microstation at HECo since 1995 were directly filed into the DMS database in their native .dgn format. The JP clerk can now scan any other documents at her workstation. We also discovered it was more cost effective to airfreight our entire files to the mainland and back than to use any of the local scanning vendors in Honolulu. All file cabinets were actually loaded on pallets, shrink-wrapped, and air freighted to the mainland scanning vendor, and then back to Honolulu.

    So what does IT do?
    The finished product now provides everyone in the company access to the Joint Pole System from their own workstations. From our AM/FM mapping system, a pole number is identified and entered into a query screen which can then bring up all the jobs (joint pole application numbers in HECo’s system nomenclature) that were ever performed on that pole location, listed in descending chronological order. All pertinent pole data is also presented on the first Pole Information Screen, including pole size, class, material, treatment, occupants, and date of installation. Other screens can be reached by “drilling down” including acceptance forms, anchor details, and so on.

    A button on the screen also allows the viewer to launch the Filenet DMS application through the Web via Microsoft Internet Explorer, which in turn will pull up the appropriate drawings and documents on a selection dialog box. We are also using a “plug-in” viewer on client workstations that do not have Intergraph’s software installed in order to view .dgn files that the Panagon DMS viewer cannot recognize.

    User groups vary from the engineers and construction crews, who access the system daily, to other departments such as Legal, Claims and Plant Accounting who may visit it only once a month. Total number of users is about 75, usually with no more than 10 accessing the data at any one time. Different user groups have different levels of access security to these files, which is controlled by the JP Coordinator. Because these are all archived files, access security is limited to “view only” except for the JP coordinator who has total access.

    The new joint pole system also allows the JP Coordinator to instantly generate various types of reports from the database. Among these are various status reports of the current pole repair jobs, cut-over notices, delinquent responses from the other pole occupants, and a multitude of year-end reports required by agencies such as FERC. Other studies can now also be instantly performed, such as listings of poles that are repeatedly involved in accidents and listings of poles by material or treatment type to study which type is giving the longest life.

    Back to the future…so what's ahead?
    Now that the system is up and running, HECo is proceeding with other enhancements:
    • Permitting the engineers and crews to make direct entries and to initiate JP applications without passing through the JP coordinator
    • Until we get more familiar with the system, most of the workflow presently passes through the JP Coordinator.
    • Additional programming to the AM/FM system to activate the JP system by clicking on the pole. This was originally envisioned in the AM/FM system design, thus every pole in that system has a “hook” on it.
    • Electronic connection through the Internet with the external joint pole owners and occupants. This will involve some security issues with HECo’s firewall that still need to be resolved.
    • Expansion of the database to include pole inspection, maintenance and treatment results.
    • Expansion of the DMS system to include other departments such as the Survey Department, where the company’s easement documents and drawings are kept; Standards, Legal, Claims and Accounts Payable Departments are also interested in using the DMS.
    • Expansion of the electronic filing of remaining Joint Pole documents on file. We found that this will actually be less expensive and be more readily accessible to users than the previous method of microfilming.
    Among the alligators

    Red Wheels
    These are issues that muddy the water without really having anything to do directly with the project. In the utility business, the buzzwords these days are down-sizing, reorganization, partnering and competition. HECo is presently involved in all four:
    • Downsizing is presently restricted to natural attrition. The effect of downsizing on this project was that we did not have adequate resources to do the converted document QA/QC that we would have liked.
    • Reorganization has been ongoing for several years, and has had some effect on this project in that we went through two different vice presidents and two different managers for our financial support during the course of the project.
    • HECo started up a partnering relationship with a local communications company on sharing pole space, which required a major change in our database design to allow for new pole occupants while differentiating relationships for ownership and rental agreements.
    • Competition is still a question, but quick and accurate access to our pole records will certainly be a plus in a more competitive environment. The question that remains is whether or not we will be required to share JP database information with our competitors in the future.
    Budgetary Constraints
    Limited financial resources is on the minds of most senior executives these days, and money for such mystical things as document management systems are easy targets for spending deferrals, particularly if the project has been expensed rather than capitalized. At HECo, we softened this a bit by:
    • Sharing the financial burden between three user departments
    • Expensing costs
    • Amortizing them over five years
    We have to keep focused on the fact that cutting certain small expenditures can result in a larger loss if planned benefits are not realized.

    Competing Projects
    HECo has just installed a corporate-wide suite of new software products that encompasses almost every aspect of our utility’s work processes
  • The transition to this new system, along with Y2k compliance issues, has consumed a tremendous amount of our corporate financial and human resources. This had an impact on our ability to complete the DMS project on time, which we did not do.

    Some surprises along the way

    Training
    Training for the new DMS product was relatively easy. Unlike our AM/FM product, which required considerable ramp-up in training and production, the JP database and DMS system is Windows NT-based. This, along with the PowerBuilder application, allows data to be presented in a forms appearance similar to the old paper system, which was very familiar. An additional advantage was that all users of the DMS system had been on either Windows NT or Windows 95 platforms for some time. They were also familiar with Internet and proficient in its use. This made end-user training faster.

    Technical Bugs
    Because this system is relatively “out of the box” with only some customization, it was not expected to present us with many technical problems. Some problems that we did encounter, however, include:
    • The DMS Web-based software and database required separate servers.
    • The DMS product could not read .dgn files and needed a special reader plug-in.
    • The bulk-loading script for the scanned files occasionally locked up, but would not be discovered until the next morning because of the loading of files at night.
    • The manual scanning process required almost three minutes to scan, index and file each drawing.
    Software Upgrades
    Because DMS technology and enhancements are coming fast and furious in this field, upgrades come about twice a year. They add better functionality and are only expected to improve our productivity. However, this requires system administration time to install, configure, and test upgrades, resulting in the need to send one of our IS people to the mainland for specialized training from the vendor.

    So what did we do right?

    Consultant Assistance
    While this is not exactly climbing a technical Mt. Everest, it is definitely still in the Himalayas and can quickly get out of hand without proper guidance and the help of a knowledgeable consultant to act as your Sherpa. How to choose and use the right one is a separate paper on its own, but we had one on board from day one and it has paid big dividends repeatedly to help us avoid the crevasses along the way.

    Formal Project Team
    The project team consisted wholly of end users along with a representative from IS, all with equal “voting rights.” The consultant was also part of the team, but the team made all the decisions. One other success factor was that the team stayed together for the entire duration of the project.

    The Quantum Leap Syndrome
    One piece of advice from our consultant that we took to heart was to not try to have the project do all things for all people all at once. We started off with just one simple application and will take our time getting to the other departments’ needs. User friendliness is a key factor in determining how effectively this new technology will be used. Our biggest surprise was how quickly the end users have taken to the new system.

    Strategic Plan
    A strategic plan is a must for any large project, and should both ask and answer:
    • What to do?
    • Will it be economically beneficial?
    • When, how, and where to do it?
    • Who will do it?
    • How much will it cost?
    Fortunately we had a DMS strategic plan that we had put together during the planning stage, and we stuck to it. The only thing we changed was the need to use a third-party Web viewer since the DMS vendor did not have this capability at the time of deployment.

    Specifications
    The planning phase included a detailed application design as well as specifications to meet our needs. This was a big help in evaluating the various submittals from among the six DMS vendors that we had short-listed (we had 70 items on our evaluation check sheet). We were surprised at the number of reference companies that we called that had selected their vendor without any formalized specifications or multiple vendor analyses and comparisons. Scanning Conversion Pilot
    After we had selected several possible vendors for our scanning effort, we actually paid each of them to do a 1000-drawing pilot using a cross-section of typical drawings from our files. This helped us evaluate the vendor’s capabilities as well as establish better procedures for us. It also gave the vendors a better idea of our needs, which resulted in considerable savings as reflected in the final bids and a much lower error rate when we went into the production conversion.

    Recommendations
    For anyone contemplating a DMS, we feel there are “musts” in being successful:
    • Obtain the use of a consultant familiar with the technology, and preferably one who is not in the business of selling and installing specific vendor systems
    • A neutral, unbiased consultant can be invaluable throughout the project.
    • Work with an internal team comprised of potential end users of the product
    • Do not leave it up to an IT department or a value-added reseller (VAR) to develop the system with an overthe- transom approach.
    • Develop a strategic plan, needs analysis, cost-benefit analysis, specifications and evaluation criteria as the first step.
    • Develop a short list of at least three DMS vendors for evaluation.
    • Be particularly aware of the vendor’s licensing, hardware, and peripheral software requirements and capabilities
    • Retain a copy of any demo software that is shown to you for bid evaluation.
    • Be leery of any “canned” demonstrations
    • Remember that they usually deal with only a few records, not the 100,000’s of records you will be filing in the system.
    • Backfile conversion (scanning) vendor selection should be a formal process and should include a conversion pilot to evaluate the potential vendor’s capabilities as well as develop your own acceptance procedures
    • Vendors who conduct these pilots generally will reduce production conversion pricing since they become familiar with your source documents and your conversion and indexing requirements
    • Therefore, they will not have to add contingencies in order to cover unknowns involved with production conversion.
    Conclusions
    HECo now has a working, fully automated and computerized system to maintain its joint pole records that is accessible to everyone in HECo from their own workstations
  • It has proven to be a cost-effective effort in manpower use and productivity improvement
  • It has also served as a pilot for other departments in the company that now want to use this new capability to improve their work processes and automate tasks.

    References
    The following may be useful sources of information as you embark on your DMS implementation.

    Publications
    • KMWorld, Knowledge Asset Media, Inc., POB 3006, Northbrook, IL 60065-9762,
    • www.kmworld.com
    • Imaging & Document Solutions, Miller Freeman Inc., 600 Harrison Street, San Francisco, CA 94107, www.imagingmagazine.com
    Organizations
    • Association for Information and Image Management International, www.aiim.org
    • Association of Records Management and Administrators International, www.aiim.org
    • © GISdevelopment.net. All rights reserved.