I first heard about electronic forms back in the mid-1980s after watching a demo of the TyForm software from Tyrego Technologies, which ran on a Personal Computer AT with special hardware attachments. I was fascinated by the possibilities that desktop electronic forms promised. In the early 1990s, many organizations rapidly converted paper forms to electronic print-on-demand forms. Some of these forms even had fields added so they could be filled out before they were printed, i.e., fill-and-print. A few had additional scripting added and became intelligent electronic forms (IEF). It was the beginning of a major shift in forms development and heralded the demise of the business forms printing industry, which, today, is a mere shell of its former self. The consensus at the time was that all forms would become electronic and that forms management as we knew it would no longer be needed.
This major change in forms development methods was accelerated by the introduction of the commercial browser and the rapid growth of the World Wide Web via the Internet. Using the Internet, forms could be distributed before they were used and web-to-print solutions were offered. This just seemed to hasten the demise of paper forms. Recently, mobile devices have really taken off, and mobile apps are now all the rage. Fast forward to today: I could argue that all forms in existence today are electronic forms. At least, they begin their life cycle as an electronic file. However, I could also argue that more than 80% of conventional forms are paper forms because they get printed at some point in their life cycle. Further, I could argue that more than 80% of all conventional electronic forms are print-on-demand forms. Another roughly 10% are fill-and-print, and maybe five percent are intelligent electronic forms, with fewer than five percent of all forms enterprise-enabled, with submit to database capability and workflow-enabled.
The bottom line, for me, is that electronic forms have failed to live up to the potential that seemed obvious 25 years ago. While there is no denying that progress has been made, it has largely stalled in terms of its potential. This failure to achieve the major productivity benefits expected has been frequently documented over the years. To be fair, the early years of electronic forms development showed significant improvements in productivity and cost benefits: Print-on-demand forms greatly reduced inventory and distribution costs. Forms obsolescence costs, always a significant problem with warehoused forms, was reduced. User productivity improved along with reduced errors associated with manually completed forms. While these improvements were substantial, they have leveled out over the past few years.
|
We have spent a great deal of time trying to understand the reasons for this relatively low level of achievement for electronic forms. No one reason stands out, but collectively, they demonstrate the barriers involved. Some issues are more compelling than others. I think one of the most significant problems is signature requirements. Of course, legislation, such as the ESIGN Act and the Uniform Electronic Transactions Act, serve to make electronic forms legal per se. However, I think there is a major difference between something being legal and being accepted as evidence in a court of law. Many transactions still enter a manual workflow when a signature is required, particularly for transactions outside the firewall. There are various competing electronic signature technologies available, and I think that is a part of the problem—competing technologies. Until standards emerge, it can be very confusing and expensive to try to obtain valid signatures on a form.
Our general approach is to first challenge the need for a signature on a form. That need depends largely on three factors: the value of a typical transaction, the risk of loss and internal policies and procedures. The basic question to ask is, "What value does the signature add to the transaction?" If a signature is required and the signer is known to the system (some login process is used to authenticate the user), we can usually proceed with the electronic transaction. However, if the user is not authenticated, we usually end up entering a manual workflow at that point. Although specific solutions can be employed, they frequently are discarded by users. Of course, there are exceptions, but signatures frequently remain a barrier.
Another obstacle we face is that laws and policies can be very slow to change to accommodate electronic forms technologies. This includes internal policies and procedures as well as external. Requirements, such as copy distribution, archiving, retention and distribution, can require paper-based transactions. While such barriers are slowly changing, they still frequently result in manual processes. Implementing security and privacy requirements are particularly challenging.
A major barrier to electronic forms is a general lack of standards that exist today. In fact, attempts to establish standards, such as the XForm standard published by the World Wide Web Consortium, have yet to gain any real traction. Most forms are developed in a proprietary design software package, and these design files do not transfer easily to a competing package. Even when they do import, much of the scripting does not translate. Most of the forms created require a proprietary client such as Adobe Acrobat Reader, MS Word, MS InfoPath or other filler. Many forms are also published as true web forms (HTML) and require only a browser for user interaction. However, most of these forms do not allow the user to save to the desktop or to print easily unless first converted to a format, such as PDF.
Over the years, many electronic forms companies have come and gone. Some, such as Delrina, JetForm, Bloc Development, Shana and Pure Edge, grew successfully at first and were then acquired by larger companies. Many users found that their investment in electronic forms was severely compromised by those acquisitions, as the old software was no longer supported, and the new software was not backwardly compatible. This set a lot of companies back in their efforts to automate forms.
|
Cost has also been a significant factor in limiting electronic forms growth. Enterprise-wide solutions tend to be expensive—software license fees and maintenance, training costs, development costs and deployment costs can rapidly escalate. Of course, the benefits can also be huge. However, getting by the initial costs can be daunting. We see this regularly in what we call scope creep. Scope creep occurs when an organization starts to define what is to be included in their electronic forms program. Many request for proposals (RFP) that I have seen look like the organization held a series of meetings and added everything they could think of, including related but separate solutions for records and document management. The responses they receive to these RFPs are very expensive, and as a result, no action is taken. It is clear that there is no electronic forms strategy in place for these organizations.
Finally, another major barrier is what I call the great IT/forms management divide. In many cases, electronic forms are viewed as IT applications rather than forms development activities. Responsibility is assigned to the IT department and progress is slowed because IT simply does not have the time to spend on electronic forms. Forms developers are restricted from developing forms as requested by users. In many cases, IT dictates to forms management what software tools they must use simply because those tools are what IT will support.
Each of these issues tend to be rather complex and many defy simple solutions. The result is that electronic forms at higher levels have not been widely implemented and many paper forms still exist. Forms that do not read in data that an organization already has, or that do not seamlessly write transaction data to a back end without a separate capture process, remain barriers to productivity improvements. Although I think we will eventually overcome most, if not all, of these barriers, we have a long way to go.
Tweet
