It is estimated that more than 40 percent of American households now own a PC and that virtually all of those households have access to the Internet in some capacity. PC and Internet penetration within the business community is even greater. And with the expectation that postal rates will continue to rise, along with costs for the paper and personnel associated with sending regular mail to your customers and partners, it is becoming even more feasible to deliver customer materials, such as statements and invoices, electronically.

Electronic delivery of such information does more than just save money; it creates new ways for you to service your customers and new ways for them to use the information in your systems.

Requests for duplicate information are among the most common of customer service requests. Regardless of which industry your organization represents, consider the possibility that your customers could look for, and reproduce, the information you have provided for them whenever they need to, without assistance from your staff. Consider, too, that a customer, particularly in the business-to-business (B2B) environment, could interface your information with its systems, also without assistance from your staff (assuming, of course, that you want to provide the information).

This article takes a look at the basic system requirements for conducting such an electronic presentment of information, as well as some things that can be done to add electronic delivery capability to your paper-based systems. It also looks at a practical example of a presentment application. This may be easier than you think.

The Necessary Pieces

Until recently, paper was one of the few portable, universal interfaces an organization could have with its partners and customers. However, systems that produce the paper can also be a source of electronic content. Tying those systems to a means of delivering content is the basis of an electronic presentment.

If your statement and invoice print programs use typical AS/400 development techniques, such as output through an operating system printer file, capturing the output for an electronic version may be as simple as creating a new printer file. A file override can be performed before the program is run, and the resulting output is captured. The new printer

file could even contain the portions of HTML required for the output to be presented in a Web browser. Often such print programs are constructed to produce all of the documents in a single output file, which makes sense if the target for the output is a printer. In an electronic environment, however, large files should probably be separated into individual documents.

Another way to capture output is to use a product such as IBM Content Manager OnDemand (www.software.ibm.com/data/ ondemand) or Gausse Interprise (formerly Magellan Software) SpyView (www.magellan.com). These products are generically known as Enterprise Report Management (ERM) or Computer Output to Laser Disk (COLD) tools, and one of their features is the ability to separate large printer output files into individual documents. A side benefit of ERM software is that it provides a means of storing, searching for, and retrieving the individual documents.

Where Is the Server?

An electronic presentation of information requires some sort of mechanism for delivering output to a network. In today’s world, that will likely be a Web server that is connected to the Internet. The AS/400 itself is a pretty good Web server if great care is taken to manage system security.

Some organizations choose not to use production AS/400s as Web servers and to ensure that Internet access to that system is either severely limited or not available at all. A dedicated server, possibly an AS/400, is assigned the role of Web server. Such a configuration presents a development challenge for an electronic presentment application, though not an insurmountable one. (I’ll cover some considerations for such a configuration later in this article.)

The Internet connection is also important. A connection that provides adequate performance for employee email and occasional Web access could be woefully inadequate if a large volume of online data is made available to the community you conduct business with. In this case, I suggest an appropriate sizing exercise be performed before implementation.

The Inevitable Prying Eyes

Security is always a concern when making electronic data widely available. The problem breaks down into two distinct issues: the first is keeping out those who have no business being in the system; the second is ensuring that those who do have a good reason to be in the system have access only to the information they are authorized to see.

Keeping undesirables out is an exercise in good environment design, appropriate system security, and ongoing management of both. Often, security systems break down simply because of a lapse in the management of a well-designed system. If new security systems and features are added to a system as a part of the development of electronic presentment but the underlying system itself is not appropriately secured, there could be an unacceptable security exposure. With any electronic presentment project, system security must be reviewed and any changes executed to ensure protection.

Limiting users to what they are authorized to see is a new problem for most systems. Many systems don’t anticipate this need, so they do not provide a means of identifying (user ID), authenticating (password), or authorizing (information users can see) a large number of users. A Web server’s security system is good for identification and authentication, but custom development may be required to address the need for authorization. At a minimum, a database table that relates users to authorized accounts is necessary.

Many Internet-enabled applications take an interactive approach to the identification of users by asking them to establish their own user ID and password the first time they access the system. However, that does not solve the authorization issue. For example, what is to prevent a user from supplying someone else’s account number? One option is to

ask for multiple pieces of information (e.g., account number and ZIP code), the combination of which should be unique and known only to the user.

Another option is to generate personal identification numbers (PINs) for each customer or user that would have access to the system. PINs can be generated and mailed out as the system is put into production, but then there is an issue with the customer either misplacing or not having his PIN available when it is required.

Once a user is authorized, there still may be a security concern. Remember that the Internet is a public facility and that, if the information being delivered in the application is confidential—such as a monthly statement in a financial application—the additional step of encrypting the data delivery may be required. One option is to scramble the information as it transits the public network with the Secure Sockets Layer (SSL) data encryption that virtually all Web servers and browsers now support.

Building the Application

The next step in such a project, once the network infrastructure and security considerations are addressed, is to design and develop the application. I will use a monthly statement delivery application for a financial services firm as an example.

Assume the application runs on an AS/400 and produces monthly statements, presently delivered by mail. The output from the application is a single, large spool file. Inside the spool file are control codes intended to drive special features, such as font changes and page formatting, on the printer. There is no way to change the application output.

First, you would capture and split up the spool file. A program could be written that requires information for each user to be stored and managed separately; however, one of the ERM tools I mentioned before might be a simpler choice. The ERM tool extracts the data from the spool queue, splits it up, and captures indexing information (in this case, an account number) from the data stream. Each user’s statement information, for each month, is then available through the ERM interfaces, on the production AS/400.

