The Future Of Forms

Electronic forms can generate big savings for your organization. Find out how one in-plant is working to implement them.

What do electronic forms have to do with an in-plant printing operation? Maybe very little today, but tomorrow you will either be producing forms electronically or be out of the forms printing business altogether—or so say most reliable indicators.

The reason for the emergence of electronic forms in the in-plant community is their ability to generate significant cost savings, a fact that will become increasingly evident in most organizations once the proper software is developed and the price for implementation drops. This market is in its infancy, but the need is growing.

For years, in-plants have designed and printed hard copy forms, kept track of the quantity used and then printed more. In many organizations the in-plant often works hand-in-hand with the record management staff. In most cases (including at my own organization), record management responsibilities involve reducing duplication of organizational forms and ensuring that required forms are printed in a timely manner. More importantly, record management is responsible for controlling how much retention there is of the final data generated from these forms.

In small in-plant printing operations, usually an old A.B.Dick or a similar press is used to produce NCR forms. Single copies (two-sided) are produced on copiers or laser printers. Large-volume forms are ganged up and printed on a large press.

What I just described still goes on in many in-plants now, but in some large or medium-size corporations, executive managers are looking at ways to reengineer the forms business. Either presses are not producing hard copies fast enough to keep up with orders or priority jobs (other than forms) are keeping the presses busy.

Electronic forms software can reduce the costs of distributing, storing and managing forms, but few companies currently have made the move to a paperless form system. At South Florida Water Management District, in our attempt to set up a Web-based electronic forms system, we have accomplished a great deal, even though we didn't achieve all our goals.

We discovered that before you can install a working electronic Web form system, other processes must be in place. This market is still in its infancy stages, but the need for such applications is growing at a rapid rate. At this time there are several electronic form procedures that we have implemented.

The First Procedure

Print-on-demand forms companies are starting to convert from the traditional offset process of producing hard copy forms to electronic forms using print-on-demand forms, which requires the use of network printers (such as Kodak's LionHeart, Xerox's DocuTech, Océ's printers and others). Users send their forms through the network to the print shop, specify the number of forms that they need that day or month, and expect same-day turn around service.

All original new forms are designed by the Graphics staff or by individual users using various software packages. Examples of these electronic design form packages are Microsoft's E-Forms, JetForm's FormFlow 98, Lotus Forms, Novell's InForm, Adobe Acrobat and others. All form templets are kept in an electronic forms library on the intranet. Old forms can be scanned using scanning software.

Neither storage space nor advanced inventory of printed forms are required. All printed forms are updated electronically so that old stored forms that become outdated do not have to be thrown out. Unfortunately, two- to seven-parts NCR forms must still be printed in the traditional offset manner, though paper companies are reportedly introducing 9-point NCR paper capable of being printed on fast printers.

The Second Procedure

The requirement for the second possibility is to place electronic forms using Adobe's Portable Document Format (PDF) on the company's Web (intranet or Internet) site. PDF makes it possible for digital files to move across the digital environment. Once a new electronic form is designed or scanned in, it can be converted to a PDF file and placed on your company's Web site.

If the form was designed using any other software than Acrobat Reader and converted into a PDF file, the user can open the form (using a free Acrobat Reader) from the intranet. But he/she can only view and print the form, and then it can only be filled out by hand.

If you designed the electronic form on Adobe Acrobat Writer, a user can pull out the electronic form from the intranet onto their workstation. Then the form can be filled out electronically (using a free Acrobat Reader). The form can be printed or saved to a floppy disk or as an e-mail attachment to be sent to whoever needs it. Whoever gets it must also have Acrobat Reader on his or her workstation to open the form.

If forms are designed in the software that is on the user's workstation (such as Microsoft Office, Excel, Adobe PageMaker, FrameMaker or QuarkXPress) and then converted into HTML files and placed in the company's Web site, the user can pull the form off the site in the software in which it was designed. Then the user can open it and fill it out electronically in that same software and either print it or save it to a floppy disk and send it as an e-mail attachment. The information then is integrated by hand into a company's database.

The print shop is almost out of the picture in printing forms except in terms of designing and updating them. Printing is done using the small printer that is attached to the workstation and passed by hand to the next person who is required to approve it.

Though this process provides time savings, it lacks a corporate-wide workflow over the Web where notification, authentication and database integration should occur.

The Third Procedure

In July 1997, the electronic forms committee agreed to hire an outside contractor for a 10-week period with the goal of implementing an electronic form solution that involved a "back-end" data and workflow engine built using Oracle tools. The purpose of this back-end was to support forms access and processing (the "front-end") via the organization's intranet using HTML forms and CGI script processing.

The contractor who was hired to accomplish this task worked from September 29, 1997 to December 5, 1997 and was hired before there was any JetForm off-the-counter Web Form Workflow software. The contractor created a forms directory and Web page on the intranet. He scanned in four District forms with OmniForms Internet Publishing software using a flat scanner. He set up validation in each of the smart HTML forms scanned in and created authentication by accessing existing Oracle employee tables, using Oracle user names and passwords.

With the help of Oracle staff, he tested a program that queried District employees. He combined CGI script with Oracle query and was able to get CGI script to read form data or look up a person in the database for validation. People were notified through e-mail when a form needed to be approved.

The contractor discovered, upon installing the first scanned-in form on the intranet, that there were compatibility problems between Netscape Communicator and Netscape Navigator in addition to the connectivity problems with the old and new Netscape software. We realized how important it is to have a compatible database "source" for the required information to provide security and routing for a forms system for large organizations.

Lessons Learned

We found out that, due to other priority projects, there were no Oracle staff members updating District employee organizational changes on a daily basis. We were able to accomplish this task once the contractor left. Based on this project, we found out that we needed to educate our present Oracle and Netscape staff in the use of JAVA, CGI scripting, Oracle JAVA cartridge and Oracle Web cartridge.

Most workflow software was extremely expensive before JetForm came out with InTempo. InTempo is a 32-bit client-server system that uses an ODBC relational database back end. The core server and workflow engine is the InTempo Agent. The Agent executes workflow processes based on defined rules, logs all system transactions and allows users to query the database for workflow or task status. The Agent can also trigger automated tasks such as printing, faxing and custom script execution for interacting with other applications.

InTempo leverages an organization's existing e-mail or groupware system for transport and notification of tasks. When a user has a work item, it is sent via e-mail to the user's in box, relieving the user of having to check a separate in box just for workflow tasks. Likewise, the Agent can send users e-mail notifications based on events such as elapsed time or deadlines.

InTempo provides a good solution for organizations whose knowledge workers participate in both highly structured and less structured processes. For organizations that already use JetForm's electronic form solutions, adding InTempo provides a powerful combination.

On the downside, the tool could use some improvement in the areas of usability and integration. But overall, InTempo is quite sufficient for the types of board-based applications the product is designed to address, providing workflow capabilities that span organizations.

We have accomplished a lot since we started four or five years ago, but we still have a long way to go before we eliminate hard paper form copies. The technology is changing rapidly—on a daily basis. Most organizations, including mine, realize now that electronic Web forms can be produced today, freeing the in-plant operation to direct its energies to other important tasks.

Simon Siflinger is project manger for South Florida Water Management District. You can contact him at: simon.siflinger@sfwmd.gov&012;

Find Out More:

www.jetform.com

www.doculabs.com