 |
Home | Contact Us | Press Room | Site Overview | Help | Login | Register |
 |
 |
| About NCSL | State & Federal Issues | Legislatures | Legislative Staff | Meetings | Bookstore | Legislators & Staff Only |
| NCSL Home > Legislative Staff: Staff Sections & Networks > ASLCS > | Add to MyNCSL |
|
Reengineering For Legislative Document ManagementBy:
© Journal of the American Society of Legislative Clerks and Secretaries Executive Summary This case study discusses how the State of Wisconsin Legislature is working with Andersen Consulting to continue to develop new legislative Document and Workflow Management applications. The project, called TEXT 2000, addresses many of the document management quality and productivity issues faced by organizations today. The case study presents Wisconsin's legislative document management challenges and the TEXT 2000 solution that was developed to meet them. The major functional and technical components of TEXT 2000 are described, as well as lessons learned. The case study is organized as follows:
The State of Wisconsin legislature and its supporting agencies are responsible for drafting, updating, and distributing all documents generated by the legislature. Document management begins with the legislative drafting process and ends with updated State statutes. Attorneys and legislative support staff are involved in preparing and revising legislative drafts and other legislative information. The system used to support their document processes was an outdated mainframe application. The challenge facing these agencies was how to maintain the quality and timely production of a steadily increasing quantity of bill drafts. The existing mainframe application and the current document management procedures were not producing drafts rapidly enough for legislators. Quality was also steadily decreasing. Vendor support for the State's existing application was to be terminated soon. The State made plans to go to the marketplace in search of a new document management solution that would come to be known as TEXT 2000. The State chose a solution proposed by Andersen Consulting. The Andersen solution moved beyond current market offerings by developing a unique client-server solution incorporating COTS (commercially available off-the-shelf) software components and a GUI (graphical user interface). The two key software components are Interleaf and DOCUMENTUM. Interleaf supports the drafting and publishing of documents. DOCUMENTUM is an object-oriented workflow management program used to store and maintain all the key documents used by the legislature and its agencies. Sun hardware is used for the Database and application server components while Intel workstations running MS-Windows are used for the client workstations. The Andersen project team has integrated these products and developed custom functionality to give the State leading-edge document management capabilities. The major long-term benefits of TEXT 2000 include elimination of non-value-added tasks, improved throughput, increased quality, improved usability, and improved flexibility. A pilot application of TEXT 2000 was established at the Revisor of Statutes Bureau. The Revisor initally produced two key documents using TEXT 2000. The benefits recognized in the Revisor's Bureau included increased quality, faster turnaround and a reduction in external typesetting costs. Custom validation routines caught errors that were previously difficult to catch. The elapsed time for producing one of the documents was reduced from about four weeks to two and a half weeks. Additionally, the Revisor is now producing the camera ready copy in-house. The average external typesetting charge for a page is $35. During 1992 5,865 pages were produced externally at a cost of approximately $205,000. TEXT 2000 will enable the Revisor's to produce the camera ready copy in-house for a fraction of that cost. The Existing Legislative Document Process There are five major agencies which support legislative activities: the Legislative Reference Bureau, Revisor of Statutes, Senate Chief Clerk, Assembly Chief Clerk, and Legislative Council. The Senate and Assembly Chief Clerks manage the legislative process within chambers; the Legislative Reference Bureau drafts and maintains bills; the Legislative Council provides drafting and research activities; and the Revisor of Statutes updates and publishes State Statutes. The legislative document process begins with the Legislative Reference Bureau (LRB), the agency responsible for drafting legislation. Requests for legislative drafts (bills, resolutions, and amendments) are assigned to a drafting attorney who works with the requester to determine exactly what the requester wishes to do. The attorney must then research the statutes to determine which portions must be changed in order to accurately implement the idea as legislation. The attorney must also check for statutory cross-references and other legislation which may conflict with the draft. Previously, much of the research was manual and attorneys often wrote drafts by hand because the system was difficult to use. The only way to find current legislation based on subject or author was to search an index card file maintained by the LRB. Although the statutes and some larger bills could be full-text searched, most other documents such as memos and the Administrative Code could not. After an attorney has completed the preliminary draft, it is given to an editor who reviews the draft for grammar, style, clarity, improper terminology, etc. The editor also rechecks statutory cross-references and other legislation which may conflict with the draft. If there are no significant changes, the draft is given to the word processing operator (WPO) for entry into the system. If there are any significant changes, the editor gives the draft and comments back to the attorney, who makes appropriate changes and submits the draft to the WPO. This process continues until the attorney is satisfied with the draft. During busy legislative periods, many different drafts are being circulated, and in-baskets tend to pile up with work. Access to this work used to be limited to the person who has the most current draft. Once the draft has been approved by the requester and filed, it becomes a legislative proposal. After the proposal is reviewed in legislative committee, the proposal is referred to the calendar and scheduled for debate and vote on the floor of the house. Staff from the Chief Clerk's office are responsible for recording all floor and legislative activity. Clerks sat in chambers during all legislative sessions and manually recorded activity in a notebook. At the end of the day, the notes were compared for omissions and errors, then keyed to publish the daily activities in the Daily Journal. Much of this information was rekeyed to publish a weekly summary, the Bulletin of Proceedings. If the proposal passes both houses without amend-ments, it is returned to the Legislative Reference Bureau for Enrollment. Resolutions need no further action; approval by the legislature is all that is required. Bills, however, must be approved by the Governor. If the Governor enacts (signs) the bill, it becomes an Act. The Legislative Reference Bureau then publishes the Act and gives a copy to the Revisor of Statutes. The Revisor of Statutes is responsible for updating the Wisconsin Statutes to include the changes specified by the Act. The Document Management Solution Document Reengineering One of the unique features of the Andersen approach was its emphasis on document process reengineering. The goal of the process reengineering effort was to give even more benefits to the State in terms of throughput, flexibility, quality and usability than would be realized by simply introducing new technology. In order to achieve these results the project team analyzed the legislative document processes, streamlined some processes and totally reinvented others. During the reengineering effort, the project team looked for ways to
The biggest benefits were realized in the elimination of non-value-added tasks (a value-added task is something that makes the original information more useful, such as adding key words to search by; a non-value-added task may be important but doesn't make the information involved more useful or valuable). By far the biggest non-value-added task was the reinvention and recreation of information. Documents originating in other agencies had to be retyped because there was no way to transfer the information. The searching methods were rudimentary and often research would have to be performed on a subject because the document relating to that subject could not be found. Additionally, many documents within the State shared information which would originate in one document but be rekeyed in several others. The new processes eliminate rekeying information. Large amounts of time were also spent on activities such as filing and distributing paper documents, printing documents to determine what the document actually looked like, and maintaining files of index cards with document-related information so that the documents could be located later. Many of these tasks were eliminated from the process in the new system. The central repository, search and retrieval system, document routing, and WYSIWYG ("what you see is what you get") editing and viewing capabilities of the technical solution make this possible. As the document processes were reengineered, it became apparent that different processes would be changed in different ways. For example, the fundamental legislative drafting process stayed the same. However, by eliminating non-value-added tasks and by making other process improvements, the overall production cycle time was greatly reduced, throughput increased, turnaround time decreased, and quality improved. In contrast, the Senate and Assembly Chief Clerk offices' document processes were totally reinvented. These agencies' documents share information, but the agencies' processes centered around the documents instead of points of information. As mentioned before, data was captured separately for both the Daily Journal and Bulletin of Proceedings, although much of the information was the same. The Weekly Schedule and Daily Calendar also use much of this infor-mation, but, again, they were created separately. The Chief Clerks' document processes were radically changed to align with the information used to create the documents. Under the new processes, floor actions are recorded directly and stored in the database. Information from other documents is shredded (broken down into component parts such as title, sponsor, summary, etc.) and also stored in the database. The required documents are then produced from the database automatically, using database publishing techniques. The before and after representations of the Chief Clerks' document processes are depicted in the following workflow diagram (see next page). By capturing the information and reusing it to automatically produce documents, the total number of production steps was significantly reduced. The Document Management Solution The State's legislative document processes required a system with the following document management functions:
The approach that Andersen Consulting developed to meet these requirements is described below. Repository One of the key requirements for TEXT 2000's document repository was the capability of handling very large volumes of documents. The Legislative Reference Bureau alone produces approximately 20,000 bill drafts each session. In addition to the multiple versions which must be stored for each draft, there are potentially several other reference documents which must be stored with the draft. Several sessions worth of drafts are required to be stored in the repository so that they can be used for research and history purposes, and as templates for similar drafting requests. Due to the various locations of the agencies and users of the system, distributed access to the repository was also a requirement. This requirement led to a client-server based repository which could support the access requirements. (A client-server system is one in which some of the software is on the individual workstations [clients] and the rest is on one or more centralized shared computers [servers] which can be accessed through the client workstations.) In addition to meeting these requirements, the client-server approach allows the system to be easily expanded to encompass more users and agencies, and, potentially, public access. Since there is no one product which would meet all of the needs of the State, it was important that all tools selected, especially the repository, be extensible (able to have additional types of information and ways of looking at and handling the information added on as the need arises) and easy to integrate with other tools. The repository selected had to have an open API (application program interface) set, be extensible in terms of data structure and behavior modification, and independent of other tools and file formats. The State also had special requirements in terms of compound documents. In some cases, all that was required was that related documents be grouped or associated together, such as with the documents related to a particular legislative draft. Other documents, such as the statutes, required "true" book technology. "True" book technology is more than simply organizing a group of documents in a hierarchy. Users must be able to manipulate a single document in a book, or work with the entire book as a whole (e.g. printing). The individual documents within a book must be sensitive to their location in the book, as well as the other documents in the book. For example, changing the order of documents within a book should also change page numbers, chapter numbers, references, table of contents, etc., for all documents in the book. Due to the requirements described above, as well as some covered later in this section, the repository chosen was DOCUMENTUM. DOCUMENTUM is a client-server based object-oriented document management product which offers more than just document repository capabilities. The current configuration for TEXT 2000 includes 64 Gigabytes of disk storage space. One of the most important features of DOCUMENTUM from an integration standpoint is its extensibility. Once object classes have been defined for the different types of documents in the system, the behavior of these object classes can be modified. An object class is a type of object as opposed to a specific object. Legislative drafts are an object class, and a particular legislative draft is an object. A behavior is what happens to an object when a user performs an action on the object. For example, telling the system to print a document is an action, and sending the document to the printer is the behavior. In TEXT 2000 this behavior has been modified for Legislative Drafts (which have their own object class) so that the document is first sent to a program which places line numbers in the document, and then sends the document to the printer. In addition to the extensibility of object classes and behaviors, DOCUMENTUM provides an open API set to allow integration with other tools. The DOCUMENTUM server has an API library for both C/C++ and the GAWK scripting language. There is also a C/C++ DLL (dynamic-link library) for Windows client applications, and the Documentum Workspace provides a full API through DDE (dynamic data exchange). Drafting One of the goals of TEXT 2000 was to make drafting (text entry) easier, so more information could be entered at the point of origin. The previous system was cryptic and hard to use. Many users, such as drafting attorneys, hand wrote or dictated what they wanted entered into the system rather than using the system themselves. The drafting tool also had to possess powerful document publishing capabilities. Some of the documents produced by the State have complex requirements in terms of page layout and format, text rotation, and graphics. The ability to create complex graphics, charts and text layouts from a single tool was a high priority. The requirement for ease of use and document publishing capabilities had to be balanced with a need to effectively tag information in documents for use by the system. Several documents produced by the State serve as sources of information, and this information must be extracted so that it can either be searched on or used in other documents. As with the other tools selected for the project, the drafting tool had to be extensible and have an open API set to allow integration with other tools. Interleaf was selected as the TEXT 2000 drafting tool. Interleaf is a powerful WYSIWYG document publishing system which allows text to be tagged through the use of component markup. Interleaf also possesses all the document publishing compound document capabilities required by the State with an easy to understand interface. Templates can be created for documents with complex formatting and tagging requirements, which allows even less experienced users to create complex documents. Interleaf is fully extensible. In addition to simple macros, Interleaf has a complete API set, and custom LISP programs can be created to access these APIs. Several custom routines were created to extend Interleaf's capabilities and modify standard behavior to meet State requirements. Interleaf also has a regular expression file processing language called Cloverleaf. This tool was used extensively to create document filters. Some filters were used to import different documents into Interleaf format. Others were used to repurpose or reformat a document, such as changing a Bill into an Act. Still others were used to create entirely new documents from existing documents, such as creating a list of all statutory cross-references using the statutes as input. In addition to Interleaf, two other add-on tools were included in the system: Oracle Coauthor, which provides additional proofing and editing capabilities to Interleaf, and Smartleaf Compare, which is used to compare two different documents and highlight any differences. Search and Retrieval Because of the large number of documents stored in the repository, a robust method of locating and viewing documents was required. To meet the needs of the State, the search engine had to be able to locate documents based on ideas and the attributes associated with the ideas. Once these documents were located, they had to be presented to the user in a read-only, WYSIWYG format. As mentioned before, DOCUMENTUM stores all documents as objects and associates with each document a custom list of attributes (based on object/document class). DOCUMENTUM provides a standard query language DQL (Document Query Language) which is a super-set of SQL (Structured Query Language). In addition to meta-data searching capabilities, DOCUMENTUM comes bundled with the Verity full text search engine. Full text searching is also supported by DQL and allows documents to be located based on both ideas and attributes. For example, a user could pose a query to DOCUMENTUM to locate all bill drafts requested by a senator having the word "crime" and "reduction" in the same sentence. DOCUMENTUM will then return a list of all of these documents. Once the list of documents is returned, they must be viewed by the user in a read-only, WYSIWYG format which is easily navigable. Adobe Acrobat was selected as the viewing tool. Acrobat consists of three pieces: Distiller, Exchange, and Reader. The Distiller is used to transform a postscript file into a PDF (portable document format) file. The PDF file is used by the Reader to view and navigate the document. Acrobat Exchange is capable of creating hyperlinks and collating documents. All three are being used in TEXT 2000. Using the extensibility of DOCUMENTUM, the transformation of documents is invisible to the user. When a document is returned from a query and selected for viewing, DOCUMENTUM uses the selected document to create a postscript file, and then a PDF file. These files are stored with the original document. The PDF file is returned to the workstation, and the Acrobat Reader is launched with the returned file. Workflow Many of the State's document production processes involve numerous steps and several different users. Under the previous system, all documents were printed and physically routed to each successive worker in the production process. The ability to eliminate many of the manual steps and capture the workflow information was important to the State. The workflow component used for TEXT 2000 is a component of DOCUMENTUM. Standard workflows, called routers, can be constructed. For example, the standard workflow for a legislative draft is drafting, editing, typing, and submitting. A router is created which has a separate "task" for each of these steps. The workflow component provides an easy method for users to determine what work needs to be accomplished in any given day and eliminates the manual distribution of paper copies. In addition, information for each task in the router is captured, such as begin time, end time, user performing the task, etc. This provides the information necessary to create reports on the production process to help identify bottlenecks and distribution of workload. Composition Composition is the creation of documents from existing information. One method of doing this is through some of the features provided with the Interleaf, such as the Cloverleaf programming language. However, the State required more than these features. Several key pieces of information are created in a source document, but need to be replicated in several other legislative documents. An example of this is the relating clause in a bill. Although created in a bill, the relating clause also appears in the Daily Journal, Bulletin of Proceedings, and Special Order of Business documents. Database shredding and publishing was the solution to the problem and Smartleaf was the chosen tool. Smartleaf is a "plug and play" extension of Interleaf (which means that it can be used at once, without additional programming, after it has been installed) and is fully compatible with Oracle, DOCUMENTUM's database engine. Specific text in the originating document, such as the relating clause in a legislative draft, is tagged using Interleaf markup. When the user checks a document into the repository after editing, the relating clause is shredded out of the draft and stored in the database by a unique identifier. When the time comes to produce the output document, such as the Daily Journal, Smartleaf is executed and creates (or adds to) the document using the data stored in the database. Database publishing eliminates the need for rekeying information and helps reduce the number of errors introduced. It also dramatically decreases the amount of time required to create a document which is based on shared information. Conversion In terms of data conversion requirements, State documents can be divided into four categories:
Documents under the previous system were created using ATMS, a mainframe word processor. Data Conversion Laboratories (DCL) was chosen to perform the conversion of documents from ATMS to Interleaf because of their experience with this type of conversion, and experience from previous projects. Technical Architecture TEXT 2000 is built on an open systems client-server architecture. A diagram of the architecture is depicted below: The hub of the system is a central data server which is used to store all documents and run all background processes such as batch routines. The central server is a Sun Sparc Server 1000 with 512 MB RAM and 64 GB of disk storage. DOCUMENTUM, Oracle, Acrobat Distiller and custom batch routines created in C/C++, GAWK and Cloverleaf all reside on the data server. Attached to the data server are individual Token Ring hubs consisting of an application server and approximately 5 to 6 workstations. The application servers are used to run Interleaf and any customized interactive drafting routines. Isolating groups of users on separate Token Ring hubs minimizes network traffic and ensures that groups of users always have enough resources to run their applications. The application servers are Sun Sparc 10 and 20 workstations with 128 MB of RAM and at least 1.7 GB of disk space. The Interleaf, Smartleaf Database Publishing, and custom interactive routines created in Cloverleaf, C/C++, and LISP reside on the application server. The workstations are Dell 486/66 PCs with 8 MB of RAM and 170 MB of disk space running Windows 3.1. The workstation serves as the interface to all other components of the system. The Documentum Workspace is the tool which is used to access, search for and manipulate documents in the repository. Interleaf is used to edit documents via an X-Windows session with the application server. Acrobat Reader and custom routines written in Visual Basic and C++ also reside on the workstation. Business Case The business case for TEXT 2000 can be broken into immediate benefits and long-term benefits. The benefits that immediately improve the State's document management processes consist of
Long-term benefits are key factors that help ensure that TEXT 2000 provides a foundation for meeting the State's document management needs for several years to come. They consist of
Immediate Benefits Improved Throughput and Turnaround: The TEXT 2000 solution will improve the response time and throughput of State documents by eliminating non-value-added tasks, automating other tasks, and introducing work flow management. This means better customer service by the legislative support agencies to legislators and the public. The critical times are during the busy legislative sessions when the volume of work is greatest and the State is working under tight time constraints. One example of how automation is improving throughput and turnaround is in the vetoing process of the budget bill. Prior to TEXT 2000, approximately 1,300 pieces of text were vetoed by the governor. For each of these vetoes, a piece of adhesive vellum had to be cut to the same shape as the text and applied to the document before printing. This process took up to a week to complete. With TEXT 2000, vetoed text is marked by the user and the system applies the appropriate highlighting. Improved Quality: By capturing information at the source, eliminating rekeying, and improving proofing and validation tools, the quality of critical State documents has been improved with TEXT 2000. Improved quality also results in less rework time. An example of how TEXT 2000 is improving the quality of information at the State can be found in the Daily Journal, a record of daily legislative activities. The Journal is currently prepared from notes taken during legislative activity on the session floor. With TEXT 2000, information for the Journal will be recorded on the legislative floor as legislative activity takes place. The Journal will then be produced directly from this information. Improved Usability: Providing people with tools and products that are intuitive and straightforward to use is important in any business process. TEXT 2000 moves the State from a mainframe system with complex formatting codes to a client-server system with WYSIWYG and a menu-driven window structure. More Flexibility: The State will use TEXT 2000 to create new types of documents from existing information or documents, pull information from multiple locations, and publish information in multiple formats. Long-term Benefits A Forward-Looking Solution: The TEXT 2000 solution incorporates the latest in document management technology. The products that make up TEXT 2000 are state of the art. The customized off-the-shelf software solution allows individual pieces of the system to be changed or updated over time as opposed to replacing the entire system. The open system client-server approach will also allow integration with other open systems. Scalable Architecture: State agencies besides those designated to receive TEXT 2000 have already indicated interest in the system. A scalable architecture provides the State with flexibility to add additional agencies and users to the system. Additional users can be added incrementally in an easier, distributed approach. In addition, the scalable architecture allows individual pieces of hardware to be upgraded, giving the State more flexibility. Extendible Products: TEXT 2000 products have open APIs which are easy to integrate with other products and custom routines. These products can be further customized as new requirements emerge, and new products can be integrated with the system as they become available. Foundation for Public Access: Public access to information through TEXT 2000 was a long-term goal. Currently, the statutes are prepared on CD-ROM and other legislative reference materials are gathered by the legislative library. TEXT 2000 also provides a foundation that allows the public dial-in and Internet access to this information. Lessons Learned Bill drafters and support workers began using TEXT 2000 in September 1994. The Chief Clerks' offices began using TEXT 2000 at the onset of the 1995-96 legislative session in January 1995. Since then, end-users of the TEXT 2000 system have successfully completed their first legislative session. Of course, as with anything new, some fine tuning was necessary, and enhancements were made to improve the system integration and performance as end-users became comfortable with and more knowledgeable about the system environment and its capabilities. The TEXT 2000 project offers several lessons for other organizations planning large scale document management projects. Some of the critical issues and how they were dealt with are described below. To use SGML or not The TEXT 2000 system had to be able to handle highly structured documents with complex tagging requirements. This is a requirement that would typically suggest an SGML (Standard Generalized Markup Language) solution. However, this requirement had to be balanced with the requirement that the drafting tools be easy to use and intuitive to the end user. One of the primary goals was to get as many users as possible involved in text entry. Interleaf could meet the State's formatting requirements through the use of templates. Interleaf has the ability to tag text for use in document shredding, searching and composition while providing an easy to understand user interface. Interleaf is also extensible and supports an open API set so that it could easily be integrated into the TEXT 2000 solution. Although Interleaf offers an SGML product, it would still require a greater level of knowledge than the typical TEXT 2000 user has. After weighing all the requirements, the project team decided that in order to make the system as intuitive and accessible as possible, SGML was not the appropriate choice for TEXT 2000. Criteria for Object Definition Because the repository is an object-oriented system, the criteria for defining new classes to represent documents had to be examined. The project team had to decide early on which documents should be stored as a single object class, which documents should be differentiated by an attribute value to identify type, and which documents should have their own object class. The TEXT 2000 project used four criteria or guidelines to determine when a new object class should be created for a document. Some of these rules are hard and fast, others are ambiguous and may not always lead to the same answer. Any given project may have a different set of rules. Creating too many classes or too few classes can make the system difficult and cumbersome to use. In general, new object classes should not be created unless one of the following rules is met:
Technical Integration Issues The TEXT 2000 solution is built upon three different operating systems, three different processor types, seven different programming languages and seven different packages. Developers had to be conversant in the following areas: Operating Systems:
Languages:
Integrated Products:
The complexity of the solution's components presented a challenge to the development team to integrate the products across the different platforms using the different tools. The most important part of the integration effort was creating a seamless interface between Interleaf and the Documentum Workspace. The requirement was that when a user opens a document for edit in the Documentum Workspace, the document is opened in Interleaf. This presented quite a challenge since the Documentum Workspace resides on the workstation, and Interleaf runs on the application server. This issue was tackled primarily because both products offered an open API which allowed the development team to create the custom extensions required to integrate the two. Not only does this integration include the ability to check a specific document directly to Interleaf, but it also includes the integration of compound documents or books. Users can check out any piece of a book (or the entire book) for edit and the portion which is checked out will be given to Interleaf as a single document. Technology Assimilation The TEXT 2000 user group consists primarily of legislative support staff and attorneys. The computer literacy varies greatly and includes several attorneys who were not even using a typewriter, much less a computer, before TEXT 2000. The user community as a whole was very excited about TEXT 2000 as it offered huge improvements over the old system. Some users, however, worried about their ability to grasp the new system and feared the loss of expertise they had achieved under the old system. These fears were dealt with by a proactive approach to helping the State assimilate the new technology. This approach emphasized
Training: For some users, TEXT 2000 was the first Windows based system they had used and the first time they had used a mouse. The concept of working with a tool kit of applications like TEXT 2000 was also new for most users. To lay the groundwork for these users, basic Windows and mouse tutorials were made available, as well as games to provide users the opportunity to learn Windows concepts in a nonthreatening environment. Users were also able to practice their keyboard skills with on-line typing tutorials. Users also took self-paced tutorials on TEXT 2000 applications. These tutorials allowed users to experiment with the TEXT 2000 applications in a safe environment. There was no need to worry about damaging data in these simulated settings. Users were more relaxed working with these tutorials early in the project when there was still lots of time before the "real" system was implemented. Encouraging interest and user involvement in TEXT 2000: Getting users involved in the project and encouraging interest was a great way to prepare them for TEXT 2000. Regular TEXT 2000 newsletters were published highlighting project news, questions and answers, and other information related to the system. In addition to newsletters, demos were offered that allowed users to see the system firsthand. By seeing the system in action, users were able to imagine what the system would be like in their own work setting. Users have also been involved in decisions related to all aspects of the project. They were involved in design, training, and rollout decisions. This increases user ownership over the project and excitement as they see user ideas implemented. Involving users in TEXT 2000 support: TEXT 2000 support is provided by the State's help desk and system administration group and through several "user experts." The user expert concept was born out of the agencies' desire to have local experts who knew the agencies' business processes and TEXT 2000. The user experts help the agencies solve problems more independently and quickly than they might by just relying on a central help desk. There are also aspects of TEXT 2000 that have been customized by agency. The user experts are particularly suited to solving user problems related to these custom functions. Organizational Impacts When TEXT 2000 was implemented, it caused several organizational impacts. These impacts had to be planned for to ensure a smooth implementation. As a result of the reengineering and the new TEXT 2000 system:
The above changes helped the State realize the benefits of TEXT 2000. These kinds of changes, however, can be scary for the workforce if they do not understand their role in them and how they will be personally impacted by them. Preparing the State's workforce for these changes involved more than just training. It involved communication - helping users to see the TEXT 2000 vision of the future and how it is different from the way work was done on ATMS. For example, the vision includes much more active use of the system by lawyers than before. Some lawyers faced a decision whether to start using a computer for the first time ever or to continue drafting by hand. The lawyers were actively encouraged to participate in demonstrations and tutorials, and the number becoming enthusiastic about the system continues to grow. Users also needed to know the details of the revised workflows and their future roles in them. For example, several users were involved in revising different parts of the legislative drafting workflow. Once the overall workflow was developed, users had access to it several months before it was implemented. Receiving the new workflows early eliminated any chance of user anxiety over the unknown or anxiety caused by the rumor mill. The preparation also included ensuring that the proper infrastructure was in place to support the revised workflows. At the State, this included establishing the channels of user support early, so those support providers could receive training early and stay more involved in the project than other users needed to be. In conclusion, Wisconsin's conversion to TEXT 2000 has been and continues to be a challenging process, but the benefits have shown that it was the right choice for the State. For more information about ASLCS, write or call:
|
© 2008 National Conference of State Legislatures, All Rights Reserved
Denver Office: Tel: 303-364-7700 | Fax: 303-364-7800 | 7700 East First Place | Denver, CO 80230 | Map
Washington Office: Tel: 202-624-5400 | Fax: 202-737-1069 | 444 North Capitol Street, N.W., Suite 515 | Washington, D.C. 20001