Given the sensitive nature of personal financial data, care must be taken to appropriately authorize users. In this case, the user is required to request a user ID and PIN from your company by phone. Procedures are carried out during the call to establish the user’s identity. A new function must be developed to assign the PIN and to associate it with the accounts the user is authorized to see.

Separate Servers

The Web server in my example is separate from the production AS/400 and runs on Windows NT or 2000. This complicates the application a bit, since parts of the retrieval process will operate on the Web server and parts will operate on the AS/400, with some sort of secure interface between them.

The part that operates on the Web server must first include some mechanism to authenticate the user. Web servers have a logon mechanism that captures the user ID and password. But, in this case, the firm would like to provide other services during the log on, so an HTML page is used. The page is SSL-encrypted, since care must be taken with the transmission of PINs on the Internet. The balance of the pages in the application are protected with SSL as well.

There are many communication options with the AS/400, especially from the Windows NT platform. One option is to install Client Access and use its ODBC driver. Requests for information can simply be written to an AS/400 database table, and a trigger program on the AS/400 can be used to initiate the required processes. The results of the processes can simply be written to another table. The Web server then extracts the results again using ODBC.

The Web application authenticates the PIN against the table created in the PIN assignment process and returns the accounts that the user is able to see. At this point, the

application must communicate with the production AS/400 to determine what information is available for the authorized accounts.

To process the request for what information is available, an AS/400 process must query the ERM product, using the valid account information determined during the logon. All of the ERM products I’ve worked with have a set of programming interfaces that allow such a lookup. The resulting list is returned to the Web server, formatted in an HTML page, then returned to the user.

The user can then select which of the available statements he would like to view. Upon selection, the Web server notifies the AS/400 of the choice. A process must execute the appropriate interfaces with the ERM system to retrieve the desired statement. The returned data will then be sent in a raw form back to the Web server.

The Output Needs to Look Good

The data could certainly be formatted as a simple HTML page and returned to the user, but one of the distinct advantages of electronic delivery is doing nicer things with the data. A more pleasing, and potentially more useful, display can be developed for a Web browser.

As I have noted, the stored data contains control codes intended for the printer. Those codes can now be used for other things. For example, a “translation” mechanism can be developed that would provide one or more different kinds of output. A table could be used to associate the print control codes with HTML tags and other formatting information. Properly developed, such a translator could even produce an Extensible Markup Language (XML) representation of the data, useful for integration with other software. In the example application, a comma-delimited representation of the data, suitable for a spreadsheet program, might be a desirable option for the user.

HTML pages are designed to be viewed in a browser, but pages with pleasing appearances often are not very “printer friendly.” One popular option is to supply documents in an Adobe PDF file so that they can be printed. There could be an option in the system for translating the statement into a PDF file whenever a user wants to print it. There are many tools (such as BVS/Tools’ Spooled File Tools at www.bvstools.com) for easily translating print data to a PDF file. Paper is still the most portable form of media, so a good print option is absolutely necessary.

That’s All

With the few simple steps I’ve outlined, virtually any invoice or statement application can have a Web retrieval option added. Some relief would be available for the customer care staff once customers and partners could retrieve information on their own.

Another benefit not to be overlooked is that, once such a system is developed, it would be available to internal staff as well. With appropriate consideration during the design phase, the sales staff could have immediate access to customer invoices from virtually anywhere. Casual users within the organization who have an occasional need for access but who are not active users of an application, could access statements and invoices without having to retrieve a physical copy from the file room. These days, a well-designed browser interface should be accessible to anyone without special training.

The next logical step is to begin weaning users away from the printed and mailed versions. Once that happens, true cost-savings will be realized. The trigger aspect of a piece of mail can’t be overlooked; the receipt of an invoice or statement in many organizations either starts or continues the payment process. Switching to an electronic option may require an alternative trigger mechanism. One option is to send an email to the receiving organization whenever an invoice or statement is available. The email could even contain a preauthorized link to the document. The user would simply select the link and either print or view the document, which is quicker than the mail and provides more options.

Other notification options could be built into the Web application. A user could be notified of new documents each time he logs on to the system. Documents that are new since the last logon could be uniquely identified in any selection list the user may request. The opportunities are limitless.

Commercial Options

If you are not inclined to roll your own application, there are commercial products that accomplish the same thing. For example, CheckFree i-Solutions (www.bluegill.com), formerly Bluegill Technologies, offers a suite of products and services that interface with the AS/400 and with many popular ERM packages. Commercial offerings like CheckFree’s provide a host of features in this application area that I haven’t even begun to touch on. However, those features will come at a price.

Internal development is still an option for many organizations. Given the relative simplicity of this sort of application, it may be a project to consider. The payback could be substantial, especially if there is an opportunity to eliminate printing and mailing processes. The skills required to develop such an application include traditional AS/400 development skills, Web development skills (appropriate for the chosen Web server platform), and security skills (for keeping your infrastructure secure). Chances are, these skills are already available in your organization if other Web development activities are under way.

So why do this? It is a great opportunity to increase customer service and reduce business costs. The ability of customers to access information without involving customer service staff, as well as the potential for reducing ever-escalating printing and mailing costs, are strong reasons for evaluating an electronic presentment option. Throw in a reasonably low level of development complexity, and this option is a winner!

REFERENCES AND RELATED MATERIALS

• BVS/Tools home page: www.bvstools.com
• CheckFree i-Solutions home page: www.bluegill.com
• IBM Content Manager home page: www.software.ibm.com/data/ondemand
• Magellan Software/Gauss Interprise home page: www.magellan.com